Working note · July 2026 · for a few friends
Two real projects from the same fortnight that, between them, describe a company I think is worth building. Neither of them proves it works. This is an honest account of what they do prove, what they don't, and what would have to be true for the rest.
It is not that AI can build a website. Everyone knows that, and it is the least interesting part.
What changed is the cost of a round trip.
An agency's unit of production is a human hour. That was true in 2010 and it is still true this morning. So every can you make the logo a bit bigger costs them roughly what it cost fifteen years ago — which is why website maintenance has always been a slightly miserable product. Priced honestly, it is too expensive for a small business to stomach. Priced to sell, it loses money, so it gets deprioritised, so the client waits three weeks for a phone number to be corrected, so they stop asking, so the site goes stale and dies.
Nobody designed that outcome. It falls straight out of the arithmetic.
Now do the same arithmetic when a round trip costs a few dollars of tokens and forty minutes of one person's attention. The retainer stops being the grudging thing you sell after the build and becomes the actual product. The build becomes what you do to acquire the relationship.
Everything above is a claim about supply. It says changes got cheap to make. It does not say anyone wants more of them.
And the binding constraint on a maintenance retainer is probably demand. A small business with an information site may genuinely have three changes a year. If so, dropping the cost of a round trip from $200 to $3 barely moves what they will pay monthly, because they were not buying many round trips at any price. What $250 a month actually buys such a client is insurance and delegated attention — and that product existed before AI and mostly did not sell.
I want to flag that here rather than bury it in the risks, because two pieces of my own evidence point at it. Trent's description of the ideal client is just infomation site. low maintanance — read plainly, that is an argument against a maintenance retainer, not for one. And the churn risk concedes the same thing in different words.
Everything below is either evidence for that narrower claim or an honest note about where the evidence runs out.
Not a website. Not a page builder. Certainly not a design system.
A small business wants their web presence to be correct. The opening hours changed. There is a new person on the team and the old one's photo is still up. There is a closure in August that nobody has announced. A supplier's name is spelled wrong and has been for two years.
What kills small-business websites is not bad design. It is staleness. And staleness is a service failure, not a design failure — which means no amount of better tooling fixes it.
I want to be careful here, because this is the load-bearing claim and it is easy to assert. So here is the observation that convinced me, from a real client:
The temple in Case A was already on Wix. Wix is a page builder — precisely the tool invented to let non-technical people keep their own site current. They had it for years. The site went stale anyway, because nobody at the temple was ever going to learn it.
Giving a non-technical organisation a better editor does not make them edit. They will not learn your interface, however good it is. They want to send someone a photograph of a handwritten note and have the website be right afterwards.
That is a service. It has always been a service. It was just too expensive to deliver at small-business prices, and now it isn't.
But the same passivity cuts both ways, and it is worth saying so: a client who will not learn an editor may also not send the photograph. The temple produced seven rounds of corrections because someone was actively driving a rebuild and asking. In steady state, will they photograph the notice unprompted every month? Unknown. If the answer is no, the service has to pull changes rather than wait for them — an operator chasing clients quarterly — and that is real operator time the capacity assumption does not currently carry.
A Taoist temple and registered charity in Hong Kong. Migrated off Wix onto Cloudflare, rebuilt, and now maintained. What this proves is delivery.
6days from first commit to a client-reviewed rebuild — 115 commits, one person, all of it agent-written.
7rounds of client corrections by WhatsApp photograph — six explicitly evidenced in the repo, the seventh inferred. Nine design iterations before that.
4separate batches of instructions received, applied, deployed and shown back — inside one working day.
Before those numbers do any work, the less flattering reading deserves an airing: 115 commits, nine design iterations and seven correction rounds in six days is also a very high rework ratio. I am counting round trips as evidence of tempo; a sceptic counts them as evidence that the first eight attempts were wrong. Both readings fit the same data and I have not earned the first one — the change reports record whose change each was, so the honest thing is to count the split of client-initiated versus my-error and publish it. I haven't yet.
The site is a single page with eleven sections and a 37-photograph gallery, plus a small admin console. Behind it: Cloudflare Pages for hosting, D1 for the database, Workers AI for the one clever bit, and Zero Trust for the staff login. Hosting cost to date is zero — it fits inside free tiers, and will keep doing so.
The temple issues a printed notice every lunar month — a pink A4 sheet, vertical traditional Chinese, read right to left. That sheet was hardcoded into the website, which is why the site always showed the wrong month.
So the CMS does one thing: a staff member photographs the sheet on their phone, the system reads it, shows them the transcription to correct, and publishes. No page builder, no blocks, no drag and drop, no training. One job, done properly.
Caveat, and it is not a small one: nobody has ever walked that path end to end. Every layer is built and verified in isolation — the recognition, the correction step, the publish — but no temple staff member has logged in and driven it, and neither have I. It is a built feature, not an operating service, and I would be overstating it to describe it in the present tense without saying so.
This matters more than it sounds. A general-purpose CMS is a tool you have to learn. A single-purpose one is a service you use. The reason we could justify building something that narrow is that building it was cheap — which is the thesis again, applied to our own product.
Every round of corrections comes back as a hosted before/after page. Each change sits beside the client's own instruction, quoted verbatim — including his crossings-out and his phrasing, never tidied. He reads it on his phone and rules on each item.
The feedback we got was that the change report is valued alongside the website itself. That is the most interesting thing either project told me, and it is the reason I stopped describing this as a web business.
There is a second-order effect worth naming. Because every change is quoted, applied and shown back, the change reports accumulate into a complete, plain-language history of the relationship. That turns out to matter later — see the note about operators leaving in section 10.
It is pro bono, and it is family-connected. Nobody paid for any of it, so it is worth precisely nothing as evidence about pricing, willingness to pay, or whether a stranger would buy this — and the relationship weakens the warmest datum in it, the praise for the change report. It also had an experienced architect working at burst intensity for free on family-adjacent stakes. None of those four conditions holds in the business being proposed, so "proof of tempo" is really proof of my tempo, which is the wrong evidence. Read it as proof that the work can be done to this standard at this speed, and as a strong hint about what clients respond to. Nothing more.
A marketer in Taipei with no development background. Seven days, unassisted apart from some messages from me. What this proves is that the operator role is real.
On 15 July, Trent was iterating on a homepage design for a Taiwanese energy company and hit her plan's usage limit mid-sentence. She had no engineering background and had never deployed anything.
On 22 July she sent me a link to a live HTTPS site on Cloudflare Pages.
i cant beleive i did it - [link to her client's site, redacted]
deploy on https!!
true...omg i was like a half website developer?
i asked for NTD 150k building a website, i thought the margin is good lol
Trent, 22 July 2026 · her spelling, four consecutive messages
7days, from usage-limit banner to a live HTTPS deploy she did herself.
150kNTD for the build — about US$4,640 at today's rate. Her price, her client. She told me what she asked for, not what was ultimately paid.
$25.67of model spend to produce the design through three rounds of revision. Screenshot on file.
Two things in that thread matter more than the deploy.
She described the business model in her own terms — though I have to be careful how much weight I put on that, for reasons I'll come to:
yeh right, i always bundle with other digital marketing service. like web+SEO
especially those are samll business, just infomation site. low maintanance
Trent, 22 July 2026 · replying to me
I originally wrote that she arrived at this unprompted. Checking the transcript, that isn't true: one message earlier I had argued that the profit is in the retainer rather than the build, and her reply literally opens with yeh right. She was agreeing with me.
What is genuinely hers — and what I did not feed her — is the specific shape: bundle it with SEO, and aim at small information sites. That comes from her own book of business, and it is the part worth listening to.
It is also worth reading the second line against the thesis rather than in support of it. low maintanance is an argument against a standalone maintenance retainer. And her instinct to bundle is telling you how a client like that actually gets sold: as a line item inside a marketer's existing relationship, by someone who already owns the client. That points somewhere slightly different from where this document started — see section 09 and the 90-day plan.
And she was honest about the learning curve. After I sent her a wall of advice about CLI harnesses, sub-agent delegation and version control:
okk i can only understand 30% haha
Trent, 21 July 2026
She is right, and that line is the clearest statement of the problem this business solves internally. She should not have to understand the other 70%. Nothing she needed that week — git, deploys, rollback, hosting, access control — is a thing an account manager should be thinking about. That is what the workflow layer is for.
She had me on LINE the entire week. Every time she hit a wall — hosting, version control, token costs — she asked and I answered within a couple of hours. So this is evidence that a motivated non-engineer can do the work with expert support on tap, which is genuinely the proposition. It is not evidence that anyone can do it alone. It also proves a price for a build, not for a retainer. Nobody has sold the retainer yet.
Concretely, what a client pays for every month.
The build is a separate one-time fee that gets the relationship started. The retainer is the business.
The person who owns the client. Not an engineer, and deliberately so.
An operator is a tech-comfortable account manager — a Trent. They handle intake, build, revisions, ongoing maintenance and the upsell conversation. They own the relationship end to end, and the relationship is the asset.
What they need to be good at is the thing that does not automate: judgment about what a client actually meant, and the discipline to check rather than assume. In the temple project, several rounds turned on exactly that — noticing that a relayed message was somebody's paraphrase and should not be quoted back as the client's own words; verifying that a "nothing needs changing" ruling really did leave the site untouched instead of trusting our own report about it. Those are not technical skills. They are the whole job.
What they should never have to touch: git, deploys, DNS, certificates, rollback, infrastructure, cost control, or the difference between a Pages Function and a Worker.
My job. The part that makes an operator viable and is the only thing here resembling a moat.
None of this is novel technology. The work is in the specificity — the accumulated set of rules about what to do when a client photographs a handwritten note, how to transcribe it without paraphrasing, what to check before claiming something is done. It is boring and it compounds.
I am not going to claim it is hard to copy. It is two weeks old, and every founder says that sentence. The workflow layer is a head start, not a moat — and the proof is in this document: Trent, a non-engineer, closed most of that gap in seven days with a friend answering questions on LINE. If it can be crossed in a week with chat support, it is not defensible on its own. What compounds into something durable is the per-client record it produces, and the relationships the operators hold. See section 10, where this is a live risk rather than a footnote.
There is a working model with every assumption exposed. Change them — most of them are guesses and the page says which.
The headline, on the base case: a client on a US$250 retainer costs about US$26 a month to serve, of which roughly $16 is AI and the rest is hosting, sundries and card fees. One operator carrying 25 clients plus a couple of builds a month runs at roughly 50% contribution after their revenue share.
Four things worth pulling out, including two that are uncomfortable:
The number I would most like someone to attack is how many clients one AI subscription can carry. I have modelled 15; the slider goes from 2 to 40; nobody has measured it. The only real evidence anyone has points down — Trent hit her plan's usage limit while serving one client. At 4 clients per subscription the per-client cost roughly triples and the business still stands up, which is reassuring but is a sensitivity check, not a finding: I tested one variable while holding retainer, churn and clients-per-operator at flattering values. There is also a question I can't answer, which is whether sharing one flat-rate subscription across many commercial clients is within the provider's terms. If it isn't, the honest unit is metered API pricing and the AI line is several times bigger.
I'd rather tell you what Bear does than let you find it. Contribution per operator falls from about $8,000 a month to $2,200, margin from 52% to 34%, and the operator takes home $3,130 for carrying twelve clients. Survivable, if thin.
The part that actually stings is the agency comparison: under Bear it inverts. If the ICP really is as quiet as the churn risk says, an agency serving them isn't spending four dev-hours a month — it's spending one, at maybe $80 all-in, and our cost to serve is $128. We lose. The base-case chart's drama comes partly from assuming the agency does four hours of monthly work for clients I elsewhere describe as too quiet to retain, and you cannot hold both of those at once. The chart says so itself when it happens: if that happens on plausible inputs, the thesis is wrong and this page just told you so. I think Bear is too pessimistic on the retainer and about right on the change volume, which is another way of saying the demand question in section 01 is the one that decides this.
Open the model → Currency switcher, every input adjustable, measured figures tagged separately from assumptions.
Trent saw the reels too — agents crawling Google Maps for businesses with no website, generating a preview, charging a few hundred dollars to make it real. This is real and it will get more common.
It is not a cheaper version of this business. It is a different one: a build with no second month. They are competing for the one-time fee, which is the part I am arguing is no longer where the value is. Where they hurt is by resetting what a client thinks a website should cost — which is a marketing problem, not a margin problem, and the answer is to not sell websites.
They will keep the clients who want a brand, a campaign and a strategy deck, and they should. Where they are exposed is the long tail of small clients they serve badly because the arithmetic does not let them serve them well. That is the whole target market.
These are genuinely good and improving fast, and they are aimed at a different person: someone who wants to build the thing themselves. Trent's client did not want a tool. They wanted a website and someone to call.
I had a second argument here — that a general builder has to be equally good at a landing page and an interactive game, so its user has to know how to steer it, whereas everything here is scoped to one shape of problem and can therefore encode opinions a general tool cannot. I no longer think that holds. Both halves are product decisions, not structural facts. A verticalised "small-business site" mode, an opinionated template set, a done-for-you concierge tier, an agency partner programme — each is one quarter's roadmap, and "opinions" are precisely the thing a system prompt encodes at zero marginal cost.
The counterexample is already in this document. Wix Studio is Wix's agency product — the temple's own former platform already sells a workflow layer to exactly the operator persona described here. A friend who knows the market will raise that, so better to raise it first.
What I think actually survives is not the tooling. It is distribution through operators who already own small-business relationships, and the accumulated per-client record — every instruction, every ruling, every house-style decision, in plain files. That compounds into a switching cost that improving tools do not erode. Encoded taste does not; it gets commoditised.
Roughly 40% of the web, and the objection you will meet most often. Trent hit it in week one:
client insists to have WP :(
Trent, 15 July 2026
It is worth being precise about what a client means by this, because it is almost never a technical preference. They mean some combination of: I don't want to be locked in to you; my last agency used it; I've heard it's the standard; and I want to be able to hire anyone to take this over. Those are all reasonable, and none of them is about the software.
There are three honest answers, in order of preference:
What I would not do is argue with the client about their CMS. It is their site.
Ranked roughly by how much they worry me. Some of these have answers and some do not.
The entire model rests on recurring revenue and there are zero months of it. One case is pro bono; the other is a build fee with no ongoing service attached.
No answer This is the gap, not a risk to be managed. It is what the first 90 days exist to close, and if it does not close then the rest of this document is an interesting essay.
Discussed in section 01 and repeated here because it belongs on this list. A small information site may have three changes a year. Cheap round trips improve the margin on a retainer; they do not create appetite for one.
No answer Same category as the one above — this is what stage one tests, and it is why stage one is a pricing and demand experiment rather than a delivery one. If it fails, the fallback the evidence actually points at is Trent's: the web line lives inside a broader marketing retainer sold by someone who already owns the client, which is a different company from the one described here.
The product is the 70% Trent didn't understand — git, deploys, rollback, hosting, access control. That gap is not a fact of nature. It is the current frontier of usability, and it is exactly what model providers and builders are spending enormous sums to erase. In eighteen months "deploy to HTTPS with rollback" may be a button in mainstream tools.
Weak answer This is strictly more dangerous than repricing, because provider-agnosticism doesn't hedge it. The document's own evidence is the indictment: a marketer crossed most of that gap in seven days. The honest position is that the workflow layer buys time, and the thing to convert that time into is client relationships and per-client history — the assets that improving tools don't erode. I would rank this the most serious risk on the list after demand.
The whole model needs a capable person to prefer this to freelancing. Under commoditisation pressure — build fee near zero — an operator on the default revenue share earns roughly $2,200 a month for carrying 25 clients end to end. Trent asked more than twice that for one build, working alone.
Partial The fix is arithmetic, not persuasion: raise the retainer share, raise the retainer price, or accept that the operator is really an independent who should be on the platform arrangement. All three cost the headline margin. The model exposes operator take-home as an output so the trade is visible rather than discovered later by the operator.
The relationship is the asset and the operator owns it. On a revenue share they are already most of the way to being independent, and the better the workflow layer gets, the less they need us.
Partial The handover cost is unusually low here — every client is a git repository plus a complete, plain-language history of every change ever made and why. A new operator inherits something legible rather than a folder and a phone number. That does not stop anyone leaving; it stops them taking the client's continuity with them. The honest mitigation is that this is a people business and you retain people by making it good to be here.
AI quality is bounded by the skills layer, which I control and can improve for everyone at once. Judgment is not. A mediocre operator paraphrases a client's words, ships it, and loses an account that took a year to earn.
Partial Some of it is encodable — the temple project produced a written house-style rulebook precisely because we got it wrong once. The rest is hiring and review, which is ordinary management and does not scale as nicely as the rest of this.
The cost base sits on somebody else's subscription, and they can reprice it, rate-limit it, or change what is allowed.
Partial AI is ~6.5% of the retainer, so on price alone providers would have to raise several-fold to matter, and competition plus open-weight models push the other way. But I have to be consistent: that 6.5% is downstream of the clients-per-subscription assumption the same document tells you to distrust most. At four clients per subscription it roughly triples, and if subscription-sharing turns out to be against the terms, the real unit is metered API pricing. On pricing this is a mild risk. On capability — see two risks above — it is the most serious one here.
Price expectations get reset by people selling builds at cost.
Good Sell the retainer, not the build. If necessary the build can go to near-zero as customer acquisition — the model still works on the recurring revenue alone, and you can check that by dragging the build fee to the floor.
Clients who buy an information site do not have many changes. After six quiet months, cancelling looks free.
Partial This is the risk I would watch most closely after the first one. Quiet clients churn, so the quarterly review is not a nicety — it is the thing that makes the retainer visibly worth paying for. Bundling something with continuous visible output, which is what Trent already does with SEO, is probably the real answer.
Sometimes the model produces something subtly wrong, and on client-facing copy in a language the operator may not read well, that is dangerous.
Good This is what the change report is for. Nothing reaches a client without a human looking at a before/after, and nothing goes live without the client approving it. The process already assumes the machine is fallible.
Free tiers cover a static site and a small database. They do not cover outbound email, and they stop covering things as traffic grows.
Good Already hit this on the temple project: the contact form stores enquiries but cannot email them without a paid plan. It is a real cost line, it is small, and it is in the model as a percentage of clients needing a paid tier. Worth naming so nobody discovers it as a surprise.
Staged, because how fast this goes depends on whether anyone else wants in. Everything in stage one happens either way.
Note what this is not. It is not a delivery test — delivery is the part I am confident about. It is a test of whether anyone wants to buy a month of this, and at what price.
Nothing, immediately. I am going to do stage one regardless, because it is a small number of hours and it answers a question I want answered.
What would be genuinely useful:
The reason I am interested in this and not something with a larger number attached: it is a business where doing the work well is the same thing as winning. There is no growth hack in it. You answer quickly, you get things right, you show people you understood them, and you keep doing that for years.
A good boring business. I would like to run one.