How I scope a product build before writing code

A good build starts before the first component, route, or database table. The first job is to turn a vague product idea into a plan that can survive contact with real constraints.

This is the scoping process I use with client work and independent products.

Start with the user loop

I want to know the core loop before the stack:

• Who uses it?
• What are they trying to do?
• What happens before and after the product interaction?
• What would make the first version useful enough?

The riskiest loop should shape the first milestone.

Separate knowns from assumptions

Every product idea has facts and guesses. Good scope makes the guesses visible.

Examples:

• We know the app needs auth.
• We assume users will invite teammates.
• We know the product needs a dashboard.
• We assume AI retrieval quality will be good enough with the available content.

The assumptions become validation work.

Choose boring tools around the risky part

If the risky part is AI retrieval, keep the rest of the stack boring. If the risky part is offline maps, do not invent a custom auth system at the same time.

Good architecture spends novelty carefully.

Define the first milestone as proof

A useful milestone proves something:

• Can the user complete the core loop?
• Can the system survive the expected data shape?
• Can the AI feature be trusted?
• Can the backend run within cost and latency constraints?

A milestone should reduce risk, not just add screens.

What to send before a project call

If you want help scoping a build, send:

• product goal
• target users
• must-have first loop
• timeline
• budget range if known
• existing code or designs
• current blockers

That context makes the first conversation far more useful. If you have a build in mind, send the details.