Halatao
Fast orientation, a realistic first phase, visible progress, and decisions tied to actual business impact.
You do not need a perfect specification to start the conversation. What matters first is the business situation, the desired outcome, the current system reality, and the constraints around delivery.
From that, we shape the first phase. In existing apps this often means discovery and stabilisation. In greenfield work it usually means a realistic MVP or first workflow release.
The following work moves in smaller steps with visible progress and room for informed decisions instead of a large opaque build cycle.
We look at the current situation, goals, constraints, risks, and the practical shape of the problem. If the fit is weak, it is better to know early.
The output should be a concrete next phase with real value, not an endless requirements bucket. Larger projects usually benefit from a narrower first release.
I prefer smaller delivery steps and regular decision points so the buyer sees progress and risk stays manageable.
That can include further features, performance work, technical debt reduction, operational hardening, or support for the internal team.
It depends on the project, but the goal is to reach a practical next-step decision quickly rather than drag out discovery for its own sake.
Not always. For most software work it is better to lock the objective of the first phase and refine detail with better information as the project moves.
Change is normal. The important thing is to assess it against business value, risk, and the purpose of the current phase.
Yes. For existing applications that is often the safest way to reduce risk before larger delivery decisions.
Next step
A short project summary is enough to start the conversation.