I have been building for the web for twenty years. I can ship reliable software, wrangle integrations, and keep things upright when traffic spikes or a vendor changes an API. What I cannot do is design: colour, spacing, typography, and “does this feel premium?” are not my strength.
This site is a deliberate counter-example. The first usable version went from blank editor to deployed in about twenty minutes, driven by a small set of carefully written prompts to a modern coding model—not because magic replaced thinking, but because the model could hold layout, copy, and structure in one pass once the instructions were clear.
No database, no traditional CMS
There is no database behind this public site and no backend CMS you log into to publish it. Content lives as plain files in the same version-controlled project as the code; a build turns those files into fast, static pages. For what this site is for—credibility and a straightforward story—that is enough, and it keeps hosting simple and easier to keep secure.
When something needs to change—visual polish, page structure, wording, layout, or a new article—the workflow is the same: describe the outcome, point the model at the project, and let it apply edits it can point to in real files. The model already knows how this site is organised, so you spend less time on filenames and paths and more time deciding what “good” looks like.
Hosting and deploys, also model-assisted
The same pattern extends past the front end of this site. Hosting on AWS and the automated deployment pipeline were set up with heavy model assistance: repeatable cloud configuration kept alongside this repo, predictable releases, and guardrails that match how a small team actually operates. The point is not “an AI pressed buttons” for its own sake—it is that boring, correct operations can move at the speed of a well-scoped conversation when the project folder is the source of truth.
Rules beat one-off miracles
Alongside the code, there is a set of project rules for the assistant: how the homepage layout is named, how blog posts should sound, when changing cloud permissions needs extra care, and so on. That is what makes “add a blog post about how this site was built” a sensible request instead of a ramble. The model gets repeatable guidance, not a different personality every session.
If you are evaluating vendors who promise “AI websites,” ask whether they can show you the rules and the repo—not just a slick deck. Speed without a clear paper trail in the code is how you get drift, broken links, and copy nobody owns.
What this is not (and why that matters)
None of this removes the need for judgement. Models still need scope, review, and humans in the loop for anything customer-facing or where industry rules apply—get professional advice where that matters for you. What changes is how much friction sits between a clear decision and a shipped change when your assets are text, code, and configuration files rather than tickets spread across three portals.
Where the value has shifted
Layout and straightforward implementation are cheaper and faster than they used to be, for teams who know how to steer models with clear constraints. The durable work is helping your organisation AI-enable what you already have: your public website, internal tools, manual processes that still run on email and spreadsheets, and the architecture and governance so assistants and automations save time without opening new holes.
If you want help with websites, integrations, and sensible rollouts—not just prettier pages—talk to us about making your systems AI-ready.