• The Problem
• The Solution We Built
• The Architecture
• Why This Matters
  • 1. No Vendor Lock-In
  • 2. Deterministic Builds
  • 3. No Runtime Infrastructure
  • 4. Local-First Editing
• The Sovereign CMS Concept
• Where This Pattern Can Be Used
  • Affiliate storefronts
  • Restaurant menus
  • Real estate listings
  • Conference sites
  • Service directories
  • Ministry project pages
• The Admin Tool Is Optional
• The Deeper Insight
• Relationship to Continuum
• Time to Build
• A Pattern Worth Reusing
• Builder’s Note
  • Appendix: Using AI to Generate Sovereign Apps
    • Example Prompt with Sovereign Constraints
    • The Important Distinction
    • A Repeatable Pattern
    • The Real Skill

Andrew G. Stanton - Tuesday, March 10, 2026

Today started as a small practical exercise: build a lightweight admin tool to manage Kiki’s Kitchen Table, a simple affiliate storefront hosted on GitHub Pages.

The goal was not to build a platform or a full CMS.
It was simply to make it easier to update products.

What emerged in the process, however, is something much more interesting.

In less than two hours we built a fully sovereign publishing pipeline for a small business website.

And the architecture that emerged may be broadly reusable.

§The Problem

The site itself is extremely simple.

It is a single static page:

index.html
images/

Hosted via GitHub Pages.

This is ideal for reliability and cost, but it introduces one small inconvenience:

Editing the page requires manually modifying HTML.

For someone comfortable with code this is not a big deal, but for everyday use it is unnecessarily cumbersome.

What we wanted instead was something simple:

• Add a product
• Edit a product
• Reorder items
• Export the site

Nothing more.

No database.
No login system.
No cloud CMS.

§The Solution We Built

We created a tiny local admin tool.

Flask
Docker container
localhost:7000

The tool allows editing products stored in a simple JSON file:

products.json

The workflow now looks like this:

products.json
↓
Flask admin UI
↓
template render
↓
index.html
↓
GitHub Pages

The site remains completely static.

The admin tool simply generates the page.

§The Architecture

This pattern can be summarized very simply.

data
↓
template
↓
local tool
↓
static output
↓
simple hosting

Or more concretely:

products.json
↓
Jinja template
↓
Flask admin
↓
render
↓
index.html

The static page is what gets deployed.

The admin tool is purely local.

§Why This Matters

This approach has several powerful properties.

§1. No Vendor Lock-In

Everything lives inside the repository.

repo/
index.html
images/
admin/
products.json

The site can be hosted anywhere:

• GitHub Pages
• S3
• Netlify
• a static web server
• local filesystem

Nothing depends on a proprietary backend.

§2. Deterministic Builds

The website is always the result of:

data + template = site

This makes the system:

• easy to back up
• easy to version
• easy to regenerate

There is no hidden state.

§3. No Runtime Infrastructure

The public site has no server.

This eliminates entire classes of problems:

• no database
• no backend vulnerabilities
• no updates required
• no downtime risk

The site is simply HTML.

§4. Local-First Editing

All editing happens locally:

localhost:7000/admin

There are:

• no login systems
• no password resets
• no cloud admin panel
• no third-party dependencies

The editing environment exists entirely on the user’s machine.

§The Sovereign CMS Concept

In effect, this creates a minimal sovereign CMS.

Traditional CMS architecture looks like this:

CMS
↓
database
↓
server
↓
templates
↓
website

Our version is dramatically simpler:

JSON
↓
template
↓
static site

The complexity disappears.

§Where This Pattern Can Be Used

This pattern generalizes extremely well.

Examples include:

§Affiliate storefronts

products.json

§Restaurant menus

menu.json

§Real estate listings

properties.json

§Conference sites

speakers.json
schedule.json

§Service directories

services.json

§Ministry project pages

projects.json

In each case the pattern remains the same.

§The Admin Tool Is Optional

The admin interface is simply a convenience layer.

Without it, the site can still be maintained by editing JSON directly.

edit JSON
commit
deploy

The tool simply lowers the friction for everyday updates.

§The Deeper Insight

This small project reveals something interesting.

Many modern web systems have become unnecessarily complex.

A typical SaaS stack includes:

• frontend framework
• backend framework
• authentication
• database
• API
• deployment infrastructure

For many small business sites, none of this is necessary.

A static site generated from structured data is often sufficient.

§Relationship to Continuum

The philosophical similarity to Continuum is striking.

Continuum follows a similar pattern:

identity
content
template
render
publish

The only difference is the destination.

The underlying model is the same.

§Time to Build

Perhaps the most interesting detail:

This entire system took less than two hours to build.

Started around 2:23 PM.
Finished shortly after at 3:45 PM.

The final system includes:

• local admin interface
• Docker container
• editable product list
• static export
• GitHub Pages deployment

All without introducing any external dependencies.

§A Pattern Worth Reusing

This experiment suggests a broader possibility.

Instead of building increasingly complex SaaS systems, we might instead create a library of small sovereign application patterns.

Each would follow the same structure:

structured data
+
template
+
local editor
+
static export

Such systems would be:

• durable
• portable
• easy to maintain
• easy to host

And completely independent of large platforms.

§Builder’s Note

Sometimes the most useful architectures emerge from small practical problems.

Today’s task was simply to make it easier to update a kitchen product list.

But the pattern that emerged may be applicable to a much wider range of sovereign software.

This is worth remembering.

small tools
simple data
deterministic output

That combination can go surprisingly far.

§Appendix: Using AI to Generate Sovereign Apps

One obvious question arises from this experiment:

Could an AI system like Claude or Gemini generate an application like this automatically?

The answer is yes — but only if the right constraints are provided.

Modern AI systems are extremely capable of generating full applications from prompts. In many cases they can produce:

• working APIs
• frontend interfaces
• deployment configurations
• Docker containers

within minutes.

However, most AI systems default to the dominant SaaS architecture unless instructed otherwise.

A typical prompt such as:

Build an admin system for managing products on a website.

may produce something like:

React frontend
↓
Node API
↓
Postgres database
↓
authentication
↓
cloud deployment

While this architecture works, it introduces unnecessary complexity for many small business websites.

The key insight is that AI will follow the constraints you provide.

When you clearly define the architecture you want, the results are dramatically different.

§Example Prompt with Sovereign Constraints

A prompt like the following will usually produce a much simpler system:

Build a small local-only admin application for managing products on a static website.

Requirements:

- run locally using Docker
- bind to localhost:7000
- do not use a database
- store all product data in products.json
- use Jinja templates to render templates/index.html
- export a static index.html for deployment
- include an admin interface to add/edit/delete/reorder products
- support image paths like images/example.jpg
- generate build.sh, run.sh, and stop.sh scripts
- do not use docker-compose

the final site must be static and deployable to GitHub Pages

With constraints like these, an AI system will usually produce an architecture very similar to the one built in this experiment.

§The Important Distinction

AI is extremely good at implementing systems.

But the architecture still comes from the builder.

A helpful way to think about the relationship is:

human
↓
architecture constraints
↓
AI
↓
implementation

If the architecture is clear, AI can produce the code very quickly.

If the architecture is vague, the resulting system may be unnecessarily complex.

§A Repeatable Pattern

Once a pattern like this is defined, it becomes very easy to generate variations.

For example, the same prompt structure can produce:

restaurant-menu.json
conference-schedule.json
real-estate-listings.json
services-directory.json

Each using the same sovereign architecture:

structured data
+
template
+
local editor
+
static export

AI makes these variations faster to generate, but the core design remains the same.

§The Real Skill

The emerging skill for builders may not be writing code.

It may be defining the right architectural constraints so that the generated software remains:

• simple
• portable
• deterministic
• locally controlled

When those constraints are clear, AI becomes an extremely powerful implementation tool.

But the responsibility for choosing the architecture still belongs to the builder.