DataLinx AI

As an early-stage startup with limited engineering resources, DataLinx needed a site that could evolve with their product without becoming a developer bottleneck. They needed to iterate quickly on messaging, features, and positioning as they refined their product-market fit. This created a bottleneck that slowed marketing velocity and prevented rapid experimentation. Hardcoded pages would mean every content tweak required a code deploy. They needed something in between: a system simple enough for founders to manage today, sophisticated enough to support a full team tomorrow.

The technical requirements were complex: implement a visual page builder with reusable content blocks, maintain type safety and performance, enable real-time content updates without full rebuilds, secure an admin area without heavyweight auth infrastructure, and build extensible architecture that wouldn't need a rewrite when the team scales.

The visual page builder was the most technically complex feature. Puck (a React-based page builder) needed to integrate with Contentful's storage format. Puck stores content as a React component tree structure with nested props, children arrays, and component type references, while Contentful stores everything as flat JSON objects with a specific schema, which required bidirectional transformation with validation.

Puck's format looks like a React component tree:

{ type: 'Hero', props: { title: '...', cta: {...} }, children: [...] }

Contentful expects a normalized JSON structure:

{ fields: { title: {...}, blocks: [{ sys: {...}, fields: {...}}] } }

The transformation involves flattening nested structures, converting component references to Contentful entry IDs, handling arrays differently, and preserving metadata that Puck needs for editing but Contentful doesn't store.

The implementation uses a dual-client pattern for Contentful: the delivery client fetches published content with CDN caching, while the preview client accesses drafts for review before publishing. This enables preview mode where admins can see unpublished changes before they go live.

Content updates trigger webhook handlers that implement content-type-aware revalidation. Blog posts revalidate blog routes, pages revalidate their specific slug, navigation changes revalidate the entire layout. This selective approach means only affected pages rebuild, not the entire site.

The system gracefully degrades when Contentful is unavailable. Components provide hardcoded fallbacks, error boundaries prevent CMS failures from breaking the site, and type-safe data transformations use TypeScript interfaces with validation functions.

The site uses Incremental Static Regeneration (ISR) with webhook-triggered revalidation. Pages are statically generated and cached, then selectively rebuilt when content changes. Images optimize through Next.js Image component with Contentful's CDN for automatic WebP conversion.

The result: Lighthouse scores consistently above 90 for Performance, Accessibility, Best Practices, and SEO.

Several Next.js API routes handle admin operations and integrations. The page management endpoint handles full CRUD operations for Contentful pages: fetching, creating, updating, unpublishing, and deleting content.

The contact endpoint handles form submissions with rate limiting, honeypot validation, and email delivery via Resend. The preview endpoint enables draft mode for content review.

All routes use TypeScript for type safety and include comprehensive error handling with proper HTTP status codes.