Build1 distinct publisher3 min readUpdated
A solo operator with no engineering background shipped a paying eSIM store, then published six failures. Not one of them was a coding problem.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
A product manager with ten years in travel and aviation and no engineering job history has published an itemised list of what production charged him for skipping the apprenticeship [2][13]. It is a useful document because the argument that AI ate the junior curriculum has mostly been made by seniors describing what juniors are no longer learning [14], and this is the same ledger read from the other end.
The setup, per his account: a travel eSIM store started in early 2026, web app, mobile app, backend, own catalogue, 190 countries, 25 languages, run alone [3]. AI wrote most of the code and he had a working store in weeks rather than the six months he estimates four people would have needed [1][5]. First paying order on 14 June, customers in 21 countries since, most of them in markets he never marketed in [4]. He is explicit that the volume is small and that he is not disputing the speed claim [4][5].
Then the itemisation. Stripe took money and no matching order existed; the webhook was configured and fired, something downstream consumed the event, and he learned about it from a customer rather than a dashboard [6]. He now runs an hourly reconciler that walks recent charges and checks each has an order [6]. PostHog showed roughly half the purchases his database had rows for, because the event fired in the browser on the confirmation page and half his customers pay and close the tab; he ran on a reported 3% conversion rate for weeks when the real figure was 16% [7], an understatement of about 5.3 times [8]. The function resolving a customer's language defaulted to French when it could not find one, which was most of the time, so Japanese and Brazilian buyers got French confirmation emails; nobody complained, they just did not return [9]. Turning on Cloudflare bot protection served challenge pages to the server-to-server webhooks his eSIM suppliers use, orders sat in limbo, and his test suite did not catch it because the suite does not run through the CDN [10]. Next.js wrote incremental static pages to a small ephemeral host disk until the disk filled and the site stopped serving [11]. And he launched on a flat markup, then did the arithmetic on supplier cost, card processor percentage, fixed fee, EU VAT and refund rate, and found the fixed costs consumed the entire margin on small orders: a three euro sale lost money [12]. He rebuilt pricing around net profit per order and added a small-order fee [12].
Six failures [15], and his own reading is that none of them is a coding problem and no function in the list was written wrong [13]. What the list actually inventories is distrust of a webhook you can watch fire, knowledge that client-side events undercount, suspicion of a framework default before it bites, the understanding that a security control is an integration change, and the habit of reading unit economics before setting a price [16]. That is the specific content of the grunt work, stated as consequences with dates and figures attached rather than as a complaint about kids today.
What to watch is the shape of the bill rather than the total. Five of the six failures sat at a boundary between his system and someone else's, and the sixth was a default inside his own framework [6][7][9][10][11][12]. That is the load AI code generation does not reduce, and it is the load that gets discovered by customers when nobody on the team has been paged before. Worth tracking whether the reconciler-and-audit pattern he arrived at reactively starts showing up in AI-assisted builds as a default rather than a scar.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
First paying order was on June 14, and since then he has had customers in 21 countries, most in markets he has never marketed in; the volume is small but the money is real and moves through the same rails a large store uses.
PostHog showed roughly half the purchases his database had rows for, because the event fired in the browser on the confirmation page and half his customers pay and close the tab before seeing it. He read a 3% conversion rate for weeks; the real number was 16%.
The author's assessment of his failure list: not one of those is a coding problem, and there is no function in the list that was written wrong. He frames the episode as the apprenticeship he never did coming back for its money, with an itemisable bill.
The author states he is not a developer, runs a product with real customers and real money moving through it, that AI wrote most of the code, and that he got there in weeks.
The author spent ten years in travel and aviation as a product manager (booking funnels, GDS integrations, checkout tests) and a few years ago completed a full-stack bootcamp so he could argue with engineers in their own vocabulary, coming out able to build things slowly and badly.
In early 2026 he started a travel eSIM store: web app, mobile app, backend, his own catalogue, 190 countries, 25 languages, run alone.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Detailed but wholly self-reported
All content derives from one first-person post by the operator. The incident accounts are specific, internally consistent and technically plausible - named vendors, named mechanisms, stated remediations - which is why this is not scored lower. But nothing is corroborated: no logs, dashboard exports, platform statements, order records or second publisher, and headline numbers such as 3% versus 16% conversion and the four-person, six-month counterfactual are unverifiable as presented.
One live solo store, small volume
There is real production adoption to point at - a store taking paying orders since June 14 with customers in 21 countries, plus concrete operational changes shipped in response to incidents (hourly reconciler, repricing) - but it is a single solo deployment of self-described small volume, and no other operator, team or organisation is shown adopting the practices described.
Modest self-critical claims, oversized generalisation
The post is deflationary rather than promotional about AI - it concedes build speed in a sentence and spends its length on what broke - and it volunteers unflattering detail against its own interest, which pushes the gap near zero. The overstatement is one of scope: a single unverified solo case is offered as a data point that settles an industry argument about the junior developer pipeline, and figures like the five-fold conversion error and the four-person baseline are asserted without artifacts.
Reputational and commercial self-interest, disclosed
The author is the owner-operator of the commercial eSIM store being described and is publishing under his own byline into an ongoing on-platform debate, so both credibility-building and product visibility are at stake. Those interests are visible on the face of the post rather than concealed, and the content runs against pure promotion by cataloguing revenue-losing failures, which moderates the score. No sponsorship, vendor relationship or paid placement is disclosed or evident in the supplied material.
Low - single self-reported publisher
Confidence is bounded by structure, not by internal quality: one publisher, one author, one interested account, no corroborating documents and no contradicting source either. The technical failure mechanisms are the most trustworthy element because they are checkable against widely known behaviour of webhooks, client-side analytics, CDN challenges and incremental static regeneration; the quantitative and counterfactual claims are the least.
product
A 2x LLM bill is not a bug report: token spend is an observability problem1 distinct publisher
build
796 pages of semantic search with no vector database, and what it cost to skip one1 distinct publisher
build
Three API calls, no rollback: the phone numbers your carrier bills and your database never saw1 distinct publisher
build
A Stripe SDK Major Bump Turned One Metadata Lookup Into a Silent Non-Delivery1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 17, 2026