पाठशाला Pathshala · उत्पाद Utpād, The product · Lesson 03 · Start

No-code and AI-assisted first versions: what to build and what to buy

A working first version can now be assembled in a fortnight from bought tools and generated code. The skill is knowing which part you must own, and the point at which the assembled version has to be replaced.

Pathshala, The Founder Library · 11 October 2026 · 8 min read

In March 2025 Y Combinator said that a quarter of the startups in its winter batch had codebases that were 95 per cent generated by a model. In November Collins named vibe coding its word of the year. The question a founder faced in 2015, whether a first version could be built without engineers, has been answered. The question that replaced it is harder: of the parts you can now assemble in a fortnight, which ones must you own, and when does the assembled version stop being good enough?

This lesson gives you a rule for sorting components into buy, assemble and build, the evidence on what generated code is and is not good for, the five signals that an off-the-shelf first version has reached its ceiling, a worked example from a Pune tuition business and a decision tree to walk for each component. It does not name tools or their prices, because both change faster than this page will.

What changed, in two numbers

The first number is the YC one. Jared Friedman told TechCrunch that for a quarter of the W25 batch 95 per cent of the code had been generated, excluding imported libraries, and he was careful about the founders: they were not non-technical, every one could have built the product from scratch, and a year earlier they would have. Garry Tan’s qualification in the same conversation is the one to keep: the models were not good at debugging, and a founder has to understand in depth what the product is doing if it is to carry a hundred million users without falling over. Diana Hu added that founders still need to read code, find the bugs and have the judgment to tell good output from bad.

The second number runs the other way. In July 2025 METR published a randomised trial in which sixteen experienced open-source developers worked 246 real issues in repositories they knew well, with and without AI tools. With the tools they took 19 per cent longer. They had expected to be 24 per cent faster and, after the study, still believed they had been about 20 per cent faster. The authors are careful that this is one setting, mature codebases with high quality standards and developers who already knew them, and that it says nothing about beginners or unfamiliar code. But the gap between felt speed and measured speed is the finding. Stack Overflow’s 2025 developer survey puts numbers on the trust side: 84 per cent of developers use or plan to use AI tools, 33 per cent trust the output, 46 per cent distrust it, and 66 per cent name solutions that are almost right but not quite as their main frustration.

Put the two numbers together and the lesson for a first version is specific. Generated code has made writing cheap. It has not made reading cheap, and almost-right code is more expensive than wrong code because wrong code fails where you can see it. The constraint on a first version is no longer how fast it can be written. It is how much of it someone on the team can honestly say they understand.

The rule for sorting: muck and core

Two old essays settle most build-or-buy arguments before they start. In 2006 Jeff Bezos told a conference that developers routinely spent 70 per cent of their time on the backend work that every company needs and no customer chooses them for: servers, storage, bandwidth, scaling. Amazon called it muck, undifferentiated yet all-important heavy lifting, and the business built on that observation now runs a good part of the internet. Muck is bought. In a 2026 first version it includes identity, payments through a gateway that handles UPI and cards, messaging through a WhatsApp Business solution provider, forms, hosting, analytics, e-signature and the KYC step done through an authorised agency rather than written yourself.

Joel Spolsky’s 2001 essay In Defense of Not-Invented-Here Syndrome states the other half: if it is a core business function, do it yourself no matter what. His examples were the Excel team writing its own compiler and Amazon writing its own commerce engine, because a bought engine would have been the same one its competitors bought. The core is whatever the customer is actually paying for: the matching logic, the pricing model, the recommendation, the workflow nobody else has. It is usually a small part of the product and it is the only part that must be understood line by line.

Between muck and core sits a third category, the assembled part: a no-code database, a spreadsheet with automations, a form tool wired to a messaging tool. This is where most of a first version lives, and it is legitimate on one condition: you know the ceiling. Every assembled component has a count of rows, users, automation runs or rupees per month at which it stops fitting or starts costing more than an engineer. Write that number down the day you adopt the tool.

A worked example: fees for forty tuition centres

A founder in Pune wants to build fee management for coaching centres: monthly fees, reminders to parents on WhatsApp, receipts, a view for the owner. The full build is four months of an engineer. The assembled version is a form tool for enrolment, a spreadsheet as the database, a payment gateway’s links for collection, a messaging provider for reminders and an automation tool connecting them. It takes nine days, including the two spent reading the messaging provider’s template rules. Three centres sign at ₹1,500 a month each.

The ceiling is computed on day ten. The spreadsheet is comfortable to perhaps ten thousand rows of fee records; at an average of 120 students per centre paying monthly that is about seven centres over a year before the sheet slows and the automations begin to time out. The automation tool is priced per run; at forty centres the monthly bill for reminders alone would exceed what two centres pay. The messaging provider is muck and stays. The gateway is muck and stays. The core, the thing the owners are paying for, is one rule set: who owes what this month given the batch, the concession, the sibling discount and the mid-month joiner. That rule page changed four times in the first six weeks as the founder met new cases, so the tree says wait; the spreadsheet is the right home for rules that are still moving.

By week ten the rule page has been stable for a fortnight and the founder has nine centres with three waiting. The build begins, with the fee rules and the data store first, generated with a model and read line by line by the founder, who can. Reminders, payments and forms remain bought. The custom build is two weeks of work, not four months, because it is only the core.

Buy what moves value around. Build what the customer pays for. Read every line of it.

The five signals that the ceiling has arrived

The data model fights the domain. The important facts are living in a notes field or an “other” column because the tool has no place for them. The bill scales faster than revenue. Per-row, per-seat or per-run pricing is crossing the salary of the engineer who would replace it. The customer’s environment breaks it. An assembled web app on a ₹8,000 Android phone over a patchy network does what assembled web apps do, and the users you built it for are the ones who cannot load it. The chain breaks weekly. An automation that passes through four tools has four providers who can change an interface, and the founder has become the person who fixes it on Sunday. A customer asks where the data lives. The first security questionnaire, data-processing addendum or sector rule is a question the assembled stack usually cannot answer well. Any two of these together means the custom build starts this quarter.

The rules for generated code in a first version

Generate freely and read everything. The YC founders who shipped 95 per cent generated code could all have written it, which is the point: generation changed who typed, not who understood. A reader on the team is a precondition for shipping any core logic, and if there is none, the concierge version remains the product until there is. Small units. A model writing a hundred lines against a clear rule page produces something a human can check; a model writing a product produces something nobody can. Tests before trust. Almost-right is the failure mode and a test for each rule on the page is the cheapest way to catch it. A repository, from day one, even for the glue, even if a founder is the only committer. Written provenance. Note which parts were generated and against which version of which tool, because the person debugging it in a year will not be the person who prompted it.

A monthly stack review

On the first Friday of every month, list every component of the product in three columns: bought, assembled, built. For each assembled component write the current count against its ceiling and the month at which the current growth rate reaches it. For each bought component write the monthly bill and the usage at which it would cross an engineer’s salary. For each built component name the person who can read it. Then make one decision: start a build, replace a tool, or do nothing and say so. When an assembled component is within a quarter of its ceiling it moves to the build list, core first. When the “who can read it” column has a blank, that blank is the most urgent item in the company.

Tools, models and their prices change monthly and none are named here for that reason. The evidence cited is from early 2025 and later, and METR has since published newer data; check the sources before quoting a figure.