PromptAtWork
Case study / Solution Blueprint · Enterprise Web Platforms

AI Enterprise Blueprint: Building Content-Driven Business Platforms

The repeatable case-study process we follow to turn a business that needs to showcase and sell its work into a living platform: content the owner can publish, real data capture, and automation that keeps it fresh, instead of a static website.

3 layers: content, data, delivery7 planning stagesPublish without a code deploySecurity reviewed at every stage
Next.js / React / TypeScriptHeadless CMS (e.g. Sanity)Managed Postgres (e.g. Supabase)Serverless hosting with scheduled jobs (e.g. Vercel)Schema validationDiagram-as-code

Overview

When a business asks for a website, what it usually needs is a platform: a place to showcase work, sell courses or services, capture leads and keep publishing without calling a developer each time. This blueprint is the case-study process we follow for every such project. It starts from the business, not the pages, and works through the same seven stages each time, so a coaching business, a clinic, a training institute or a consultancy all get a platform they can run themselves.

Problem

Static websites go stale. The copy is hard-coded, so every new offering, project or announcement needs a developer and a deploy. Owners stop updating, leads get lost in inboxes, and search engines and AI assistants describe the business from old information. The underlying gap is that a static site treats content as code. A business needs content it owns and can change daily, plus somewhere real for enquiries and sign-ups to land.

ANALOGY

Static website vs content platform

A content-driven business platform is like A shop window the owner can rearrange

  • Content stored in a CMS, not in codeis like Stock kept in the back room, not painted on the window
  • The owner publishes directlyis like The owner rearranges the window herself
  • Pages refresh on publishis like The window changes the moment it's rearranged
  • A database captures sign-ups and enquiriesis like The counter where customers sign up and leave notes
A static site is like a printed brochure: changing a line means reprinting. A content platform is like a shop window the owner rearranges every day without calling the builder. The analogy stops at automation, which has no shop equivalent.

Context

We use this blueprint when the client's business has at least two of these: a catalogue of offerings that changes (courses, services, products), work or proof to showcase (projects, case studies, testimonials), something visitors sign up or register for, regular publishing (blogs, videos, reviews), and a need to be found and correctly described by search engines and AI assistants.

Solution

We plan every platform in seven stages, documented as a case study before code is written. 1. Business discovery: what the business sells, who updates what, and what a visitor must be able to do. 2. Content model: every repeatable thing (offering, project, testimonial, post, event) becomes a structured content type the owner edits in a CMS. Pages are assembled from it, never hard-coded. 3. Data layer: anything a visitor submits goes to a real database with access rules enforced in the database itself, not only in the form. 4. Delivery: server-rendered pages that refresh automatically when the owner publishes, so updates go live in moments with no deploy. 5. Automation: routine upkeep, such as cover images, syncing an external channel or refreshing listings, runs on its own, with a scheduled safety net behind every automated step. 6. Discoverability: structured data, social previews and an AI-readable summary so search engines and assistants describe the business accurately. 7. Content operations: a review-first publishing workflow, so AI-assisted drafts never go live without a human check.

PROCESS FLOW

The seven planning stages

  1. 1. Input

    Business discovery

  2. 2. Action

    Content model

    Offerings, work, posts as data

  3. 3. Data store

    Data layer

    Sign-ups and enquiries

  4. 4. Action

    Delivery

    Auto-refresh on publish

  5. 5. AI

    Automation

    With a scheduled safety net

  6. 6. Action

    Discoverability

    Search and AI assistants

  7. 7. Output

    Content operations

    AI drafts, people publish

Every project moves through the same seven stages, from understanding the business to a review-first publishing workflow the owner can run on their own.

My Role

I lead the process end to end: discovery with the business owner, the content and data model, architecture, build, security review, SEO/AEO, and handover, including training the owner's team to publish on their own.

Architecture

Every platform built with this blueprint has three layers, each with one job. Content layer: a headless CMS holds everything the business publishes, as structured types with validation, so the owner can't publish something half-filled. Visuals such as process diagrams are stored as data and drawn by the site, so they stay consistent with the brand. Data layer: a managed Postgres database holds what visitors submit, such as enquiries, registrations, comments and testimonials. Access rules live in the database, user-submitted content waits for approval before it appears, and anything sensitive (like booking a limited seat) goes through one validated server-side path. Delivery layer: a modern React framework renders pages on the server and refreshes them when content changes. External services are connected through adapters, so adding a new source later doesn't change the rest of the system. Around all three: authenticated automation, structured data for search and AI assistants, and secrets kept only in the hosting environment, never in code or content.

DIAGRAM

The three layers

flowchart TD
  V([Visitor]) --> APP[Web app: delivery layer]
  O([Business owner]) --> CMS[(Content layer: headless CMS)]
  APP --> CMS
  APP --> DB[(Data layer: database with access rules)]
  CMS -- on publish --> REF[Pages refresh]
  REF --> APP
  CMS -- on publish --> AUT[Automation: images, syncs]
  AUT --> CMS
  SCH([Scheduled safety net]) --> AUT
Visitors use one web app. The owner publishes to the content layer, visitor submissions go to the data layer, and automation keeps content and assets current in the background.

Workflow

How a new piece of content flows on a finished platform: 1. The owner (or an AI drafting assistant) prepares the content. 2. Automated checks confirm required fields are filled and that every claim and number traces back to the owner's own source notes. 3. It lands in the CMS as an unpublished draft. 4. The owner reviews and presses Publish. 5. The site refreshes on its own, and supporting assets such as a cover image are generated automatically. The same review-first rule applies to every client: AI can draft, but only a person publishes.

PROCESS FLOW

Review-first publishing

  1. 1. AI

    Draft content

    Owner or AI assistant

  2. 2. Decision

    Automated checks

    Required fields, numbers vs source

  3. 3. Data store

    Unpublished draft

  4. 4. Human

    Owner reviews

  5. 5. Output

    Live, assets generated

Content can be drafted by the owner or with AI help, but it passes automated checks and a human review before anything goes live.

AI Models

Image generation model for automatic cover and card artClaude Code as the build and content-drafting partner

Challenges

Keeping cross-linked content fresh. On a platform, one item appears in many places (home page, listings, related links). We design refresh around the whole experience rather than single pages, so nothing shows stale content after a publish. Slow automated work. Generating images or syncing external channels can take longer than a publish event allows. We run that work in the background and back it with a scheduled sweep, so nothing is silently missed. Limited-capacity sign-ups. When a course batch or appointment slot has limited seats, two people can race for the last one. We make booking a single atomic, validated operation so capacity can't be oversold. Changing the structure later. As a business grows, sections merge and URLs change. We plan permanent redirects from day one so shared and indexed links keep working. Being public and secure. Platforms like these are often fully public. We assume every visitor can see the front end and design so that nothing important depends on being hidden.

Results

What a business gets from this blueprint: a platform the owner publishes to directly, with no developer needed for routine updates; enquiries and registrations captured in one database instead of scattered inboxes; content that keeps itself current through automation; and accurate visibility in search and AI assistants. We have applied it end to end on our own platform, which runs its portfolio, training catalogue, batches, publishing and video library this way.

Learnings

Model the content before designing pages. Once the business's offerings are defined as data, pages, search and AI summaries follow from them. Enforce rules where the data lives. Protection in the database holds even if a form is bypassed. Every automation needs a safety net. A scheduled check behind each automated step catches what events miss. AI drafts, people publish. Checks that tie every number to the owner's own notes stop a model from inventing results. Write the case study first. Planning the platform as a case study before building makes scope, trade-offs and handover clear for the client.

Future Scope

Where the blueprint is heading: an on-site AI assistant that answers visitor questions from the business's own published content, a single admin dashboard that brings content and visitor submissions together, and newsletter automation that brings readers back to new posts.

Confidentiality note: This is our reusable approach, not the documentation of any one system. Endpoints, configuration, data structures and security settings are deliberately left out.