How we estimate software, and why we quote ranges
A single number implies a certainty nobody has before scoping. Here is the method behind our estimator and what makes an estimate move.
Clients often ask for one number. We give a range, and it is not evasion — it is the honest shape of the information available before we understand the problem.
Estimate hours, then convert to money
We size everything in engineering hours first. Hours are something we can reason about from experience: we know roughly what building payments or offline sync has cost us before. Converting to money at the end keeps the rate a single number that can be discussed separately.
The second platform is cheaper than the first
A common mistake is doubling the price for a second platform. By the time you build it, the domain model, API and design system already exist. The incremental cost is the interface and the platform-specific work, which is a fraction of the original.
What actually moves an estimate
Integrations with systems we do not control, which have their own timelines.
Compliance requirements discovered late, because they constrain architecture.
Unclear decision-making on the client side — the most common cause of overrun in our experience.
Narrowing, not raising
After a scoping call, the number should get more precise rather than larger. If an estimate only ever moves upward once work begins, that is a sign the original was optimistic to win the work. We would rather lose the work than do that.
Keep reading
How much does an app cost in 2026?
There is no single number, but there is a method. Here is how we turn a rough idea into a range you can plan around, and what makes that range move.
Native or cross-platform: how we actually choose
We default to Flutter for cross-platform work and go native when the project earns it. The decision comes from constraints, not fashion.