Choose a stack by who edits after launch

An AI agent can write a small site in code in an afternoon. That makes stack choice easy to get wrong. The build is no longer the expensive part. Every edit after launch is, and so is whoever has to make it.

So start from one question. Who edits this site after launch, how often, and what does it have to do? Answer that and the stack mostly picks itself. Start from the tool you happen to like, and you'll answer the question wrongly without noticing you've answered it.

Break it into four. Who edits, and how comfortable are they with software? How often, and from what device? A weekly change from a phone is a different problem from a twice-yearly update at a desk. What do they change: a few words, a price list, whole new pages? And what does the site have to do beyond showing pages? Taking enquiries, bookings, payments. Often that last part is a separate service you connect, whichever stack you pick, so check it early.

Three fictional clients. An architect who updates her portfolio twice a year, always through you. Static HTML or Astro, built with an agent, is fine. Every edit is a small job for you, and that's the arrangement you both expect. A village bakery where the owner changes the bread list every Friday, from her phone. Framer fits, because she can edit that content on the live page without opening the design canvas. And an events organizer with forty events in a spreadsheet. Astro fits, because each event can live as a content file and Astro builds a page for every one.

Here's the trap with building everything in code because an agent makes it cheap. The bakery site would be lovely hand-built. Then the bread list changes on Friday, and either the owner learns to run a build, or you become her Friday job. Neither of you signed up for that. Code is cheap to write now. Edits still cost whoever has to make them.

Neither side is free. With a visual tool like Framer, the client is independent, and you're working inside one company's editor and hosting, on its plans and its limits. In code, you control every detail and you own the files and their history, and every edit goes through someone who can run the build. Pick the cost that suits the person who'll be living with the site.

If you do work with an agent, give it the editing facts before it builds, and make it answer in terms of the owner's Friday. Something like this. Its answer tells you quickly whether the plan survives contact with the person who'll use it.

When you explain it to the client, leave the tool names until last. Describe what an edit will look like for them. For the bakery: you'll open the page on your phone, change the bread list, and publish it. For the architect: you'll email me the new project and I'll put it up. Whichever it is, they should be able to picture their first edit before they agree to anything. If they wince, you've picked the wrong stack.

Whatever you choose, write it in the project file: who edits, how often, the stack, and why it fits. Add one line for what would change your mind. Say the architect decides she wants to post news every week. When that day comes, you'll recognize it as a stack question straight away. How to use each tool is in its own documentation. This decision is yours.

Choose the stack by who edits after launch, and write down what would make you change it.