One person can build a serious product now

I am building an AI-native SaaS product as a solo founder. I do not type every line of code myself, and I no longer think that is a particularly useful measure of the work.

I write specifications, break problems into bounded tasks, direct coding agents, review what they produce, test the result and send work back when it is wrong. It is closer to running a small, extremely fast and occasionally confused engineering team than using autocomplete.

The result is a working product where people can sign up, upload invoices, inspect extracted details, deal with duplicates and export results. One person can now build something that previously required several specialised roles to get moving.

That does not mean one person suddenly knows everything. It means the bottleneck has moved.

Start with the specification

The quality of AI-assisted development depends heavily on the quality of the task. “Build an invoice app” is not a specification. It is a wish wearing a technical hat.

I need to describe the behaviour, boundaries, failure cases and acceptance criteria. What happens when a document is unreadable? How do we identify a duplicate? Which organisation is allowed to see the record? What should the interface show while processing is incomplete?

Writing this down is not administrative overhead. It is product design. The agent forces me to make decisions that a human team would also need, only much sooner and with fewer meetings.

Give agents bounded work

Agents are most useful when the task has a clear surface. Add a validation rule. Implement a state transition. Create a page using an established component pattern. Write tests for a known behaviour.

Large, vague requests invite large, vague implementations. The agent will fill missing context with assumptions, and it will do so at machine speed. This is impressive right up to the moment you realise it has confidently renovated the wrong room.

I keep tasks small enough to review and explicit enough to verify. The point is not to make the agent busy. The point is to move the product forward without losing control of it.

Review is still engineering

Generated code is not finished code. I read the changes, question the structure and check how they interact with the rest of the system. I look for duplicated logic, weak boundaries, missing failure handling and security assumptions that were never stated.

Sometimes the implementation is excellent. Sometimes it passes the immediate test while quietly creating tomorrow’s problem. This is not unique to AI. Human engineers have been producing both varieties for years.

The difference is volume. An agent can create a surprising amount of code before lunch, so a founder needs the discipline to reject work quickly. More output is not the same as more progress.

Tests become more important, not less

When implementation gets cheaper, verification becomes more valuable. Tests give the agent a boundary and give me evidence that a change behaves as intended. They also make later changes less dependent on memory, which is helpful because my memory does not support version control.

I use tests to protect business rules, permissions and important workflow transitions. I also test the product as a user because technically correct software can still be confusing, awkward or simply unpleasant to operate.

Design can move faster too

The same pattern applies to product design. AI can produce alternatives quickly, help explore layouts and expose assumptions before a direction becomes expensive. That speed is useful.

Judgment still decides what belongs. A screen can be polished and wrong. A flow can be clever and make the customer do more work. I use AI to create options, then evaluate those options against the problem the product is supposed to solve.

What has not become easy

AI has changed the economics of producing software. It has not removed the need to choose a worthwhile problem, understand customers, establish trust or build a business.

Finding customers and making money is still hard. Deciding what not to build is still hard. Knowing whether silence means “not interested,” “not now,” or “your message was confusing” is still hard. No coding agent has volunteered to handle rejection for me, which feels slightly unfair.

This is why I describe the change as leverage, not magic. A founder can cover more ground and test ideas with less capital. That creates a real advantage, but it also removes a convenient excuse. If building is faster, we have to spend more time asking whether we are building the right thing.

The role has changed

I still need engineering knowledge. Without it, I could not evaluate architecture, security, maintainability or correctness. But my highest-value work is increasingly about context and direction: defining the problem, setting constraints, reviewing decisions and connecting the implementation to customer value.

One person can build a serious product now. Not because the tools are infallible, and not because experience has stopped mattering. It is possible because one experienced person can coordinate capabilities that used to require a larger team.

The typing was never the whole job. Now that part is becoming impossible to ignore.