Decide while building, not before

Since building products alone with AI, one thing I’ve had the hardest time getting used to is that development often starts before many things are fully thought through.

In teams before, I was more used to requirements being fairly clear and design being done before development began. Now it’s often: settle part of it, build it, then fill in the next layer based on the real results.

At first I wondered: is this a sign the process isn’t complete enough?

After doing it for a while, I’ve come to feel more and more that indie development isn’t about thinking everything through first, but about knowing what must be settled now and what can be settled while building.

1. Some things are better figured out the earlier the better

Not everything suits changing as you go.

Some decisions, once wrong, drag a lot down with them.

For example:

• who exactly the product is for
• what core problem it solves
• what the most important use case for this version is
• how the core objects and data relate
• how the main flow goes
• what it explicitly won’t do
• basic rules that can’t go wrong, like security, permissions and compliance

On these, I’m actually more careful now than before.

Because if the underlying direction is wrong, however fast AI writes code, it just makes the mistake bigger faster.

2. Some questions are really hard to answer without building it

Another kind of question is completely different.

For example:

• should the results page show the conclusion first or the evidence?
• should an action use a modal, or open a separate page?
• which content should be expanded by default?
• is a certain feature really worth existing on its own?

These can be discussed in documents for a long time, but once the real page appears, the answer may become obvious right away.

• You only know whether it’s cramped once the information is in.
• You only know whether the flow is smooth once you’ve clicked through it.
• Only once AI results come out do you know what explanation users actually need.

So for this kind of question, I no longer force myself to reach a “final answer” before development.

Have a reasonable plan first, build it, then judge.

The more something depends on real content and real use to judge, the less reason there is to lock it in too early.

3. First get one real flow working; don’t spread out the whole product at once

This change has mattered a lot to me too.

It used to be easy to move forward by feature module:

finish this page, then that one; finish the list, then the detail view; cross features off the plan one by one.

Now I’d rather first pick one action users will really complete, and go from start to finish.

For a task management tool, say, I don’t rush to finish:

filtering, search, notifications, settings and all kinds of lists.

First get the most basic path running:

create a task → find it → change its status → save successfully.

Because once a complete path is running, it exposes many problems at once:

• does the requirement itself make sense
• is there enough data
• are the steps smooth
• is the page too heavy once real content goes in
• do users know what to do next once they’re done
• are there obvious problems with the technical structure

Some problems really only become visible once the product comes alive.

4. Once it’s built, don’t immediately keep adding things

This may be what I most need to remind myself of now.

AI coding agents make it especially easy for development to keep rolling forward.

One task done, hand over the next.

One page done, add three more features.

In teams, requirements reviews, design reviews, technical reviews and testing would naturally make the project pause.

Building a product alone, all these pauses disappear.

So you have to stop and look on purpose.

These days I look from at least a few angles:

Product

Does this thing really deserve to exist?

User

Does a first-time user know where they are and what to do next?

Design

Is the focus clear? Do the pages together still look like the same product?

Engineering

Is the current implementation supporting what comes next, or already starting to cause trouble?

For an AI product, also look at:

• whether the output is really good
• whether mistakes can be caught
• whether speed and cost are reasonable

These questions used to be asked by different people.

Now I have to remember to ask them myself.

5. After each round, keep what’s been figured out

I used to skip this step easily.

Once a feature ran end to end, I felt I could keep going.

But after a while, a layer builds up underneath the product:

• outdated requirements;
• temporary data structures;
• components no longer used but still there;
• plans that were tried and dropped but are still written in the docs.

So now I think a round isn’t really over just because “the code runs.”

You also need to tidy up what this round has confirmed.

It might just be:

• updating a few lines of the product definition
• deleting requirements that no longer apply
• adjusting the data model
• turning things that keep recurring into shared components
• deleting temporary code
• adding tests
• noting why an important decision was made

It doesn’t necessarily take lots of documentation.

But next time we continue, neither I nor AI should have to guess again what happened before.

6. The next step isn’t necessarily adding more features either

This is another habit I’ve slowly been changing lately.

It’s easy to understand product progress as:

A done → B → C → D.

But in real development, the most worthwhile next thing is sometimes:

• deleting a feature that actually has no value
• shortening the main flow
• unifying pages that have grown apart
• reworking a data structure that keeps causing problems
• finding someone to actually use it once
• lowering AI costs
• shoring up reliability

So I increasingly judge progress less by “how many features got built today.”

What I care about more is:

after this round, is the product a little less fuzzy than it was last round?

This may be one of the biggest process changes since I moved from team development to indie development.

It isn’t that you never think ahead anymore.

Nor is it “AI builds fast anyway, so just build it first.”

It’s putting different questions at the time best suited to answering them:

the harder something is to change and the higher its risk, the earlier to settle it.

The more something needs a real product to judge, the more it’s allowed to mature later.

Seen this way, “adjusting while building” doesn’t necessarily mean the process is out of control.

What’s truly dangerous is pushing ahead because implementation is so fast, with nothing thought through.

Recently, in this very process, I ran into a very concrete problem:

lots of features were already built, but the product was really ugly.

I thought it was just that the UI hadn’t been dealt with at the end.

Later I found that many questions that belonged to design had actually long been decided quietly during development.

In the next post I want to write about that:

when you build a product alone with AI, when exactly should design come in?