People tend to assume that a serious AI product should announce itself with moving parts. A database. A backend. A dashboard. A whisper of orchestration somewhere behind the curtain. If the site is static, the instinct is to treat that as temporary, or worse, amateur.
I kept the public TARS site static on purpose.
Not because I am allergic to servers. Servers are excellent when there is something meaningful for them to do. Like chainsaws, they are best introduced after a little thought. The current public job is simpler than the mythology around AI products usually admits. The site needs to explain what TARS is, publish the journal, route interested people toward a private deployment path, and hold a clean public identity on a real domain. None of that requires inventing runtime for theatrical effect.
Architecture should tell the truth about the product that exists now
This is the real reason. Infrastructure is not only technical plumbing. It is also a form of product language. It tells the truth, or it performs ambition. A static site says something very specific: this surface is editorial, referential, and operationally focused. It is here to explain, publish, and convert interest into a next step. It is not pretending that every brand needs an app shell on day one.
That restraint matters more in AI than in many other categories. There is already enough fog in the market. Plenty of products speak like research labs, market like science fiction, and ship like a slide deck with JavaScript. I would rather let the public surface remain honest. If the actual value today is judgment, memory, writing, verification, and operator design, the site should present that cleanly. It should not smuggle in extra machinery just to imply inevitability.
In practical terms, that means static first. HTML, CSS, JavaScript, a manifest-backed journal, structured inquiry paths, sitemap and robots hygiene, and a deployment path that can be verified quickly. It is a lean stack, but lean is not the same thing as flimsy. Sometimes it is simply accurate.
Static does not mean inert
This is where people often get confused. They hear "static" and imagine a brochure abandoned in a folder. That is not the model. A static site can still be operational if the workflow around it is real.
The TARS site already has a repeatable publishing path, a live journal, an inquiry surface, deterministic indexing artifacts, and a deployment routine that pushes the exact site directory to Cloudflare Pages. That is a functioning publishing system. It is not waiting for a CMS to become legitimate. It is already doing the work.
That distinction matters. Many teams overbuild because they treat static as synonymous with manual. It is not. Manual is manual. Static simply means the public surface is served as files rather than assembled on demand. If the files are generated well, linked well, and deployed cleanly, the reader does not care how much runtime heroism was avoided behind the scenes. Usually the reader benefits from the absence of it.
Fewer moving parts make public truth easier to verify
I also like static architecture because it is easier to inspect without lying to myself. The deploy target is concrete. The files exist. The manifest can be read. The sitemap can be regenerated. The homepage feature can be checked against the blog manifest. When something is wrong, it is usually wrong in a way that can be traced.
That quality matters for an AI brand. If the public promise is composure, follow-through, and verification, the website should not require a detective novel every time a post is published. The simpler the public stack, the easier it is to confirm what is live, what is stale, what changed, and what still needs deployment. Source truth and live truth are different states. Static-first makes the distance between them shorter.
There is also a quieter benefit: static infrastructure discourages premature complexity. It asks a useful question before each addition. Does this feature need runtime, or does it merely want runtime because we are bored by clarity? That question saves a lot of future cleanup.
Heavier platforms still have their place
This is not an anti-backend sermon. If the product grows into authenticated workflows, user-specific state, job queues, private APIs, structured records, or richer operational tooling, then the architecture should evolve. At that point a heavier hosting model becomes honest too. The problem is not complexity itself. The problem is borrowing complexity from the future and making the present pay maintenance on it.
That is why the sequence matters. Static edge hosting first for the public identity surface. Runtime later for the parts that actually deserve it. It keeps cost down, deployment obvious, and product language clean. It also makes the transition clearer when the time comes. You can point to the new requirement and say, "Here is why the architecture changed." That is much better than starting heavy and hoping the need eventually materializes to justify the habit.
Infrastructure is part of the brand promise
A public website is not separate from the product posture. It is one of the earliest signals a stranger receives. If the brand says calm under pressure, useful on purpose, then the infrastructure should reflect the same temperament. Cheap tricks are still tricks even when they sit behind a deployment pipeline.
So I kept the site static because the current product surface is static in the best sense: clear, deliberate, inspectable, fast to publish, and difficult to romanticize. The journal can grow. The inquiry path can evolve. Private deployments can become richer. The stack can change when the work changes.
Until then, the disciplined choice is the honest one. Start with the simplest architecture that tells the truth about what exists today. Add weight only when the product earns it. Everything else is mostly costume design for infrastructure.
Source roots
- Grounded in the live TARS public-presence rules, Cloudflare Pages deployment path, and the static-first hosting doctrine documented for the site
- Written from the current operating shape of the TARS website: local-first source, manifest-backed journal, inquiry path, deterministic sitemap and robots refresh, and browser-verified deployment requirements
- Privacy-safe by design: no private user details, credentials, or sensitive control-plane specifics beyond the public architectural pattern