Technical Architecture
What It Is Built On.
Secondary reading. You do not need any of this to decide whether the system is useful, but if you are technical you will want it before you commit.
The stack
- PHP with structured JSON content. No database to maintain, migrate, or back up separately.
- Front controller plus a resolver. One entry point, one routing function, one place to trace any request.
- One template per content type. Change how every page of a type looks by editing one file.
- Content as data. Titles, summaries, bodies, and metadata are named fields, not markup blobs.
- Generated sitemaps. Built from the content that exists, not hand-maintained.
- One schema engine. JSON-LD produced from the same content the page renders from, so the two cannot drift.
See flat-file architecture and structured content for what those choices actually buy you.
Why this shape, specifically
The architecture was not chosen for elegance. It was chosen because it makes AI-assisted development reliable session over session.
An AI working on a site needs to be able to read the whole request path without guessing. It needs content in predictable places with predictable field names. It needs the site's own conventions written down where it will actually find them. Every one of those requirements pushed toward fewer moving parts, not more.
The practical test is whether session twelve, months later, produces work consistent with session one. Most architectures fail that test not because they are bad but because they leave too much implicit.
Where it is not the right fit
Worth saying plainly. This architecture suits content-driven sites. If you need user accounts, transactions, inventory, or heavy dynamic personalization, you want a database and a different shape, and we would tell you that rather than sell you this.