Solo building: the product process isn't linear anymore

Building a product alone with AI lately, I feel one thing more and more clearly:

the product development process I was used to can’t simply be copied over.

In teams before, even though requirements changed and designs got reworked, it was broadly:

product works out the requirements → design proposes a solution → engineering builds → test and launch.

Now it often becomes:

think part of it through → build it → see how it really works → find there are things I haven’t figured out → go back and fill in requirements, change flows, change the design → keep going.

It used to be more like a relay.

Now it’s more like going forward loop by loop.

Why it used to be closer to linear

Thinking about it later, the traditional product process looked fairly linear not necessarily because products should be built that way.

A large part of the reason was that teams need handoffs.

Designers need to know when they can start designing.

Engineers need fairly stable requirements and designs.

Testers need to know what counts as done.

So we have PRDs, requirements reviews, design reviews, technical reviews, and try to think a stage’s problems through fairly completely before handing over to the next role.

These processes certainly help the product get better.

But at the same time they solve another problem:

with many people working together, everyone has to have roughly the same understanding of the same thing at some point in time.

Once one person builds the product, that constraint suddenly mostly goes away.

In the morning I’m discussing requirements; in the afternoon I can have a coding agent build it directly.

If the result is wrong, I change it in the evening.

Nobody has to wait for me, and there’s no formal handoff point forcing me to say: “this stage ends here.”

That’s certainly freer.

But with the freedom, the shape of the process changed too.

AI makes “building it” much faster than “figuring it out”

This is what I’ve felt most clearly lately.

It used to take days or even weeks for a feature to go from idea to actually appearing in the product.

During that time, many things kept being discussed.

Whether the requirement made sense, where the design had problems, whether there were technical pitfalls — all had a chance to surface early.

Now an idea that pops up in the morning may already be usable by the afternoon.

The problem is:

the code being written doesn’t mean the product judgment is mature.

A page opening doesn’t mean the experience holds up.

A feature running doesn’t mean users really need it either.

AI has cut implementation time a lot, but the speed at which a product gets thought through hasn’t sped up with it.

So it’s easy to end up in a state where:

the product keeps growing, but many of its decisions are actually only half-baked.

Development itself is also becoming part of thinking

This is very different from how I used to work.

Before, it was easier to see development as “implementing the requirements and design.”

But building products alone, I keep finding that some questions really can’t be worked out from documents alone.

For example:

once real content goes in, will there be too much information?

Should an action live in the list, or in the detail view?

When AI gives a result, should users see the conclusion first, or the evidence?

A feature that seemed very reasonable in the PRD turns out, once you actually use it, to have no reason to exist.

These things often only become visible once the product is actually running.

So development now isn’t only execution.

It’s also helping me make ideas that were vague concrete.

That’s also why many details get filled in while building.

Not necessarily because I didn’t think carefully earlier, but because some questions can only be answered after seeing the real thing.

But “thinking while building” can easily become “building whatever comes to mind”

There’s a very dangerous difference here.

Indie development easily creates an illusion:

AI builds fast anyway, so just build it first.

So feature after feature gets added.

This page uses one structure for now, another page uses a different one.

A decision that was convenient at the time, never rechecked by anyone, slowly becomes a default rule in the product.

In the end you find:

every part is “done,” but put together they don’t look like one complete product.

So these days I distinguish two kinds of change.

One is going around in circles:

changing the same problem over and over without getting new information.

The other is what I understand as “spiraling forward”:

with each part built, you see a bit more of what you didn’t know; the next round doesn’t simply overturn the last, but makes the product a bit more solid on top of it.

The features don’t necessarily keep multiplying.

But the product should keep getting clearer.

Building a product alone, what you lose isn’t only hands

In a team, product, design, engineering and testing would naturally pick at problems from different angles.

Now all these abilities seem to be fillable by AI:

ChatGPT can discuss the product, Claude can design, Codex can write code.

But in actual use, I increasingly feel:

several AI tools don’t automatically form a product team just because they each play a different role.

Each tool easily keeps going with the task in front of it.

The one writing requirements keeps adding requirements.

The one designing keeps polishing pages.

The one writing code keeps implementing features.

But rarely does anyone stop on their own to ask:

put together, does all this still look like the same product?

In the end, that falls back on the person.

What I really need to change is what I expect of “process”

Before, I was more used to:

finishing one stage fairly completely, then moving to the next.

Now I’m starting to accept that different parts can be at different levels of maturity.

The product direction may already be fairly stable.

The details of one feature are still changing.

The data structure has only just been validated by real use.

The design system is only beginning to form.

Some pages are still just temporary solutions.

They no longer line up neatly on one line.

So the new question is no longer:

“How do I think everything through before development starts?”

But:

which things must be figured out now, and which make more sense to decide once they’re built?

And:

when should I keep going, and when should I stop and organize what I just learned before moving on?

That’s what I most want to work out lately.

In the next post, I want to keep going: if product development really has turned from a line into loops, how should each loop go so it doesn’t end up as building while things fall apart?