DEV Community

Paul Crinigan
Paul Crinigan

Posted on

Shipping Software Without a Dev Team: What Actually Works

Every argument about AI replacing developers focuses on the same thing: can a model write the code. It is the wrong question, because writing the first draft of the code was never what made shipping software slow.

What makes it slow is everything around the code. Reviewing it. Documenting it. Standing up accounts, a database, an API and billing for the fifth time. Building another customer portal that looks like the last four. Deciding whether the model has to run on your own hardware because of the data going through it.

That is the work agents are genuinely good at right now, and conveniently it is the work nobody wanted to do anyway.

The Bottleneck Was Never Writing the Code

Ask anyone who has shipped a product alone where the time actually went. It is rarely the feature work. It is the pull request that sat for three days, the docs that drifted out of sync six commits ago, the auth flow rebuilt from scratch because the last one was in a different framework.

None of that is intellectually hard. It is bounded, repetitive and checkable, which is exactly the profile of work you can hand to an agent and verify afterwards. The parts that genuinely need judgment, the data model, the architecture, what you refuse to build, stay with you.

The teams getting real value out of coding agents are not asking for a whole product. They are handing over the parts that were never the interesting bit.

Where Coding Agents Actually Earn Their Keep

Three places, in rough order of payoff.

Code review is first. An agent reviewing every pull request against your real project catches the boring class of bug consistently, and it never gets tired at 6pm on a Friday. It will not replace a senior reviewer on architecture, but it removes most of what a senior reviewer spends time on.

Documentation is second, and it is underrated because nobody enjoys it. Docs generated from the source stay in step with the source. The failure mode of hand-written docs is not that they are bad, it is that they were correct nine months ago and nobody noticed when they stopped being correct.

Delegated feature work is third. It works when the task is well specified and the agent can run the tests. It fails when neither of those is true, which is most of the time people complain about it.

The pattern is that agents do well anywhere there is a fast, honest feedback signal. Give one a test suite it can execute and it converges. Take that away and it guesses confidently.

The Boring Parts of a SaaS

Every MVP needs the same scaffolding. User accounts. A database. An API. Billing. A dashboard. A way for a customer to log in and see their own data.

This is the part that quietly kills side projects, because it is weeks of work that produces nothing a user would ever describe as a feature. It is also almost entirely solved. Building it by hand for the fifth time is a choice, not a requirement.

Customer portals are the same story. Branded login, dashboards, database-backed pages, a webhook API. The requirements barely change between products, which is exactly why it should not consume a month of your life each time.

When Self-Hosting Is Worth It

Running your own models is worth it in three situations, and it is a distraction in all the others.

It is worth it when the data legally cannot leave your infrastructure. It is worth it when your workload is high volume and predictable, because at that point the per-token math stops favouring an API. And it is worth it when you need the behaviour to be frozen, because a hosted model that silently improves is a hosted model that silently changes your output.

If none of those apply, self-hosting is usually a way to spend a month on infrastructure instead of on the product. The honest version of this advice is that most projects should start on an API and move later, once the volume is real enough to justify the operational cost.

The Takeaway

The useful framing is not whether an agent can write code. It is which parts of your process have a clear definition of done and a way to check it.

Review, docs, tests, scaffolding and the fifth identical billing integration all qualify. Architecture, product decisions and knowing what not to build do not, and probably will not for a while.

Hand over the first category, keep the second, and the amount of software one person can ship changes considerably.

Guides for each of those pieces, coding agents, automated code review, technical documentation, building a SaaS, customer portals and self-hosted AI, are collected here: https://www.aiappsapi.com/ai-development/

Top comments (0)