A Tech Team Is More Than Developers

There is a pitch doing the rounds that goes roughly: AI writes code now, so you no longer need developers, so you no longer need a tech team. Point a model at your idea, and out comes a product.

I write code with AI tooling every week, and I run a service built on exactly that leverage, so I have every commercial incentive to agree with the first half. The first half is largely true. The leap to the second half is where founders get hurt, because it quietly assumes that a tech team is a room full of developers. It never was.

What a tech team actually contains

Strip a competent product team down to its functions and you find at least six, whatever the job titles say.

A product manager decides what problem you are solving and for whom, and defends that decision against every shiny distraction, including yours. A product owner turns that intent into a sequenced backlog: what gets built this week, what waits, what gets cut. An architect makes the decisions that are expensive to reverse: the stack, the data model, the security posture, the things an investor's technical due diligence will pull apart later. Developers build it. Testers assume it is broken and go looking for the proof, which is a different mindset from the person who wrote it and hoped. And a release manager gets the thing into production without taking the previous version down with it, then makes sure you can do that again next week.

In an early-stage team these functions are hats, not headcount; two experienced people can wear all six. But the functions themselves do not go away just because nobody is wearing the badge. If nobody is doing the product owner's job, it is not that prioritisation stops happening. It happens by accident.

Outcome: you can name six functions, and honestly say which ones your current plan covers.

What AI actually replaced

Here is the honest version of the last two years. AI has collapsed the cost of the one function in that list that was priced by the hour: writing the code. What used to take a developer a fortnight now takes an afternoon with the right tooling and the right supervision. That is a genuine revolution, and it is precisely why our pricing looks the way it does.

But look at what the other five functions have in common. They are not typing jobs. They are judgement jobs: deciding, sequencing, doubting, verifying, taking responsibility. AI participates in all of them now; it can draft a test plan or sketch an architecture. But participation is not accountability. When the model proposes an architecture, something still has to decide whether the proposal is right for your business, your budget and your next funding round. That something is a person with scars.

The economics changed in one row of the table. The table did not get shorter.

Outcome: you stop expecting a coding tool to do six jobs because it does one of them brilliantly.

The failure mode, described precisely

I have now seen the AI-only build go wrong enough times to describe its shape. It is not that the code does not work. Modern models produce code that runs. It is that nobody with judgement was in the loop, so the product accumulates unmade decisions.

Nobody killed the features that did not matter, so it does five things adequately instead of one thing well. Nobody tested like an adversary, so the first real user finds what a tester would have found in an afternoon. Nobody owned the architecture, so the third month of changes costs more than the first two months of building. And nobody ran releases, so every deployment is an adventure. The founder ends up where founders ended up in 2015, with a rebuild, except faster and with more confidence on the way in.

A fast, cheap version of the wrong product is still the wrong product. Speed just gets you there sooner.

Outcome: you can spot the unmade-decisions pattern before it is your product.

What this means if you are buying

None of this argues for hiring six people. At your stage that would be absurd, and it is not what we do either. It argues for one question you should put to anyone offering to build your MVP, including us: who is doing the other five jobs?

If the answer is a name and a track record, good. If the answer is a tool, a process diagram, or a pause, you have found the gap. You are not buying hours of code generation; those are nearly free now. You are buying the judgement wrapped around them, and that is where the price of a build service should be scrutinised: not per hour, but per decision you will not have to unmake.

Outcome: one question that separates a build partner from a code dispenser.