Why You Can't Just Build the Software Yourself

You made something. Maybe it took a weekend and too much coffee, maybe a no-code tool, maybe an afternoon of prompting an AI. It runs. You click the button and the thing happens. It feels like ninety percent of a company. This is the most expensive feeling in software, because the part you can see is the part that was easy, and the part that was easy is almost none of the work.

I am not here to talk you out of building things. Building the first version yourself is one of the best moves you can make. It sharpens the idea, it is the cheapest way to learn what you actually want, and it earns you the right to have an opinion. What I want to do is show you the part the prototype hides, why that part is most of the work, and what it costs to have people who have already done it build the real thing.

The thing on your laptop is not the product

A demo has exactly one user: you. You know precisely what to type. You use one device, with clean data, and you forgive it when it stumbles, because you built it and you understand what it meant to do. You steer it around its own weak spots without noticing.

A product has none of those luxuries. It has a hundred strangers who type the wrong thing, paste a spreadsheet into a name field, lose their internet halfway through, share a laptop, and try the one path you never tested, all at once, at 2am, while a payment is in flight. The distance between "it works when I use it" and "it works when they use it" is not a last coat of paint. It is the building.

What lives under the waterline

None of the hard work shows up on the screen. That is exactly why it is easy to miss and expensive to skip. Here is a small piece of what a simple idea quietly demands the moment real people touch it.

Every row on the right is invisible in a demo and unavoidable in a business. This is the essential complexity of software, and it is worth being precise about the word. Fred Brooks drew the line decades ago in No Silver Bullet: some complexity is accidental, a product of clumsy tools, and better tools erase it. The rest is essential, baked into the problem itself. No tool, no framework, and no AI removes the essential part. It can only be understood and handled, and that is the work you are actually paying for.

It looks 80 percent done. That is the trap.

There is an old line among engineers, the ninety-ninety rule: the first 90 percent of the code takes the first 90 percent of the time, and the remaining 10 percent of the code takes the other 90 percent of the time. It is a joke, and it is also just true. The demo is the first 90 percent. The part that makes it dependable is the second 90 percent, and it is where the schedule and the budget quietly go to die.

The demo measures what is possible. The business pays for what is reliable. Those are different numbers, and the gap between them is the whole job.

This is not a small-team problem or a beginner problem. When McKinsey and the University of Oxford studied more than 5,000 large software projects, the average one ran 45 percent over budget and delivered 56 percent less value than promised, and roughly one in six went so far off the rails it threatened the existence of the company that started it. These are funded teams with real engineers. The gap between the demo and the dependable thing is not a rookie mistake. It is the nature of the material.

It is the same illusion that quietly kills AI agents in production, which I wrote about in a separate piece on shipping agents that actually work. A thing that impresses a room for five minutes and a thing a company runs on for years are separated by all the work that never demos well.

No-code and AI got you a demo, not a system

I want to be fair to these tools, because they are genuinely good. No-code builders and AI code generators are excellent at the tip of the iceberg. They get you to something that works, fast, and that is real value. If you used one to prove your idea, good. You did the right thing.

The problem is that they are as blind to the mass below the waterline as you are. They will happily generate the login box and skip the fact that anyone can read anyone else's data. They will save the record and not tell you it silently drops every tenth write under load. They produce confident, working-looking output, which is exactly what makes the missing 90 percent so hard to see until a real user finds it for you.

Spend an hour in the founder and no-code forums and you will see the same arc on repeat this year. Someone ships a working-looking app in an afternoon. Then they hit the wall: they cannot maintain it, they cannot secure it, sometimes they are locked out of the very code they supposedly own, and there is no one to ask. The tell is what comes next. A small market has appeared of experienced developers who do nothing but review AI-built apps before real users touch them, and of founders quietly asking what a proper handoff from a real team should even include. The prototype was free. Getting it to safe, or rebuilding it properly, is not.

A prototype proves the idea. It does not survive the first real user, the first real payment, or the first change to the database six months in.

You are paying for scars, not keystrokes

Here is the thing people get wrong about hiring engineers. You are not buying typing speed. Anyone can produce code now. What you are actually buying is someone who has already met the failure modes and lived through them: the 2am outage, the data migration that corrupted a table, the auth bug that leaked one customer's records to another, the innocent change that broke three things you did not know were connected.

Those scars are the product. A person who has shipped and operated real systems does not just write the happy path faster. They design for the bad day from the start, because they remember the last one. That is worth more than any amount of raw output, and it is the one thing a tool cannot hand you.

It also explains a number that surprises founders: software is mostly the part that comes after launch. Across the industry, maintenance eats somewhere between 40 and 80 percent of a system's total lifetime cost. The build is the down payment. The running of it, the fixing and the adapting as the world changes around it, is the mortgage. Plan for that from day one or it plans for you.

The software that quietly runs a company

The most under-appreciated software in any business is the internal kind: the dashboards, the workflow tools, the integrations that stitch the company's systems together and run in the background where nobody applauds them. This is bigger than it looks. Retool found that teams spend about a third of their engineering time building internal tools, and that most companies have at least one full-time role dedicated to them. This is where a lot of real software actually lives.

These tools usually get built on the big clouds, Azure, Google Cloud, and AWS, and for good reason. They have to plug into enterprise systems that already exist. They carry real obligations: security, access control, single sign-on, compliance, an audit trail for who did what. They have to stay up, because when the tool that finance closes the month with goes down, the month does not close.

Which is exactly why internal tools punish do-it-yourself hardest. The visible part is a screen with some buttons. The real part is the integration surface, the permissions model, the compliance boundary, and the uptime. A dashboard the whole team depends on at month end is not a weekend project, and the cost of getting it wrong is not a bug report. It is the business stopping.

What it actually costs to build

People want a number, so here is how we think about it at pylondev. We size a project by three things: how much there is to build, how long it takes, and how many systems it has to touch. Not a feature count. Two screens that move real money are a bigger project than twenty screens that do not.

Those are what it costs to have a team build it, with design, testing, deployment, and revisions included, end to end. One reason we can keep the numbers lean is that we iterate live, in real working software, instead of drawing screens in a design tool and rebuilding them in code later. It cuts a whole translation step out of the build.

The build is the down payment. Software is mostly the part that comes after launch, which is why the real relationship is a monthly one, not a one-time invoice.

So, should you build it yourself?

Yes and no, and the line is clean. The prototype, the thing that proves the idea and shows people what you mean: build it yourself. It is the cheapest, fastest way to learn, and it makes you a better client when you do hire. The system your business will actually run on: hire the people who have already broken one and fixed it.

The test I would use is the same one I use for everything else. Ask what it costs you on the day it is confidently wrong. If the answer is a bad afternoon, build it yourself and enjoy it. If the answer is a lost customer, a leaked account, or a number your finance team cannot trust, that was never a weekend project. That is the part you hire for, and it is worth every dollar of the second 90 percent.

Further reading

The pieces I would hand to anyone deciding whether to build it themselves.

• No Silver Bullet: Essence and Accident in Software Engineering (Fred Brooks). The original essay on essential versus accidental complexity, and why no single tool gives you a ten-times gain on the hard part.
• The Law of Leaky Abstractions (Joel Spolsky). Why the tools that hide complexity always leak it back out, which is exactly how a no-code build breaks in a way you cannot see.
• State of Internal Tools 2023 (Retool). How much of real engineering is the quiet internal software that runs the company.