DEV Community: Pierre- Laurent Medori

Your agent's memory is a liability: track state, not history

Pierre- Laurent Medori — Thu, 03 Sep 2026 13:04:57 +0000

There is a French draft in one of my test apps that I keep like a fossil. Article 96924661: a title, a slug, zero paragraphs. A June translation run created it; I remember that run as green. I cannot check it: the n8n execution history from June is purged. What survives is a screenshot and the likeliest path, read off the canvas and never reproduced: the article is created before its paragraphs, so if the split step yields nothing, "Create FR paragraph" runs without error on nothing and the report node declares success. Green all the way down. The draft is still empty.

As I wrote in June, in the piece on automating an app with n8n and MCP, "our runs burned 40,000 to 77,000 input tokens per minute, past the rate limits of an entry-tier API account, whatever the model." The survivor was not an agent: deterministic plumbing, plus one model call per article. One line of context so you know where I stand: I run engineering at GoodBarber, an app platform, and we run a production MCP server everything below runs on systems I operate myself.

Then a preprint crossed my feed at the end of August with a headline number: 16 times fewer tokens, 94 percent once you do the subtraction, if your agent keeps state instead of history. I had lived the mechanism before the paper, so I read it back. Here is the cell the number comes from, my June job replayed five ways, what our server learned the hard way, and the rule the paper does not have.

The number is real. The cell matters more.

The preprint is SKILL.state, arXiv 2608.26263, v1 posted on August 26, 2026, by Sanket Badhe and Priyanka Tiwari at Google LLC with Jonghyun Chung at Purdue. At every step the model receives an immutable skill specification, the current structured state as JSON, and the last observation; the reasoning trace is discarded once the runtime has validated its state patch. The prompt stays roughly constant, so cumulative cost is O(T) instead of O(T²).

The 94 percent is exact and it is one cell. Table 1, the authors' synthetic Warehouse environment, Gemini-3-Flash, horizon T = 100: 65,408 cumulative tokens against 1,062,387 for the stateful baseline, a 16.2x gap. Same column at T = 10: 43 percent. On the public benchmarks, InterCode CTF and τ-Bench, the reduction lands between 11 and 66 percent depending on the baseline. The gain is a horizon effect.

The result that matters is elsewhere. At equal budget, roughly 1,800 prompt tokens for every runtime at T = 100, accuracy was 0.94 for the structured state, 0.52 for a capped summary, 0.22 for ReAct plus LLMLingua, 0.18 for a truncated window. The saving is a side effect. The structure is the result.

The prefix is the bill

On September 3, 2026, I counted our tool inventories with the count_tokens endpoint against claude-haiku-4-5. My n8n test app, 62 tools: 17,763 tokens. The larger test app, 77 tools: 23,174. The seven tools a translation needs: 2,416. One default page of cms_list_articles on the small app: 16,987. The paper's mean prompt per step, all three inputs included: 1,905.

A ReAct loop on that app opens every turn with nine times the paper's whole prompt in schemas alone, and each list it calls adds nine more that history never forgets. D's six-field state object counted 56 tokens; a create-and-read-back envelope, 112.

I replayed June in five arms

Same job, same six English articles, same test app, September 3, 2026, claude-haiku-4-5, prepaid credits; the table is run 1, except D, the best of its six versions. Every French draft was created as status: draft with a marker, then deleted. Verification is deterministic and outside the model: the five checks in the code block further down.

arm	what	verified	model calls	input tokens	cache read	list price
A	ReAct, full history, 62 tools	6/6	25	1,159,084	0	$1.267
B	ReAct, full history, 7 tools	6/6	25	893,341	0	$1.002
C	script plumbing, one call per article	6/6	6	7,135	0	$0.054
D	explicit state, best of six runtime versions	4/6	80	155,249	0	$0.348
E	arm A with prompt caching	6/6	25	123	1,080,099	$0.306

A does C's job with 160 times the input tokens. B, with 55 fewer tools, still needs 125 times: trimming the inventory does not fix a loop that re-reads its own transcript. A peaked at 694,434 prompt tokens in a 60-second window and never saw a 429; the account is not where it was in June, so I will not quote a June limit. C is the June survivor, a stdlib script now that the n8n workflow no longer runs: O(1) per article, and its prompt was the paper's triplet before anyone named it.

A second pass the same day reproduced A within 0.1 percent (1,158,626 input tokens) and B 13 percent lower (773,767); C used the same 7,135 tokens and E came out at the same $0.306.

E, arm A with cache breakpoints: 123 uncached input tokens, 73,114 written to cache, 1,080,099 read from it, 93 percent of the prompt served from cache, a quarter of A's price. Caching makes the transcript cheap. It does not make it small, or a sufficient statistic of anything.

And D, my own SKILL.state, never finished. Six runtime versions in one afternoon, 80 to 100 steps each, prompt flat between 1,400 and 2,500 tokens per step, best result 4 of 6. Each version failed somewhere new. The first schema carried ids and statuses but not the translation, so the model re-read the source at every step, 33 reads for 6 articles, and the runtime filed one French id under two sources. With the translation in state, the model invented tool arguments, author_id, body, language, and the server refused 74 creates in a row. With arguments filtered against the tool schema, it re-read and re-created: 52 reads, 17 drafts for 6 sources. With the runtime owning the state machine and naming the next expected action, it created 70 paragraphs on the same drafts: after each write the runtime read the article first and the paragraph list second, so the list came from the 60-second GET cache, empty, for about 25 cycles, then 131,991 bytes at once. My commit rule was right. My read path was the cached one. With the read-back taken off the cache, 4 of 6, then a patch rejected 52 times for a string where an integer was expected. The paper reports that on small open-weight models 68 percent of failures are premature overwrites of the state; on claude-haiku-4-5 mine were the runtime's, and every one of them was a validation the runtime did not do yet. The state was constant. Sufficient is the hard part.

My own transcripts are not O(T) either

On September 3, 2026, I scanned my local Claude Code transcripts, counters only, no content: 264 files, 175 sessions with at least 30 assistant turns, 32,607 turns. Prompt per turn (input, cache creation and cache reads) climbs until a compaction, then drops: 37 drops of more than half, a median cost of 2.2 times a constant-size state, a median cache read share of 0.968. The longest session ran 2,444 turns and 1,071,111,255 prompt tokens, 6.89 times a constant state, 97 percent of it cache reads. That is Daniel Vaughan's point about Codex CLI: O(T²/K) by chunks, not O(T). I have never noticed a decision lost to compaction and will not claim one. I can only vouch for the bill.

The server did it to itself first

Our MCP server stopped keeping history on August 10, 2026. Since then the transport is stateless: no Mcp-Session-Id, no session cap. What the server keeps per agent, keyed by the sha256 of the access token: the last ten tool names for one hour, enough to push the read that follows a write past the cache, and since August 11 a sliding counter of 1,000 requests per minute that answers 429 with Retry-After. Ten names and a number.

Measured on September 3, 2026, 50 cycles on a test app. A get straight after a delete: 3 stale reads out of 50, the August fix holds, not perfectly. Delete, list, get: the deleted object came back in 50 of 50 cycles and stayed a median 61.1 seconds, maximum 61.2, the 60-second GET cache doing what it was told. The bypass covers only the read right after the write; a list resets it. Three limits I read in the code rather than measured: another token never gets the bypass, nothing invalidates on write, and on an upstream failure the server serves stale cache on purpose. Read-back through a cache lies in both directions, as I wrote in the write-safety piece. It still does.

State is what was verified, not what the model believes

The rule I want, and the one the paper does not have: an agent's state is not what the model reports. It is what the world confirmed. Every write tool on our server returns _mcp_policy.verification_required: true, except six fire-and-forget push tools. D's runtime turned that policy into a commit rule:

commit rule, enforced by the script, never by the model:
  1. the model proposes a patch: {"set": {...}, "delete": [...]}
  2. the runtime validates it: an unknown key, a wrong type or any touch
     of verified_fr, and the patch is rejected, state untouched
  3. an id enters verified_fr only after cms_get_article passes every check:
     exists, status draft, at least one paragraph, no residual delimiter,
     body length within 0.6 to 1.8 of the EN body
  4. a failed read-back commits nothing; the failure is the next observation
  a 200 on cms_create_article is not a commit. The read-back is.

On one article, 20 identical calls at temperature 0 on September 3 gave one distinct output; the eight offline checks I run on a translation, a different set from the five runtime checks above, caught all six faults I injected, and a status code would have caught none. Deterministic checks, not a 200.

Running that rule against our own server hit the same holes I had logged in August, and the September 3 cycles confirmed them. Ticket B: a delete returns only the policy envelope, no deleted, no id, no status. Ticket C: cms_create_article defaults to status: published, unchanged since May 13. Ticket D: a create on September 3 returned cms_get_article, cms_get_article_paragraph and cms_get_event as verification tools, the first three read tools in alphabetical order, while the tool plan points its verification call at cms_list_cms_sections. Follow the plan to the letter and you verify an article by listing sections; follow the envelope and you may end up reading an event.

The June draft reads differently now: an invalid state patch, created without verified, accepted by a run whose only witness is my memory. IDs, not vibes.

My scheduled tasks never had a memory

My scheduled Claude Code tasks had the triplet before I read the paper. Each starts from a fresh context: a daily ops review that reads Nagios and BuildBot, daily code reviews of two workspaces, a Monday glossary sentinel. From local transcript counters over August 1 to September 2, 2026: the ops review ran 30 times, median 25 turns, 49 uncached input tokens and 1,529,904 cache-read tokens per run, about 14 tool calls a run. The two code reviews, 23 and 29 runs, read 14,689,395 and 10,637,775 cache tokens per median run. The sentinel, 3 runs, 820,312.

A few dozen to a few hundred uncached tokens per run, and the cached prefix is the rest of the prompt: spec, then observation. Where is the state? In Nagios, in git, in the CMS: the system of record, never the agent. The paper's architecture, state pushed one layer down, no validator anywhere.

The sentinel is the closest thing I have to a validator. A cloud routine created on August 12 ran twice, both green; I replaced it on August 17 on a design argument, not an observed drift: a routine that rewrites its script each week is a moving specification. The replacement is a frozen script with 22 negative test cases, under version control; its four reports, August 17, 25, 31 and September 2, were all green on 170 pages in 89, 139, 116 and 166 seconds. The state is the sitemap. The validator is the test file.

The honest list

The paper's third limitation is the one I hit last month: when the task is the trajectory itself, throwing the history away destroys the work. My llms.txt forensic needed 121 days of logs and 1,321 requests to find 26 AI-labeled hits; the facts existed only in the sequence, and no crawler state schema would have held them. There, the log is not the memory. The log is the deliverable.

What the paper is not: synthetic-first, a strong horizon effect, a stateful baseline that pads the transcript with a state block rather than using LangGraph idiomatically, single-agent only. What our server has not shipped: any of it. No validator in front of any state file, no idempotency keys, no version-bound writes, no plan-then-commit object, no semantic span attributes, no token fingerprint column in the usage log. Tickets B, C and D were still open at our August 28 commit. D never finished.

What is cheap, and what I am doing next:

☐ Weigh your tools/list with count_tokens. Compare with 1,905.
☐ Log the four usage counters per turn.
☐ Schema and validator in front of the state file.
☐ Commit state after read-back; deterministic checks, not a status code.
☐ Freeze and version the spec.
☐ When the trajectory is the deliverable, keep a ledger.

What does your prompt look like at step 50, and who decided what goes in it? If you run a scheduled agent: where does its state live between runs, what validates it before the next run reads it, and how big is it in tokens? I am genuinely curious whether anyone has a schema in front of that file, or whether we are all editing JSON by hand and hoping. I will answer with token counts where I can.

There is no free lunch, especially in app publishing

Pierre- Laurent Medori — Tue, 01 Sep 2026 11:54:27 +0000

2009, mobile networks class. We were studying how TCP handles packets lost over 3G: the network detects the loss, replays the packet, and the transfer survives a radio link that drops things all the time. Someone asked the obvious question: why not just make the radio link reliable in the first place? The professor's answer became the soundtrack of that semester: there is no free lunch. Reliability over 3G is not free, it is paid for in retransmissions, latency and battery. The cost never disappears. It just moves to wherever you are not looking.

I now run engineering at a no-code app builder. Every pricing decision I have seen from the inside since, his sentence explains better than any business book.

Here is the version of it nobody puts on a landing page: you can build an app for free anywhere, and you can ship one for free nowhere.

The asterisk every vendor knows by heart

Search "free app builder". Every result promises an app for free. Every vendor behind those pages knows exactly where their free tier ends: right before the App Store and Google Play. Build for free, preview for free, then the store gates close and the pricing table appears.

I will not do the pricing comparison here. We published a dated, sourced table of what each major free tier actually includes on the company blog: Can you really create an app for free?. Spoiler: the pattern is identical across the market, and one competitor even admits in its own comparison that store publishing always requires a paid plan.

This post is about the side of the counter you cannot see from a landing page: what the word "published" costs the vendor. Because that is where the free lunch dies.

What "published" costs us, forever

A built app is a file. A published app is a commitment. From our machine room, that commitment looks like this.

The store treadmill never stops. Google Play raises its target API requirement every year. Apple killed UIWebView in 2020. The legacy push protocol died in March 2021. The Play Data safety form arrived in July 2022, Apple privacy manifests in May 2024. Each event means rebuilding and resubmitting fleets of apps through two review pipelines. Skip one deadline and apps disappear from stores. This work is invisible, recurring, and nobody can bill it to "free".

Runtime is real hardware. Our customers' apps call a backend every day. We run our own machines in racks in European datacenters. The CDN moves terabytes per day. Push delivery counts in millions of notifications per week. An engineer is on call all year; the status page is public (goodbarberstatus.com). None of this pauses when a customer pays zero.

A free plan that included native publishing would mean carrying all of the above, indefinitely, for free. Nobody in this market does it. That is not stinginess. That is arithmetic.

So who pays for your free plan?

The lunch is never free; the bill just moves. On a typical free app builder tier, you pay with:

Branding. Your app advertises its builder. Removing the badge is a paid feature, everywhere.
The wall. The upgrade prompt lands at maximum investment, minimum leverage. That timing is not an accident, it is the business model.
A link instead of a listing. Free "apps" are often web links. The store fees never trigger, and neither does the store presence you came for.
Your time. The expensive one. Rebuilding elsewhere because platform one could not ship is the worst deal in no-code.

And two line items belong to nobody's free plan because they are not the builder's to give: Apple charges 99 $ a year for a developer account, Google Play 25 $ once. A page that promises store publishing "for free" without those numbers is describing a demo.

In defense of free tiers

Said plainly, because my employer's competitors deserve fairness: free tiers are a great deal when your goal matches their content. Testing an idea on a real phone screen. Learning how a no-code editor thinks. Shipping a link to five colleagues. For all of that, use a free plan and pay nobody, including us.

The problem is never the free tier. It is the landing page that lets you believe the lunch stays free all the way to the App Store.

The menu with prices on it

GoodBarber has no free plan, and now you know the reason is structural, not commercial. Our trade is different: the full platform, free for 30 days, no credit card, including a PWA you can actually publish during the trial (what free really includes). When it ends, nothing is charged, because we never took a card. You have seen the real product and the real prices, and you decide.

No free lunch. But a menu with prices on it, and a table where you eat for 30 days before ordering.

Same lesson as those 3G retransmissions: the cost never disappears, so honest design shows you where it sits. You know what to expect, and the price is not hidden. In 2009 we would have called that a well-designed protocol.

Determinism Is a Feature

Pierre- Laurent Medori — Wed, 26 Aug 2026 08:31:29 +0000

We spent seventy years building machines that do exactly the same thing every time. It took about three years of AI hype to start describing that property as a limitation.

I keep running into the framing in threads, in pitch decks, in hallway conversations: deterministic systems as the old world, rigid, unimaginative, waiting to be disrupted by something that improvises. And every time, I want to push back with the least fashionable opinion I hold: determinism is not the boring baseline that AI liberates us from. It is the single most valuable property a production system can have, and 2026 is the year we are most eagerly trading it away.

Let me be precise about what this post is not. It is not an anti-AI post. I run an engineering team, and we run agents in production: they draft, they call tools, they touch real systems every day. I like this work. The argument here is not "don't use models". The argument is that the more probabilistic components you add, the more load-bearing the deterministic parts around them become, and that almost nobody is hiring, promoting, or celebrating for the second half of that sentence.

What determinism actually buys you

Reproducibility is not an aesthetic preference. It is purchasing power. Walk through what "same input, same output" quietly funds:

A reproducible bug is a bug that is already half fixed. You can trap it, shrink it, watch it happen in a debugger. A non-reproducible bug is not a bug, it is a haunting. You don't fix hauntings, you appease them: add a retry, widen a timeout, sacrifice a sleep(500) and hope.

A failing test means something. In a deterministic system, red means broken. The moment flakiness enters, red means "run it again", and the entire signal collapses. A suite that people rerun until it passes is not a test suite, it is a slot machine with CI minutes.

git bisect works. Bisect is a miracle we stopped noticing: binary-search across history and the machine tells you which commit broke the world. The miracle rests entirely on replay giving the same answer twice. Bisect over a component that answers differently each run is not debugging, it is astrology with version control.

A diff tells the truth. Code review works because a change in behavior is legible from a change in text. The whole social contract of "I read your PR, therefore I know what it does" assumes the text determines the behavior.

Incidents can be reconstructed. The 3 a.m. question is always "what exactly happened, in what order?" Every answer you can give assumes the system will tell the same story twice.

Notice the shape of that list. Testing, review, bisect, rollback, audit: essentially every practice we call "software engineering" is a child of determinism. It is not one nice property among many. It is the property the rest of the discipline is built on.

The bottleneck moved

Here is the economic argument, because the craft argument never convinces anyone in a planning meeting.

For most of my career, producing the artifact was the expensive part. Writing the code, the config, the migration, the docs. So that is where the effort, the tooling, and the prestige went.

That cost just fell off a cliff. Code, tests, configs, entire services: generating a plausible version of almost anything is now nearly free. And when the cost of production approaches zero, the remaining cost of software is the cost of verification. Checking that the plausible thing is actually true is no longer a phase of the project. It is the project.

The asymmetry is brutal. Generated output scales with compute, which gets cheaper every quarter. Verification scales with human attention, which does not scale at all. Every team I talk to is discovering the same imbalance: the pipeline that produces changes got a jet engine, and the pipeline that validates them still runs on the same few pairs of eyes it had in 2019.

So the scarce skill inverted. The valuable engineer of 2020 was the one who could produce faster. The valuable engineer of 2026 is the one who can look at something plausible and determine, efficiently and reliably, whether it is correct. Plausible is the commodity now. Correct is still artisanal.

Put the non-determinism where wrong is cheap

None of this means banning models from production. It means placing them deliberately, the way you place any component with a known failure mode.

A probabilistic component belongs where a wrong answer is cheap and checkable: a draft, a suggestion, a summary, a first pass that a cheaper process can validate. It does not belong holding your state, moving your money, or standing alone in front of an irreversible action.

The pattern that works is deterministic rails around a probabilistic core. And the rails are built from the least glamorous toolbox in the profession: schemas validated at the boundary, state machines whose enums make illegal transitions unrepresentable, idempotency keys so a confused retry collapses into one effect instead of two, version-bound writes so decisions made on stale data get rejected instead of applied, a plan-then-commit gate in front of anything with blast radius, and an append-only log so "what did the system do?" never depends on anyone's memory.

I wrote a whole article on the how of those rails at one specific boundary, agents writing to production systems: where each mechanism goes, what each one catches, what the server contract looks like. Consider this piece the why. Nothing in that toolbox was invented this decade, and that is exactly the point: it is decades of transactional common sense, redeployed at a new boundary, the line between a model and everything you care about. The model gets to be creative precisely because the rails are not.

Read it back before you believe it

I have a rule I apply to everything now, and it started long before agents: a system's report about itself is a claim, not a fact. Read it back before you believe it.

The agent says it published the article? Fetch the article through the same path a reader would, and look at it. The migration says it ran? Count the rows. The dashboard is green? Green means "the things we chose to measure are within the thresholds we chose to set", which is a much smaller statement than "everything is fine". Your own code from last year? Same treatment. The author being you buys it nothing.

For years this was a habit. Recently I understood it is actually a design requirement, and this is where it connects back to determinism: verifiability is a property you build in, not a virtue you exercise afterwards.

A deterministic system is cheap to verify. One run is proof; the test you wrote once keeps testifying forever. A probabilistic system can be made verifiable too, but not for free: you have to design the read-back paths, the invariants, the reconciliation jobs, the alert that fires when the report and the reality disagree. Skip that work and you have not built a system, you have built a story the system tells you about itself.

The question that changed how I build is not "does it work?" It is "how will I know it is still working when I am not watching?" A system that cannot answer that question is not finished, no matter what the demo looked like.

Boring is a career strategy

Ten years ago, Dan McKinley told us to choose boring technology: spend your innovation tokens on your actual problem, not on your stack. The 2026 version of that advice is one level deeper: choose boring properties. Determinism. Idempotency. Reproducibility. Auditability. The stack will change under you; the properties transfer.

Because here is the career math nobody puts on a slide. When everyone on the team can generate code, generating code stops being what distinguishes anyone. The floor rose; the ceiling did not move. What is scarce in a room full of people who can produce plausible artifacts is the person who can say "this is correct, and here is how I know", and have the second half of that sentence be load-bearing.

That skill compounds, too. The prompt tricks of last spring are already quaint. The ability to design an invariant, bound a blast radius, or smell a non-reproducible test has been appreciating since the seventies and shows no sign of stopping.

Nobody demos idempotency keys. Demos are generation; production is verification. The distance between the two is where reputations are quietly being made right now.

Ship the boring thing

The systems I trust all have the same personality: they do the same thing every time, and they can prove it. When I add a model to one of them, and I do, I add it where being wrong is cheap, with rails around it that never improvise.

Determinism is a feature. Some years I would have said an underrated one. This year I will go further: it is the feature, the one that makes all the others checkable.

Ship it. And read it back before you believe it.

What is the most boring thing in your stack you would defend to the death? Genuinely curious.

The Cows Don't Send Alerts

Pierre- Laurent Medori — Thu, 20 Aug 2026 08:45:06 +0000

My neighbor spent yesterday morning clearing a patch of maquis with a bulldozer. I watched him from the fence for a while, coffee in hand, contributing nothing. Then I walked down to check that the cows had water, because it's August in Corsica and that is the one job on this farm that cannot wait until later.

The rest of the year I do engineering at GoodBarber, a mobile app platform. This month, my production system is a herd of cows and a water trough.

This is not a burnout story. I'm fine, the team is fine, nothing is on fire. This is about something I re-learn every summer at my parents' farm and manage to forget again by October: disconnecting is not the opposite of engineering. It's where my engineering comes from.

The job I closed the laptop on

For the past few months my work has looked like this: agents that draft, publish and verify things through MCP servers, pipelines that touch production, and one rule I repeat so often my team can probably recite it in their sleep: grep and eyes. When an agent says it did something, you go read the actual output, with your actual eyes, before you believe it. And a human stays in the loop for anything that ships.

I like this work. A lot. Which is exactly why closing the laptop for two weeks felt harder than it should have. When you love the loop, you stop noticing you're inside it.

The farm

The heat arrives before you finish your coffee. By nine the cicadas are at full volume and they won't stop until dark; after a day you stop hearing them, a wall of sound your brain files under silence.

The maquis smells like it's cooking. Immortelle, myrtle, hot dust. When the bulldozer bites into it the smell turns sharp, crushed green and diesel, and my father comments on the neighbor's technique from three fields away.

The trough is a twenty-minute walk, morning and evening. You put your hand in the water, because looking is not enough: the surface can shine while the float valve sits jammed. The cows watch you do this with monumental indifference.The soft tick of the electric fence. On the way back you kick the same pine cone the whole length of the path, because there is nothing else to do. It takes a few days to understand that nothing else to do is the entire point.

My phone lives in the kitchen. Half the property has no signal anyway. Evenings are long: tomatoes that actually taste of tomato, a card game nobody remembers the full rules of, chairs on the terrace facing the dark. When the cicadas finally stop, the silence has a texture. The silence in my apartment is just a machine that hasn't beeped yet.

Distance gives you back your judgment

From the hill behind the house you can see the whole farm at once: which field burned yellow, where the fence sags, where the water runs and where it doesn't. None of that is visible from inside the barn.

For months my days were a hundred items deep. A flaky deploy. A graph doing something odd. An agent behaving strangely at 2 a.m. Every one of those items legitimate, none of them wrong to look at, and together they formed a wall between me and the only question that actually matters: what shape is the system, and where is it sagging?

Two weeks of distance, and the shape comes back on its own. Without opening a laptop, I can tell you the two things that genuinely worry me for the autumn. In June I couldn't have, and in June I had all the dashboards.

Judgment turns out to be a renewable resource with a single supplier: distance from the thing you're judging.

Hard bugs die in boredom

Every engineer carries one around: the bug that survives every fix. You fix it, it comes back wearing a different stack trace. Mine came on vacation with me, uninvited. They always do.

The answer did not arrive at a desk. It arrived on day six, somewhere between the trough and the gate, wet hands, no phone. I didn't write a line of code. I just finally saw it: the whole mechanism at once, including the part every previous fix had been politely stepping around.

Boredom without notifications is not empty time. It's the only state in which the complete model of a hard problem fits in your head, because nothing is evicting it every ninety seconds. A notification doesn't need to be answered to cost you. It only needs to arrive.

We talk about deep work as if it were a scheduling technique. I'd call it something simpler: it's what your brain does by default when nothing is allowed to interrupt it. The farm doesn't teach you to focus. It just stops preventing you.

Urgent is a word that means something here

On a farm in August, urgent is unambiguous. Cows without water is urgent. The smell of smoke on the wind is urgent. Everything else waits, and waiting costs nothing.

The cows don't send alerts, by the way. You find out how they're doing by showing up, twice a day, whether anything is wrong or not. There is probably a monitoring philosophy hiding in that sentence, but I promised myself I wouldn't write it on vacation.

Before leaving I skimmed the threads marked urgent across my inboxes. Dozens. I already know what I'll find when I get back, because it's the same every year: most of them will have resolved themselves, gone stale, or turned out to be someone else's adrenaline. What remains is the real work, and it was there all along, hidden in plain sight under the pile.

Here's the uncomfortable part: I can't tell the two apart while I'm in the pile. Nobody can. Up close, all urgency produces the same cortisol. Telling signal from noise takes distance, and you cannot acquire distance while you're busy responding. The 90% of noise was never a triage failure. It was the absence of the one tool that makes triage possible.

Grep and eyes, with actual eyes

Here is the thing I actually came to say.

Checking the trough with your hand because the surface can lie to you: that is grep and eyes. Walking the fence line instead of assuming it held: that is verification before belief. The rule I repeat to my team all year was not invented at a whiteboard. It was installed here, a long time ago, by people who never wrote a line of code and would never trust a report about anything they could go and check themselves.

The farm and the job run on the same values. Look with your own eyes. Keep a human in the loop. Know the difference between urgent and loud. I don't disconnect to get away from engineering. I disconnect to visit the place my engineering came from, and I come back with the judgment, the unstuck bug, and a short list of the things that actually matter.

The neighbor finished his patch of maquis yesterday. Where there was scrub there is now clean ground, ready for whatever comes next. Two more weeks and it's my turn.

The first thing I'll do back at work is not open a dashboard. I'll go look at the system with my own eyes.

Our MCP server is now a ChatGPT plugin

Pierre- Laurent Medori — Fri, 14 Aug 2026 12:06:29 +0000

GoodBarber is now listed in the ChatGPT plugin directory. Find GoodBarber in the directory, connect your app, and run it from the chat: content, catalog, members, push notifications. This post extends the announcement on our blog with the developer view, and it closes a loop we opened when we wrote up how we built that server.

One line of context for new readers: GoodBarber is a no-code app builder (running since 2011). Customers configure an app in a web back office; the platform compiles native iOS and Android builds plus a PWA. We built a public MCP server so that MCP clients (Claude, ChatGPT, Codex, Cursor, n8n and others) can operate those apps.

One server, two ways in

Nothing changed server-side. Both paths land on the MCP connection your app already has, scoped to that single app and authorized by you. What changed is the effort to get connected:

The official app in the directory. Find GoodBarber, connect, authorize access to your app. No Developer mode, no URL to paste.
The full GoodBarber MCP server as a custom connector. Enable ChatGPT's Developer mode and add https://mcp.goodbarber.dev/mcp/sse (the /sse is a route name; the server speaks Streamable HTTP). This is also the path for Codex: Settings, Integrations, MCP servers, leave the bearer token field empty and the save opens the OAuth flow in a browser.

The step-by-step for both lives on our setup page.

What the connection actually is

If you have read our write-up on building the server, you know the architecture. The short version:

One connection = one app. Each GoodBarber app has its own MCP URL with a unique app id; an agent authorized on app A cannot reach app B. You authorize the connection in a browser via OAuth; there is no API key to paste into the chat.
Writes are policy-flagged. Every write returns _mcp_policy.verification_required: true, so a well-behaved client reads back what it just changed before claiming success.
The tool surface is documented, not hardcoded. The authoritative list is the server card; what a given app exposes can be a subset, depending on its features and plan.

Our own tests, including the “Send my users a push about the spring sale.” example that opens the announcement, ran from a free ChatGPT account through the MCP connection: we drafted the push, confirmed it, and it landed on the test phones.

Why the listing matters

Building the server was engineering. Being found is distribution, and for an agent-facing product the distribution surface is inside the assistant, not on your marketing site. Until now, connecting GoodBarber to ChatGPT meant knowing the endpoint existed, enabling a developer toggle, and pasting a URL. That filters out almost everyone who would benefit. A directory listing replaces all of that with a search box: something a non-technical app owner can actually do, without reading a single setup doc.

What we do not control: how the directory surfaces or ranks apps. That side is OpenAI's.

For us, building the server turned out to be the easy half. The listing is what puts it in front of the people it was built for.

MCP 2026-07-28 from the server side: Codex already speaks it, Claude doesn't yet

Pierre- Laurent Medori — Thu, 13 Aug 2026 12:52:51 +0000

On July 28, the Model Context Protocol project shipped a new spec revision, 2026-07-28. I run backend engineering at GoodBarber, and our public MCP server is a live production surface: real apps, real content, real push notifications. So for us a new revision is not a changelog to skim on a Friday. It is a migration with our name on it.

We have just brought the server up to the new revision. This post is three things: the operator's cut of what changed, what upgrading a public server actually involves, and the thing we found in our logs while checking the work. The last one is the reason I'm writing.

The operator's cut of 2026-07-28

The headline is the stateless core. MCP grew up as a stateful, bidirectional protocol: an initialize handshake, a negotiated session, an Mcp-Session-Id header to carry it all. The new revision retires that entirely. Every request now self-describes in _meta: protocol version, client identity, capabilities. The practical consequence is the one server operators have wanted since day one: you can put an MCP server behind a plain round-robin load balancer with no shared session storage. If you have ever kept session affinity alive with duct tape, you know exactly which muscle just relaxed.

The rest, fast:

Method and tool names now also travel in Mcp-Method and Mcp-Name HTTP headers, so gateways can route and meter without parsing JSON bodies.
Multi Round-Trip Requests: a call can come back with resultType: "input_required" and continue over stateless connections. Mid-call questions no longer need a held-open stream.
List results (tools, prompts, resources) carry ttlMs and cacheScope, so clients can finally cache your inventory honestly instead of guessing.
Authorization hardening: RFC 9207 issuer validation, and Client ID Metadata Documents replacing Dynamic Client Registration.
Tasks, MCP Apps, and Enterprise Managed Authorization become formal extensions instead of core features.
Roots, Sampling, and Logging are deprecated, with a minimum twelve months of support before removal.

All four Tier 1 SDKs spoke the revision on launch day, which for a protocol this young is genuinely good release engineering.

Upgrading without breaking anyone

Here is the constraint that shapes everything when your server is public: you do not get to move your clients. Every agent that connects brings its own dialect, and you serve all of them or you break someone's production workflow.

So "upgrading" really means "adding a dialect". The old initialize path stays up for clients that expect it. The stateless path answers clients that self-describe. And one rule keeps the whole thing sane: the declared protocol version selects the behavior, never the client name. You would be surprised how tempting user-agent sniffing becomes during a migration. Resist it. The version declaration is the contract; the client name is trivia.

The other rule is older than MCP: nothing gets removed the day the spec says "deprecated". The spec gives Roots, Sampling, and Logging at least twelve months. The real clock is not the spec calendar. It is in your own logs, which brings me to the fun part.

Then we read the logs

We still verify upgrades the old-school way at GoodBarber: a human reads the code, and a human reads the logs. No dashboard, no pipeline, just grep and eyes. Last week that habit produced a whole article about llms.txt. It keeps paying for itself.

The protocol version a client speaks sits in plain text: in the initialize params for old-style clients, in the version declaration on each request for new-style ones. So during the development phase of the upgrade, we looked at who declares what on our traffic.

What we saw surprised us. Requests from OpenAI's Codex were already declaring 2026-07-28. The revision was barely two weeks old. Meanwhile, Claude clients were still opening with initialize on an earlier revision, exactly as they always had.

Let me be precise about what this is not. It is not a scoreboard. Pinning a revision and upgrading deliberately is what a well-behaved client does. Serving several revisions at once is what a well-behaved server does. Both populations got exactly what they asked for, which is the entire point of version negotiation.

But it is a data point you can only see from the server side, and it killed a lazy assumption I was carrying: that adoption of a brand-new revision would sit near zero for months, so supporting it "eventually" would be fine. In reality, part of your traffic may speak the newest revision before your migration branch is merged. And the split does not fall where intuition puts it: I would not have bet on which client family moved first.

If you run an MCP server

Four suggestions, all cheap:

Log the declared protocol version. One field per request. It is the cheapest telemetry you will ever add, and it is the only ground truth you have for deprecation decisions.
Test against real clients, plural. If you validate against a single vendor's client, you will quietly extrapolate that client's dialect to the whole world. Our logs contradicted our intuition within days.
Plan removals from your version distribution, not from the spec calendar. Twelve months is a floor, not a schedule. If a revision still carries real traffic, it stays.
Key behavior on the declared version, never on the client name. Negotiation is the contract you both signed. Honor it in both directions.

The upgrade itself was the unglamorous kind of work that never makes a launch post. But the logs made it worth a story: protocol adoption is happening faster, and more unevenly, than the discourse suggests, and every server operator is sitting on the evidence.

If you operate an MCP server: what does your version distribution look like? I am genuinely curious whether "Codex first" is universal or just our traffic.

One line on where I'm writing from: I run engineering at GoodBarber, an app platform. We run a production MCP server and publish open-source Claude Skills — so the 2026-07-28 migration is a live problem for us, not a thought experiment.

llms.txt in the wild: 1,321 requests, and not one AI assistant came looking

Pierre- Laurent Medori — Tue, 11 Aug 2026 12:31:16 +0000

We publish an llms.txt on our main domain and on every language portal. It is exactly what the proposal asks for: a curated markdown index of the site, at the root, written for AI systems to read. I pulled four months of nginx logs to answer one question: who actually reads it?

From April 7 to August 5, 2026, our front-ends served 1,321 requests to /llms.txt and /llms-full.txt across eleven hostnames (plus a few stray subdomains). About eleven a day, 92 percent answered with a 200. That volume already tells you this is not a busy interface. But the volume is not the story. The story is who those requests came from, because I went through every one of them, checked the interesting ones against published IP ranges, and the answer says something uncomfortable about the file, and something genuinely funny about the ecosystem around it. Ahrefs and Evil Martians have already counted this traffic at scale, and I will point at both. What I wanted was per-request forensics: when a hit wears an AI badge, is it real, and who sent it?

One line of context so you know where I stand: I run engineering at GoodBarber, an app platform. We run a production MCP server, we publish Claude Skills, we want the machine-readable web to work. This is not a takedown by someone who resents agents. It is a log review by someone who ships for them.

What llms.txt promised

Quick recap, then the data. llms.txt was proposed by Jeremy Howard in September 2024: a markdown file at your site root "to provide information to help LLMs use a website at inference time". Same placement logic as robots.txt and sitemap.xml. Mintlify made it a default for every docs site it hosts in November 2024, Shopify quietly shipped it to storefronts in spring 2026, and Originality.ai's tracker counted an 8.8x adoption jump in a year. On the publish side, the format is a success.

The open question was always the other side: does anything read it? Not "does anything fetch any file on the internet", because scanners fetch everything. Does the intended audience, the assistants and their crawlers, actually consume it?

Who actually reads our llms.txt

Here is the reader board for our 1,321 requests, by user-agent:

Reader	Requests	What it is
Generic browser user-agents, HeadlessChrome, WebPageTest agents, assorted scripts	~600	tools that did not bother introducing themselves
`satoric-indexer/0.1`	116	unknown indexer; even Ahrefs could not identify it
Googlebot	80	URL crawling, and Google says it ignores the file
`closing-web-clock/1.0 (+policy-surface observation)`	54	anonymous project observing "policy surfaces"; zero public footprint
SemrushBot SiteAudit	46	SEO audit tool
BuiltWith	44	tech profiler
`LLMS-Txt-Scanner/1.0 (Research)`	31	anonymous scanner on Azure IPs, self-labeled research
`AgentRadar-Research/1.0 (BCG Henderson Institute; agentic-web-research)`	29	identifies itself as a BCG crawler studying the agentic web; Evil Martians logged the same operator
`statespace-indexer/0.1`	27	agentic-web indexer; its likely parent repo was archived on August 5, 2026
`prompt-injection-survey/1.0 (research)`	21	self-described security research scanning llms.txt as an attack surface

SEO auditors, tech profilers, headless browsers, and a small zoo of research scanners. So far this matches what Ahrefs found across 137,210 domains in June (97 percent of llms.txt files got zero requests; of the traffic that exists, SEO audit tools are the biggest reader at 21.7 percent, AI assistants 2.5 percent), and what Evil Martians found in their own logs in July. Both are worth your time. Neither answered the question I actually had, which is why this post exists: when a request does carry an AI assistant's name, is it real, and did the assistant come on its own?

The 26 requests that wore an AI badge

Out of 1,321 requests in four months, exactly 26 carried the user-agent of an AI assistant or its crawlers. I checked each one against the vendors' published IP ranges (gptbot.json, chatgpt-user.json, searchbot.json, perplexitybot.json, and Anthropic's known blocks). They decompose like this:

Three were impostors. A single DigitalOcean IP requested our llms.txt three times in the same second, presenting as GPTBot/1.0, then PerplexityBot/1.0, then ClaudeBot/1.0. Bare version strings, none of the vendors' real UA formats, an IP in nobody's published ranges. Somebody's compliance checker cycling through bot costumes to see if we cloak (serve different content to bots than to humans). If you count assistants by user-agent alone, your llms.txt numbers include this.

Four were GPTBot, genuinely. All four IPs validate against OpenAI's published gptbot.json ranges. This is the interesting part, because all four requests carried a Referer header. Three referers were https://agentready.md, an AI-readiness checker that validates llms.txt files and runs a public leaderboard of them. The fourth was https://sitestatsdb.com, which I could not even inspect, because it now sits behind a bot-verification wall. GPTBot did not wake up wanting our llms.txt. It crawled third-party pages that link to our llms.txt, and followed the links like it follows any link. In four months and 215,484 GPTBot requests to our sites, the number of times it requested llms.txt without a third party pointing at it: zero.

I think this detail matters beyond our logs. Ahrefs found GPTBot to be the single biggest AI fetcher of llms.txt files (4.51 percent of requests) and concluded, correctly, that "Zero requests came from AI bots for llms.txt files that don't exist. They never go looking." Our referer data shows the mechanism behind both facts: an ecosystem of llms.txt directories and audit tools now links out to these files, and a crawler that follows links will follow those too. The training crawler "reads" llms.txt the way it reads any URL it encounters: as content, not as protocol. The llms.txt promotion ecosystem is generating the llms.txt consumption statistics.

Ten were ChatGPT-User. Azure IPs, half of them in the current published rotation (the list rotates, and these hits go back to April). ChatGPT-User is OpenAI's on-demand fetcher: it fires when a human asks ChatGPT something that requires opening a specific page. Ten requests in four months, each one meaning a human request was behind the fetch. Given what people use ChatGPT for these days, my honest guess is "check my site's llms.txt" prompts and GEO (generative engine optimization) audit tools, and I cannot rule out that some of those humans were us.

Two were ClaudeBot. Anthropic's crawler, from its usual 216.73.216.x block. These are the only two requests in the entire window where a dedicated AI crawler fetched the file with no referer and no human in the loop. Two, out of 262,242 ClaudeBot requests to our sites in the same period. Credit where due, and note what it is: the training crawler stocking a corpus, not an assistant consulting an index on a user's behalf. No user-facing assistant ever came on its own.

Four were Claude-User and three were Claude Code. Claude-User is Anthropic's on-demand fetcher, same story as ChatGPT-User: a human asked. The Claude Code hits are the most telling: Claude-User (claude-code/2.1.x) requests coming from a residential ISP line in France and a French cloud box. That is a developer at a keyboard pointing Claude Code at the file, quite possibly someone on my own team. It is also the one documented use case that actually works: a coding agent reading a docs index because a human told it to.

Meanwhile, in the same logs

Now the control group, because "assistants do not read llms.txt" could just mean "assistants do not read us". They read us plenty. Same window, same domains, AI bots only:

User-agent	Requests, all paths	Requests to /llms*, unprompted
ChatGPT-User	472,985	0 (10 user-triggered)
Meta-ExternalAgent	369,504	0
ClaudeBot	262,242	2
GPTBot	215,484	0 (4 via directory links)
OAI-SearchBot	171,121	0
PerplexityBot	63,475	0
Perplexity-User	22,667	0
Claude-User	19,324	0 (4 user-triggered)
Claude-SearchBot	17,512	0
DuckAssistBot	6,511	0
Claude-User (claude-code)	4,513	0 (3 user-triggered)

That is 1.6 million requests from AI systems in four months. ChatGPT-User alone made 89,668 blog-article fetches, about 740 a day, triggered by real people asking real questions; our most-fetched pages are deep technical pieces on app store compliance that classic SEO metrics would call worthless. The assistants are not ignoring our content. They are devouring it, hundreds of article fetches a day. And in the same four months, the file that exists specifically for them was fetched unprompted exactly twice, both times by the training crawler. Every other AI-labeled visit had a human behind it or a link in front of it.

And the ratio that settles it: Claude Code user-agents made 4,513 requests to our pages in four months. Documentation pages mostly, 2,264 hits on /help/ alone, plus 1,182 on the blog. Number of those requests that went to llms.txt: three. Even the archetypal llms.txt consumer, the coding agent that the strongest case for llms.txt is built on, overwhelmingly goes straight to the actual pages.

This is consistent with everything the vendors themselves publish, by the way. OpenAI's bot documentation explains robots.txt directives and never mentions reading llms.txt. Same for Anthropic's and Perplexity's. Google wrote it into its official AI documentation in June: "Google Search ignores them." Meanwhile all three AI vendors publish llms.txt files for their own docs sites, largely because their docs platforms generate one by default. Everyone is publishing the format. Nobody is committing to consume it.

John Mueller said it plainly back in April 2025: none of the AI services have said they use it, "and you can tell when you look at your server logs that they don't even check for it." Fifteen months later, on our logs, still true.

An object of research before an object of use

So who is left? Go back to the reader board. Once you remove the SEO auditors, the profilers, and the scripts, the most attentive readers of our llms.txt are research crawlers: an agent presenting itself as BCG Henderson Institute research on the agentic web, an anonymous LLMS-Txt-Scanner running from Azure, a closing-web-clock observing "policy surfaces", a statespace-indexer whose likely operator archived its repo the day before I wrote this, and my personal favorite, prompt-injection-survey/1.0 (research): a self-described survey of llms.txt as a prompt injection attack surface, because a plaintext file that sites voluntarily write for LLMs to ingest is, of course, a lovely place to plant instructions. All of this assuming their user-agents tell the truth, which, as the DigitalOcean impostor demonstrated, is optional. Ahrefs found the same pattern at scale: 12 percent of all llms.txt requests come from tools auditing, scoring, validating, or studying llms.txt itself.

The file has a thriving ecosystem of directories that list it, auditors that score it, scanners that catalog it, researchers that study it, and security people who probe it. Every layer of that stack is real and shipping. The one layer that does not exist is the consumer it was designed for.

llms.txt has become an object of research before ever becoming an object of use.

I want to be fair to the proposal here: nothing in the spec is wrong. It is a reasonable, well-designed answer to a real problem, context windows are finite and HTML is noisy. The assistants simply built around the problem instead: they fetch the real pages on demand, at scale, triggered by user questions. The protocol layer the file was supposed to occupy got filled by retrieval.

What I would actually do

My recommendation, which is what we do ourselves:

Keep the file if it costs you an hour. Ours stays. It is one hour of maintenance, it is harmless, and if a platform someday announces real consumption, you are ready. Google's official position is literally "won't harm (nor help)".
Keep it accurate, precisely because humans send agents to it. Every genuine assistant-family read in our logs, the two ClaudeBot fetches aside, had a human behind it or a link in front of it. Those are the readers you are writing for: a developer pointing Claude Code at your docs, a prospect asking ChatGPT to look at your file. Stale content there is worse than no file.
If you have developer docs, that is the one real use case. Coding agents directed at an llms.txt index do consume it (tooling like mcpdoc is built on exactly this). If your product has no docs for developers, your llms.txt is decoration.
Never report it as an AI-visibility deliverable. If someone bills you for "GEO optimization" and the deliverable is an llms.txt file, you now have four months of somebody else's server logs saying what that is worth. What actually got our content into assistants, per the same logs: deep, specific, technical articles that answer the questions people actually ask, plus a robots.txt that lets retrieval bots in.
Treat the file as code, not copy. Version-control it, restrict who edits it, keep it to plain links and descriptions. The most motivated readers of the format right now include people studying it as an injection surface. Do not give them material.

Check your own logs

Methodology, so you can replicate: 121 days of nginx access logs (April 7 to August 5, 2026) across our production hostnames, every request matching GET /llms, user-agents tallied, and every AI-labeled hit checked against the vendors' published IP ranges where they exist (OpenAI, Perplexity), and, for Anthropic, which publishes no list, against the blocks that carry its 262,000 other requests in the same logs. One caveat cuts both ways: user-agent strings are claims, not proofs. Our ~600 generic-browser requests surely hide a few interesting readers, and any study that counts assistants by UA alone, including this one before the IP checks, will overcount them. Could an assistant fetch llms.txt in stealth, hiding in those 600? In principle. But a vendor that cheerfully declares itself on 1.6 million fetches to the same servers has no evident reason to go incognito for this one file.

The whole analysis is a couple of grep and awk commands. If you publish an llms.txt, run them. The base rate says you will find silence; if you find an AI assistant that came looking on its own, unprompted, no referer, IP in the vendor's published range, I genuinely want to see that log line. Comments are open.

Your MCP write returned 200. Did the right thing actually happen?

Pierre- Laurent Medori — Thu, 06 Aug 2026 13:09:00 +0000

The failure mode that worries me most in agent tooling is not a crash. It looks like success.

An operator, somewhere, asks their agent to put the summer collection on sale. The agent discovers the products, loops over the variants, fires four hundred write calls, collects four hundred 200s, and reports back, confident and polite: "Done! All prices are updated." And they are. On the wrong collection.

Nothing in that transcript failed. The transport worked. The writes persisted. The agent did not hallucinate a single call. Yet the one thing the operator actually wanted, "the summer collection, on sale, nothing else", is not what happened. If you have shipped distributed systems you know this smell: every component is green and the system is wrong.

I run engineering at GoodBarber, an app platform, and our MCP server exposes a live production surface: content, commerce, push notifications, real apps with real users. So this is not a thought experiment for me. And judging by the comments on my last piece and the threads landing on r/mcp lately, it is not a thought experiment for many of us anymore.

Three different things we call "success"

When an agent reports "done", that word is doing a lot of undeclared work. Unpack it and there are three separate claims stacked on top of each other:

Transport success. The request arrived, the server answered, nothing threw. HTTP 200, no protocol error. This is the only one of the three the agent gets for free.
State success. The write persisted: the article exists, the price changed, the push is scheduled. This is what a verified read-back proves.
Intent success. What persisted is what the operator meant, within the policies of the account. The right collection. The right segment. The right amount.

Language models are spectacular at conflating the three. A 200 becomes "done"; "done" becomes "what you wanted". Not because the model lies, but because nothing in the loop ever represented intent explicitly, so the model reports the only success it can observe.

After my last piece, an engineer I traded notes with put the gap in one line I have not managed to improve on: given only transport success, the agent will "faithfully confirm the wrong thing." Confirmation is not correctness. A model that is perfectly honest about what it saw can still be wrong about what it did.

Where verified read-back stops

In my last piece I argued that an application MCP server should verify writes as a matter of server contract. On our server, every write result carries _mcp_policy.verification_required: true: the server itself instructs the agent to read the object back through the public read path and confirm the result before declaring success. I still believe every word of that. Read-back closes the gap between transport and state, and it catches the most common agent failure in the wild, which is declaring success on a write that never landed.

But I want to be honest about where it stops. Read-back proves the object changed the way the call said it would. It cannot prove the call was the right call. In the repricing story above, read-back passes four hundred times in a row. Wrong collection, verified thoroughly.

Necessary, not sufficient. That exchange, and those threads, shaped the list below: the layers that close the rest of the gap.

The layers that close the gap

None of this is exotic. Most of it is decades of transactional common sense applied at a new boundary: the line between a language model and your production system. Each layer kills one specific class of failure.

1. Scope the credential, not the prompt

"Please only touch the blog" is not a permission model. The prompt is reachable territory for anyone who can get text in front of your agent: a product review, a support ticket, a pasted document. If the prompt is the only thing standing between the agent and a tool family it should never use, you do not have scoping, you have a suggestion.

Scoping has to live where the prompt cannot reach it: in the credential. On our server that takes two forms. Sessions are bound by OAuth to a single app, so an agent connected to app A cannot discover that app B exists. And the tool list is generated from what the app has enabled: no shop, no shop_ tools; push not configured, no push tools. The families the agent must not touch are not denied, they are absent from the inventory. Billing, design, and the build pipeline are not on the surface for anyone. The server card is public if you want to see what a feature-gated inventory looks like.

What this buys you: a compromised or confused session cannot escalate. There is nothing to escalate into.

2. Idempotency, because agents retry

Agents retry. Clients time out and replay. Runtimes resume interrupted loops. In human API usage a duplicate submit is rare; in agent usage, retry-on-ambiguity is standard behavior, which means "the network blinked between the request and the response" must never be able to mean two pushes or two charges.

The first half of the answer is declarative, and MCP already has the vocabulary for it: tool annotations. Every tool on our card declares idempotentHint (along with readOnlyHint and destructiveHint): updates are marked safe to replay, creates and push are not, and the server-side failure policy the meta tool returns caps retries at exactly one. A client that respects the annotations will not loop a non-idempotent write on its own initiative.

The second half is where most surfaces, ours included, still have work to do: true idempotency keys on the non-idempotent writes. The mechanism transfers unchanged from classic API design: the client sends a key with the write, the server stores the outcome under that key, and a replay returns the stored outcome instead of running the write again. Stripe drilled this into a generation of engineers. MCP write tools need it for a bigger reason: the thing doing the retrying now improvises.

3. Bind the write to the version you read

Between the agent's read and the agent's write, the ground can move: another agent, a colleague in the back office, a scheduled job. A write built on a stale read should be rejected, not applied. The mechanism is old and boring: the write carries the version (or etag, or updated-at) of the object as the agent read it, and the server refuses with a conflict if the object has moved since. The agent re-reads and re-decides, with current facts.

There is a coarser flavor of precondition you can get for free at schema-design time: make illegal transitions unrepresentable. On our order tooling, the shipping-status enum only contains FULFILLED and DELIVERED, and the state machine runs one way. An agent cannot un-deliver an order, however confused it gets. If you do nothing else from this section, enum your state machines.

4. High-impact writes get a plan, then a commit

A draft article is a non-event; delete it and nothing happened. A broadcast push has no undo: our card marks it destructiveHint: true, idempotentHint: false, which is the formal spelling of "no undo, no retry". Bulk repricing touches four hundred objects in one intent. Above a certain blast radius, one-shot writes are the wrong shape entirely.

The shape that works is plan-before-commit. The first call returns a plan: what will change, how many objects, a sample of them, bound to the exact context it was computed in, with an expiry:

{
  "plan_id": "pl_9f27",
  "action": "reprice",
  "objects_matched": 412,
  "sample": ["Home Kit Hoodie 2026", "Away Kit Hoodie 2026", "..."],
  "bound_to": {
    "app": "my-shop-app",
    "object_set_hash": "sha256:c41d...",
    "tool_schema_version": "2026-07-01",
    "policy_version": 14
  },
  "expires_at": "2026-08-05T18:00:00Z"
}

Commit is a second call that references plan_id and fails if any binding moved: the object set changed, the schema changed, the policy changed, the plan expired. Between the two calls sits a human or an explicit policy, looking at "412 objects" and deciding whether that number matches the intent.

We are partway there in production and heading the rest of the way. Every tool on our server publishes its recommended discover, call, verify sequence through a meta tool (meta_get_tool_plan), and my own standing rule for push is send: "at", never now: the agent schedules, which leaves a review window between the ask and the broadcast. The plan object is where this converges, because "a number a human saw before commit" is the single cheapest defense against the wrong-collection story.

5. Verified read-back stays

Everything above is why read-back is not enough. None of it is a reason to drop read-back: it remains the floor. After every write, read the object back through the same read path anyone else would use, and compare against what was sent. It is the layer that catches the write that silently did not land, the truncation, the default that filled a field you did not send. Keep it, make it the server's contract rather than the client's memory, and stack the rest on top.

One requirement I did not fully appreciate until I ran this article's checklist against our own server: the read path you verify through must be read-your-writes consistent. While testing, I hit the mirror image of the 200-that-failed: a delete succeeded, and the immediate read-back served a seconds-stale cached copy of the object, so the verification step swore the delete had not happened. An agent following the discipline to the letter would have retried a write that had already landed, which is exactly the failure class layer 2 exists for. Read-back through a cache lies in both directions. Verify against the source of truth, or invalidate on mutation for the writing session.

6. Make the 200-that-failed observable

The nastiest property of an intent failure is that your telemetry approves of it. A standard span records transport: status code, latency, maybe payload size. It has no opinion about whether the business outcome matched the ask. On a default dashboard, the span for the wrong-collection repricing is indistinguishable from the span for the right one. All green.

The signal has to be emitted on purpose, in two places. In the tool result, where the agent can see it: a server-side outcome flag, plus the read-back requirement, so "it worked" is a claim the server participates in. And on the span, where your on-call can see it:

http.status_code     = 200          # transport: the easy part
mcp.write.readback   = "match"      # state: persisted as sent
mcp.write.outcome    = "ok"         # intent: preconditions held, plan honored

Then alert on the combination that matters: status 200 with an outcome that is not ok. That alert is the entire point of this post compressed into one rule: the failures worth paging on are the ones that returned success.

You do not remove the human. You move them.

It would be easy to read all this as "add friction everywhere", and that would be the wrong lesson. Draft states, scheduled sends, version conflicts and plan gates are all ways of sorting writes into two lanes: low-impact writes flow without ceremony, high-impact writes pause at exactly one place, the commit line.

That is not less automation. It is oversight spent where it changes the outcome. The content agents I run create drafts all day without me. Nothing reaches a user's lock screen without a human having seen the plan. Both of those sentences are policy, and I can defend each one, which is more than I could say for "the agent seems careful."

The checklist

Before an agent gets write access to a production system, you should be able to answer yes six times:

☐ Scoped: can this credential reach only the tool families this agent needs, with everything else absent from the inventory, not just denied?
☐ Idempotent: does the same write, retried, produce one change instead of two?
☐ Version-bound: does a write built on a stale read get rejected instead of applied?
☐ Previewable: do high-blast-radius writes produce a plan that a human or a policy approves before commit?
☐ Read-back verified: is post-write verification part of the server contract, not client etiquette?
☐ Semantically observable: would a 200 that did the wrong thing show up on a dashboard, or only in a customer email?

Six noes is a demo. Six yeses is something you can hand to a customer.

Takeaway

Getting an agent to call your write tools and collect 200s is the easy 80 percent, and it is the part every MCP server demo shows. The remaining 20 percent, making sure the right thing happened and making it survivable when it did not, is unglamorous server work: scopes, keys, versions, plans, read-backs, span attributes. It is also, I think, where production MCP surfaces will actually differentiate from here on.

The surface these notes come from is documented at goodbarber.com/mcp if you want to see the choices in context.

What is in your write-safety stack that I missed? Genuinely curious. The comments on the last piece made this one better.

I gave an AI agent the keys to a live production app: here's the MCP setup

Pierre- Laurent Medori — Fri, 31 Jul 2026 13:21:47 +0000

AI agents are good at writing code. What they mostly cannot do is operate the software you already run in production: publish the article, schedule the push, fulfill the order. Not because the models are incapable, but because most production apps expose no structured surface an agent can act on.

MCP fixes exactly that. This post is the hands-on setup I use to let an agent operate a live mobile app: real endpoint, real tool calls, real payloads, and the gotchas I hit.

Disclosure up front: I run engineering at GoodBarber, an app platform, so the production app in this post runs on our MCP server. The patterns transfer to any remote MCP server you point an agent at.

Connect it

The server is a hosted remote MCP server. No npx, nothing local to run:

https://mcp.goodbarber.dev/mcp/sse

The /sse path is historical; the server answers both SSE and Streamable HTTP, so every current client works.

Claude Code:

claude mcp add --transport sse goodbarber https://mcp.goodbarber.dev/mcp/sse

or in .mcp.json:

{
  "mcpServers": {
    "goodbarber": {
      "type": "sse",
      "url": "https://mcp.goodbarber.dev/mcp/sse"
    }
  }
}

Claude (claude.ai): Settings, then Connectors, then add a custom connector with that URL.

ChatGPT: Settings, then Apps & Connectors, enable Developer mode, create a connector with the same URL. Write actions worked on a free account when I tested it; OpenAI's docs gate some of this by plan, so verify on yours.

Codex: add a custom MCP server, transport Streamable HTTP, leave the bearer token field empty. Saving opens the OAuth flow.

The first tool use triggers OAuth in the browser: you sign in with the app's account, and the session is scoped to that single app. No API key to paste anywhere. That scoping does a lot of security work later.

After OAuth, the client pulls the tool list. What the agent sees is not "the API": it is an operations menu, namespaced by domain. The cms_ tools cover articles, events, and media. The shop_ tools cover products, variants, orders, and promo codes. The classic_ tools cover push, analytics, and memberships. The full inventory is public in the server card, which is the file to read before writing any client code:

https://mcp.goodbarber.dev/.well-known/mcp/server-card.json

First real call: schedule a push

Push is the scariest operation to hand an agent (a sent push has no undo), which makes it the best test of a server's design.

Me, in the chat:

Schedule a push for 6 PM tonight: "Doors open at 7. First 50 people get the poster."

The agent calls classic_create_push_broadcast:

{
  "message": "Doors open at 7. First 50 people get the poster.",
  "send": "at",
  "send_at": "2026-07-29T18:00+02:00"
}

Three details in this schema are worth noticing:

message is capped at 255 characters server-side, so the agent gets a hard error instead of a silently truncated push.
send is an enum, now or at; scheduling requires the timezone-aware send_at, and the tool handles the UTC conversion. The agent does no date math.
The tap action is structured too: action_type is one of open_app, external_link, or section. "Open the tickets section" resolves to a real section id, not a guessed deeplink.

The result comes back confirming the scheduled send, along with something rarer: a policy block. Every write on this server returns _mcp_policy.verification_required: true. The server's own guidance tells the agent to read back what it just wrote before declaring success. There is even a meta tool for this: meta_get_tool_plan takes a tool name and returns the recommended discover, call, verify sequence plus the failure policy. Agents follow instructions embedded in tool results remarkably well; putting that discipline server-side beats hoping every client prompt remembers it.

Operate the app: one call per domain

Publish an article (CMS). cms_create_article wants a title and category ids, and category ids come from cms_list_cms_sections first. Discover, then write:

{
  "title": "Matchday guide: what to know before Saturday",
  "categories": [4821],
  "status": "stock",
  "publishedDate": "2026-08-01T08:00:00+02:00"
}

status is published, draft, or stock; a future publishedDate requires stock, which is the scheduled state. Body content is its own resource: cms_create_article_paragraph, one call per paragraph, with cms_reorder_article_paragraphs when the agent restructures. There is also an accessTier field (free or premium) that hooks straight into the app's paywall.

Add a product and a variant (shop). shop_create_product first:

{
  "title": "Home Kit Hoodie 2026",
  "status": "DRAFT",
  "collections": [312]
}

then shop_create_variant:

{
  "product_id": 88410,
  "price": "49.00000",
  "stock": 120,
  "sku": "HK26-M",
  "option_values": [{ "option_id": 17, "value": "M" }]
}

Two things I like here. price is a decimal string, not a float: whoever wrote this schema has met floating-point money. And the variant model is strict: all variants of a product must share the exact same set of option_ids, so introducing a Size option on one variant forces you to define it on all of them. That is a real invariant of the commerce domain, enforced at the tool layer. A raw database connection would let your agent violate it silently.

Look up and update an order (fulfillment). shop_list_orders filters by status and date range. shop_update_order_shipping moves an order along a one-way state machine, PENDING → FULFILLED → DELIVERED, with optional tracking:

{
  "order_id": 55231,
  "status": "FULFILLED",
  "shipping_tracking_num": "6A0301234567",
  "shipping_tracking_url": "https://tracking.example.com/6A0301234567"
}

The status enum only contains FULFILLED and DELIVERED. You cannot un-deliver an order through this surface, however confused the agent gets.

Pull the numbers (analytics). classic_list_downloads and classic_list_page_views take plain ISO date ranges and return aggregates. The stats family is read-only by construction; there is nothing to break. My standing Monday ask is one sentence: last week's downloads and page views versus the previous week, flag anything odd.

The security model (the part that actually matters)

This is what I would look at before connecting an agent to anything in production:

OAuth per app, not per account. The session is scoped to a single app. Connect App A and the agent cannot tell App B exists. Agencies operating many client apps add one connection per app; there is a per-app URL form for that, on a white-label domain if you resell.
Feature-gating shapes the tool list. The tools exposed are a function of what the app has enabled. Connect an app with no shop and the shop_ namespace is simply absent; push not configured, no push tools. The agent cannot call what it cannot see. Corollary if you write client code: never hardcode the tool list, read it at connect time or from the server card.
Verify-after-write is server policy, not client etiquette. The _mcp_policy block rides on every write result.
No design surface. Nothing in the inventory touches layout, navigation, or the build pipeline. The blast radius of a bad agent day is content, campaigns, and commerce state, all inspectable in the back office. Not the app itself.

Skills: the recipes layer

On top of the server, there is an open-source repo of 44 Skills: markdown recipes in the Claude Skills format, one per workflow (create a product with variants, schedule a push campaign, process the morning's orders, and so on). They encode the discover-then-write sequences above so the agent does not rediscover them every session:

https://github.com/goodbarber/goodbarber-skills

The terms allow rebranding and redistribution; they were written for resellers. The server itself is proprietary. The recipes are the open part.

Trade-offs and gotchas

Things I would want to know before recommending this to another engineer:

The tool list varies per app. A tool name from a tutorial (or this post) may be absent on your app because the feature is off. Check the list, not the docs.
Conversational operations do not batch. Three hundred products means three hundred shop_create_product calls. Bulk import stays a back-office job; the agent shines on the daily delta, not the migration.
Verify-after-write costs round trips. A multi-step ask (product, three variants, launch push) runs tens of seconds, not milliseconds. That is deliberate, and the right trade for writes on a live app.
IDs, not vibes. Agents guess names when you let them. Make them discover first (cms_list_cms_sections, shop_list_products); meta_get_tool_plan returns exactly that sequence per tool.
Keep a human on send. My own rule: the agent schedules pushes with send: "at" rather than now, so there is always a review window between the ask and the broadcast.
One app per connection. A multi-app morning means multiple connectors. Scoped beats convenient.

Takeaway

Everyone is racing to make agents build software. The quieter and, I think, more useful shift is agents operating the software you already have. Building is a one-time event. Operating is every day.

If you want to poke at a live implementation: the server card is public, the Skills repo is open, and the non-dev version of this story lives at goodbarber.com/mcp.

Not all MCP servers are equal: BaaS MCP vs application MCP

Pierre- Laurent Medori — Wed, 29 Jul 2026 13:10:29 +0000

Every platform now advertises an MCP server, and the label tells you almost nothing. Two servers can carry the same three letters and hand an AI agent completely different powers: one gives it your database, the other gives it your live app. Here is the difference between a BaaS MCP and an application MCP, and why that altitude decides what an agent can actually do for you.

"Has an MCP server" is the wrong question

The short version. An MCP server is only as useful as what it exposes. BaaS platforms such as Back4app and Supabase expose their backend: database tables, schemas, queries, cloud code. GoodBarber's MCP server exposes the operations of a live mobile app: publish an article, schedule a push, update the catalog, read the stats. 150 domain-typed tools at the time of writing, feature-gated, scoped to one app by OAuth, with a verified read-back on every write. Same protocol, very different altitude.

The Model Context Protocol has won fast. Introduced by Anthropic in November 2024 and donated to the Linux Foundation a year later, MCP is now the standard way to hand tools to an AI agent, with more than 9,400 public servers listed in the official MCP Registry in 2026. Which means the phrase "we have an MCP server" has quietly become a checkbox. Every platform can tick it, and the tick tells you nothing.

The questions that matter sit one level deeper. What does the server let an agent see? What does it let an agent change? And when the agent writes, what stands between a well-phrased prompt and a broken production system? The answers depend far less on the protocol, which is the same for everyone, than on the altitude at which a platform plugs into it.

Two altitudes: MCP for your database, MCP for your app

Backend-as-a-Service platforms plug MCP into their infrastructure layer. Back4app's MCP server, as its documentation describes it in July 2026, lets an agent create and manage Parse apps, define database schemas, query and modify objects through the Parse REST API, manage users and permissions, and deploy cloud code. Supabase's official MCP server points the same way: list tables, execute SQL, run migrations, manage branches and Edge Functions. These are real, useful capabilities. They are also unmistakably backend-shaped: what the agent reads and writes are rows, schemas and deployments. Call it MCP for your database.

GoodBarber plugs MCP in at a different altitude: the application itself. GoodBarber's MCP server exposes the operations of a finished, published mobile app: publish an article, schedule a push notification, create a product with its variants, update an order, read the analytics. The agent never sees a table. It sees the same product-level actions the app's owner sees in the back office. Call it MCP for your app.

A BaaS MCP hands an agent the keys to your data. An application MCP lets an agent run your product, safely.

Side by side:

Dimension	BaaS MCP server	Application MCP server
What the agent sees	Tables, schemas, rows, cloud functions	Articles, push campaigns, products, orders, stats
A typical tool	Run a SQL query, create a database class	`cms_create_article`, `classic_create_push_broadcast`
A write is	A raw data mutation	A product action, run through the application layer
Guardrails	Read-only modes, project scoping	Feature gating, per-app OAuth, verified read-back on every write
Built for	Developers in AI coding tools	Any operator, technical or not, in any MCP client
Examples	Back4app, Supabase	GoodBarber

Why the altitude changes everything

Same protocol, same JSON, same agents on the other end. Four things change completely.

Semantics: the agent knows what it is doing

A backend tool speaks data. An application tool speaks intent. When an agent's tool is a raw SQL query, the agent knows it is inserting a row; whether that row makes sense as a product, a subscriber or a campaign is entirely the prompt's problem. When an agent calls classic_create_push_broadcast on GoodBarber's server, the tool's name, its typed schema and its constraints already encode what a push campaign is. There is far less room to be confidently wrong, because the domain knowledge lives in the tool, not in the prompt.

Safety: where the guardrails live

Good BaaS MCP servers do ship controls, and they matter: Supabase, for instance, offers a read-only mode and project scoping. But at database altitude, a permitted write is still a raw mutation. Nothing checks that the new row respects the invariants your application enforces everywhere else.

GoodBarber's MCP server enforces its guardrails at the product level, on the server side. Feature gating: a tool only exists if the matching feature is active in the app, so an app without push configured exposes no push tools at all. Per-app OAuth scope: every session is bound to one authenticated app, an agent connected to app A cannot see or touch app B, and agencies connect each client app separately. Verified writes: every write returns a server-side flag requiring the agent to read the object back and confirm the result before moving on. Hallucinated success is the failure mode agents are most prone to; GoodBarber's answer is to make verification part of the server's contract rather than a best practice left to the prompt.

Completeness: a database is not a product

An agent with full control of your backend still controls no product. The mobile app around that backend remains yours to design, build, connect, submit to the App Store and Google Play, and maintain: exactly the gap we mapped in AI app builders can build an app. Can they run one? An application MCP starts on the other side of that gap. The app already exists: compiled native iOS and Android builds plus a PWA, with hosting, CMS, push infrastructure and payments included rather than assembled from separate subscriptions. The agent operates a live product from day one, and there is nothing left to build around it.

Operators: who can actually use it

Back4app's MCP documentation lists the clients it is built for: Cursor, Windsurf, VS Code, Claude Code. Developer tools, reasonably, because driving a backend safely requires a developer's judgment. An application MCP moves the interface up to plain language. A shop owner can ask Claude to reprice a product, a publisher can ask ChatGPT to publish the morning's article and schedule the push, a club manager can ask for last month's downloads, and none of them needs an IDE. GoodBarber built its MCP surface for that operator, the same person its no-code back office was built for, and it works from any MCP client, including automation platforms like Zapier.

What GoodBarber's MCP server exposes

GoodBarber runs a hosted, production MCP server: nothing to install, nothing to self-host. You plug the endpoint into your MCP client, sign in with OAuth 2, and the session is scoped to your app from the first call.The inventory is public and machine-readable. The server card lists 150 domain-typed tools at the time of writing (July 2026), namespaced by what they operate: tools prefixed cms_ cover content (articles, events, maps, photos, videos, podcasts, including scheduled publication), shop_ tools cover commerce (products and variants, collections, orders, promo codes, customers), and classic_ tools cover the running of the app (push broadcasts, analytics, memberships). The card is the contract: when the platform grows, the card grows, and connected agents pick up the new tools automatically. On top of the server, GoodBarber publishes 44 open-source Claude Skills that wrap common workflows as tested recipes, part of the same agent-ready platform push.

Just as deliberate is what the server does not expose. Design and layout stay in the builder, where GoodBarber's design system can protect them; pushing visual design through text-shaped tools does not produce good apps. And agent ready does not mean the human left the room: you grant the scope, you set the policies, and the server verifies what the agent does. Details and per-client setup live on the MCP page.

When a BaaS MCP server is the right choice

If you are a developer building custom software, with your own data model, your own business logic and your own frontend, a BaaS MCP server is exactly the right tool, and the good ones are genuinely good. Back4app's gives your coding agent a real Parse backend to build against; Supabase's does the same for Postgres, with scoping controls that show the category maturing. GoodBarber is not that tool and does not try to be: it will not host your custom backend, and it is built for content apps and mobile commerce, not for arbitrary software.

These are two altitudes for two different jobs, not two competitors on one axis. The practical test: if your project needs an agent that can touch raw data structures, you want a BaaS MCP. If it needs an agent that can run a live mobile app, you want an application MCP.

Which MCP server does your project need?

You are building custom software and want an agent working on your schema, data and cloud code: choose a BaaS MCP server such as Back4app or Supabase.
You want an agent to operate a real mobile app in production, across content, catalog, push notifications, orders and analytics: choose an application MCP server. That is what GoodBarber runs.
The app's day-to-day operator does not code: an application MCP is the only altitude that works in plain language from mainstream clients like Claude and ChatGPT.
You need both: some teams run them side by side, a BaaS MCP for the custom system a developer maintains, GoodBarber's MCP server for the mobile app the business operates. The protocol is the same; only the altitude differs.

FAQ

What is the difference between a BaaS MCP server and an application MCP server?
A BaaS MCP server exposes backend infrastructure to an agent: database tables, schemas, queries, cloud functions. An application MCP server exposes the operations of a finished product. GoodBarber's MCP server lets an agent publish content, schedule push notifications, manage a catalog and read analytics on a live mobile app, without ever touching raw data structures.

Does GoodBarber's MCP server give an agent access to my database?

No. GoodBarber's MCP server exposes product operations, not SQL. An agent works with articles, products, orders, push campaigns and stats through domain-typed tools, and every call runs through the same application layer as the back office, so business rules and validations apply. Raw table access is never on the menu.
Is an MCP server on a backend enough to run a mobile app?
No. A backend MCP server operates the data layer, and the app around it still has to be designed, built, connected, submitted to the App Store and Google Play, and maintained. An application MCP server operates an app that already exists. That is the difference between managing rows and running a product.

How does GoodBarber keep agent writes safe?
Through three server-enforced layers. Feature gating: a tool only exists if the matching feature is active in the app. Per-app OAuth scope: an agent connected to one app cannot reach another. Verified writes: after every write, the server requires the agent to read the object back and confirm the result. Safety lives on the server, not in the prompt.

What is the best MCP server for a no-code mobile app?
Judge any candidate on three criteria: tools that speak the app's language rather than raw SQL, authentication scoped to a single app, and server-enforced verification on writes. GoodBarber's MCP server checks all three, with 150 domain-typed tools at the time of writing and a public server card listing every one of them, so you can verify the inventory instead of taking the claim on faith.

See the altitude difference for yourself. Start a free trial, build your app, then plug its MCP endpoint into Claude, ChatGPT or any MCP client: connecting an agent to a live app takes about two minutes. The complete MCP guide covers setup client by client.

In-app purchases without writing StoreKit or Play Billing: selling subscriptions inside your app

Pierre- Laurent Medori — Mon, 27 Jul 2026 08:08:47 +0000

Selling a subscription inside a mobile app is one of the most demanding things you can build: StoreKit on iOS, Google Play Billing on Android, server-side receipt validation, renewals, refunds. Or, on our platform, one toggle. This post explains what that toggle actually hides, and the honest trade-off that comes with it, because there is one and it is not small.

Quick context: GoodBarber is a no-code app builder running since 2011; the platform compiles native iOS and Android apps for people who will never open Xcode. Some of those people live from their content. This is the machinery that lets them charge for it.

What in-app purchases are for (and not for)

In-app purchases sell access to digital content inside the app: premium articles, videos, podcasts, courses, members-only sections. On our platform that takes the form of subscriptions, monthly or annual, and it exists for Content Apps published as native iOS and Android builds.

What in-app purchases are not for: selling physical goods. That distinction is not a product choice, it is store law. Apple and Google require in-app purchase for digital content sold inside an app, and forbid it for physical goods and real-world services, which must go through a regular payment gateway. So an app that sells t-shirts checks out through Stripe or PayPal, and an app that sells premium podcasts checks out through the App Store and Google Play. Two different rails, two different cost structures, and no way to swap them.

Keep that in mind for the rest of this post: everything below is about the digital-content rail. The e-commerce rail is a separate module with separate economics (no store cut, standard processor fees). Mixing the two up is the single most common confusion in this topic.

When is the in-app rail the right call? When your audience is mobile-first, your product is content, and your growth depends on people subscribing at the exact moment they hit your paywall. Which is precisely the moment a payment form kills.

Why this is the hardest checkout in mobile

Here is what "selling a subscription in your app" means when you build it yourself:

Two APIs, two lifecycles. StoreKit on iOS and Play Billing on Android are separate systems with separate product models, separate testing sandboxes and separate failure modes. You implement everything twice.
A server you now operate. Purchases must be validated server-side: the store issues a receipt or purchase token, and your backend has to verify it, or your paywall can be bypassed. That means running a service, storing entitlements, and keeping it up for as long as you have subscribers.
A state machine that runs for years. A subscription is not one transaction. It renews, fails to renew (card expired), enters grace periods, gets cancelled, gets refunded, gets restored on a new phone. Every one of those events must reach your server and flip content access accordingly, or you have paying users locked out and free riders let in.
Store-specific edge cases. Restore purchases is mandatory on iOS. Refund handling differs per store. Review teams check your subscription UX against their guidelines.

None of this is exotic for a payments team. All of it is a wall for a creator, and a serious multi-week project for a developer doing it once. It is the hardest checkout in mobile because it is not a checkout: it is a long-running billing system with two masters.

What happens behind the toggle

On our side, the creator's job is to define the offer in the back office: the subscription products, monthly or annual, and the price for each store, because the App Store and Google Play each have their own pricing grids and currencies. Then they turn the feature on.

To be precise about what "we handle the rest" means: it is not one big automation. Behind the toggle there is software and there is a team, splitting the list from the previous section:

The billing machinery is software. Server-side receipt and purchase-token validation runs on infrastructure we already operate. Renewals, grace periods, cancellations, refunds and restores are processed and wired to content access: a subscriber sees the premium content, a lapsed one stops seeing it, with no code written by the creator.
The store side is our app-store experts. The creator's configuration drives the product setup with Apple and Google and the submission work around it, carried by the same team that publishes and maintains apps in the stores all day. Store-specific edge cases, and the drift of StoreKit and Play Billing over time, land on their desk, not the creator's.

One toggle on the creator's side does not mean one script on ours; it means the complexity moved to people and systems whose job it is.

For the end user, the entire experience is one tap on the store's native payment sheet. No form, no card number, no new account. The store already has their payment method on file.

The fine print, because a toggle this clean has some:

it is for Content Apps published as native builds, not PWA-only plans, and not eCommerce Apps (different rail, as covered above);
it sells subscriptions, monthly or annual, not one-time unlocks or consumable credits;
subscription access is binary: subscribers see the premium content, everyone else sees the public content. It also replaces the standard login flow; an app uses one or the other, and the back office makes you switch deliberately.

Very few no-code builders ship native in-app purchases at all; the usual answer is a plugin, a third-party billing service, and a validation server that becomes your problem. Shipping it as one toggle is rare, and it is one of the features we consider a signature.

The honest trade-off: the store cut

Apple and Google take 15% to 30% of every in-app subscription. Where you land in that range depends on their programs and your history: the small-business tiers, subscription retention past the first year. That cut is real money, and any article that shows you the toggle without the cut is selling you something.

GoodBarber adds no commission on subscriber revenue: the platform is flat-rate subscription pricing, and what your subscribers pay is yours, minus the store's share. But the store's share is structural. It is not our fee to waive; it is the cost of being on the rail.

So why accept it? Because of what the rail buys: the highest-converting checkout that exists on mobile. The user is already authenticated with the store, their card is on file, and the purchase completes in one tap at the exact moment of intent. Compare that with sending a mobile user to a web page to type a card number: conversion drops sharply, and the drop routinely costs more than the cut. The store cut is not a tax on the feature; it is the price of the smoothest checkout in mobile.

In-app or web checkout: how to choose

The alternative is legitimate: sell the subscription on your website, keep your full margin minus processing fees, and let subscribers sign in inside the app. Regulators and courts have also started forcing the stores to loosen their rules on external purchase links in some regions, so the legal ground is moving. The physics, so far, are not: a web checkout still asks a mobile user to leave the app and fill a form.

A short decision grid:

In-app wins on volume. Mobile-first audience, impulse subscriptions at the paywall moment, price points where 15-30% is absorbable: the conversion uplift usually outweighs the cut.
Web wins on margin. High-ticket subscriptions, an audience you already convert on the web, thin margins where the cut genuinely hurts.
Most creators are not choosing a religion. They are choosing a default for where their audience actually subscribes, and for a content app, that is usually inside the app.

If you are evaluating no-code platforms for premium content, here is the one question that sorts the field: who validates the receipts? If the answer involves you, a plugin and a server, you now know what you are signing up for.

Questions in the comments. happy to go deeper on the billing lifecycle or the store-specific quirks.

No-code at scale: Why the real engineering challenge is the treadmill, not the editor.

Pierre- Laurent Medori — Tue, 21 Jul 2026 07:52:11 +0000

"No-code" sounds effortless. Configure your app in a browser, hit publish, done. And that is exactly how it should feel, for one app, seen from the outside. Keeping thousands of no-code apps alive and published, for years, is another job entirely. This post opens the machine room: hosting, push delivery, store submissions, and the maintenance treadmill running underneath.

Quick context: GoodBarber is a no-code app builder running since 2011. Customers configure an app in a web back office; the platform compiles native builds (Swift for iOS, Kotlin for Android) plus a PWA, and operates everything those apps need at runtime. That last clause is the subject here.

What "at scale" means for a published app

The demo problem and the production problem are different problems. Any stack can produce one app that works today. A published app is a longer commitment: a binary sitting in two stores behind two review processes, a backend it calls every day, push credentials that expire, an OS release every year and store policies that move under your feet.

Scale, in our case, as of mid-2026:

thousands of live apps in production;
one download every 4 seconds across the fleet, about 20,000 a day and 8 million a year (measured over 29 days in April 2026);
paying customers in 152 countries;
a platform running since 2011, so "long-term" is measured in OS generations, not in sprints.

The operative definition of scale is multiplication. With one app, a store policy change costs you an afternoon. With thousands, every external change becomes a fleet event: whatever Apple or Google decides this quarter, multiply it by every app in production. The entire architecture below exists to make that multiplication survivable.

The infrastructure nobody sees

Hosting. GoodBarber is its own hosting provider. We rent rack space in large European datacenters and run our own machines there: several racks of hardware, not a tenancy on someone's hyperscaler. The backend is multi-tenant: thousands of apps share the platform's services, each with its own content, configuration and API surface, and the CDN in front of it moves several terabytes a day. Running the hardware ourselves keeps the data question short (one company, one jurisdiction, servers in Europe) and puts capacity planning where it belongs: on us, once, instead of on thousands of individual app owners.

Push, at volume. The platform delivers several million push notifications a week. The app owner's view of that sentence: write the message, pick the audience, send now or schedule. Everything else is ours:

fan-out to APNs and FCM, with per-app credentials provisioned and rotated;
device-token hygiene: tokens die constantly (uninstalls, device restores, OS reinstalls), so delivery responses have to be consumed and dead tokens pruned, or delivery rates rot silently;
payload limits, throttling, retries, and the scheduling queue that turns thousands of "send at 9am" campaigns into synchronized bursts of individual deliveries.

Reliable push is a data-hygiene problem at least as much as a throughput problem. The throughput is bursty and predictable; the token decay never stops.

Store submissions, handled by people who do it all day. A dedicated publication team submits and maintains apps in the App Store and Google Play. The baseline that team works against: Apple rejects approximately 42% of first submissions (measured across the submissions our team handled over the last 12 months; that is Apple's baseline, not our failure rate). The team recovers 91% of those first-submission rejections. On updates, upstream prevention work makes rejections rare in the first place. App review is not an API call that returns 200; it is a negotiation with guidelines that shift, and it goes measurably better when it is somebody's full-time job.

The treadmill: what a platform absorbs

An app left alone degrades. Not because its code changes, but because everything around it moves. A sample of what "around it" has meant, with dates:

Every year: Google Play raises the required target API level. Miss the deadline and you cannot ship updates; fall further behind and the app is hidden from new users.
April to December 2020: Apple stopped accepting new apps, then updates, still using UIWebView. Every app embedding web content had to move to WKWebView.
March 2021: APNs dropped its legacy binary protocol. Push senders had to migrate to the HTTP/2-based API or stop delivering.
July 2022: Google Play's Data safety form became mandatory for every listing.
May 2024: Apple began enforcing privacy manifests and "required reason" API declarations, including for third-party SDKs.

Add the annual rhythm on top: new iOS and Android majors every fall, Xcode and Gradle toolchains that move, SDKs that deprecate.

On a platform, each of these is absorbed exactly once. The fix lands in the shared codebase, the apps are rebuilt, and the fleet rolls forward through regular app updates. That is also why we advise owners to update regularly even when nothing visible changed: the update is the vehicle that carries those fixes into production, and the stores themselves are hostile to dormant apps (Apple periodically sweeps apps that have not been updated in years; Google buries apps targeting outdated API levels). An app that ships updates stays current, visible and installable. Most of our owners experienced the events above as a release note, if they noticed at all.

The bill, itemized

Strip the platform away and here is what one production app makes you own, permanently:

one target API level raise per year, so at least one rebuild and resubmission per year;
OS beta season: test every summer, fix before every fall;
your dependencies' CVEs, deprecations and license changes;
push infrastructure: credentials, token hygiene, delivery monitoring;
store policy watch: new forms, new manifests, new review guidelines;
monitoring, and someone reachable when it breaks.

None of these is hard in isolation. All of them are permanent, and they compound.
What a no-code platform actually sells is not the editor; it is amortization.
Which editor you came through — drag & drop, prompt, or both —
changes nothing to that list. One team absorbs it once, and thousands of apps
inherit the result with their next update.

Our own receipts are public: an engineer is on call year-round, and the platform status page is at goodbarberstatus.com.

Questions in the comments. happy to go one layer deeper on any of this, from colocation choices to the push pipeline to review stories.