Every project starts with the same question: how much will it cost to build?
The honest answer is "it depends" — which is useless on its own. So here is what it actually depends on, the models we work under, and where budgets quietly get burned. No magic number, but by the end you'll be able to estimate your own project's shape — which is most of the battle.
What actually moves the number
Two apps that look identical from the outside can differ 5× in cost. The difference is almost never the screens you see — it's what sits behind them.
- Scope, honestly drawn. Not "a marketplace," but which flows, in v1, for which users. Vague scope is the single biggest cost multiplier, because it turns into rework.
- Integrations. Payments, Telegram/auth, maps, third-party APIs, a legacy system you must talk to. Each one is a boundary where reality leaks in — and where estimates go wrong.
- Data and AI. A CRUD app is cheap. Real data pipelines, background processing, or a production LLM feature (not a demo) are a different tier of work.
- Compliance and trust. Handling payments, health data, or PII (HIPAA / GDPR / PDPL) adds real, non-optional engineering — encryption, audit, access control.
- Design fidelity. A clean, systemised UI is fast. A bespoke, pixel-negotiated brand experience is not.
- Timeline. Compressing a schedule costs more, not less — parallel work needs more coordination and more people.
- The unknowns. The parts nobody scoped yet. A good estimate names them out loud instead of pretending they're free.
The models you can engage under
Cost also depends on how you buy, not just what you build.
- Fixed-scope build. A defined v1 with a clear boundary — best when the scope is genuinely knowable up front. Predictable, but only as good as the scoping.
- Iterative / retainer. We scope the smallest shippable version, ship it, and extend from real usage. Best when the product will evolve — which is most products.
- Revamp vs 0→1. Rebuilding an existing site or platform (migration, performance, redesign) prices differently from starting clean — sometimes cheaper, sometimes not, depending on how much of the old system you keep.
- Embedded engineering. Dropping senior hands into your team for architecture, review, and velocity — priced as capacity, not deliverables.
Where budgets quietly get burned
Most overruns aren't bad luck. They're predictable:
- Vague scope that everyone interpreted differently, discovered at build time.
- The wrong stack for the problem — chosen for familiarity, paid for in maintenance.
- Building the big version first instead of the smallest one that proves the idea.
- No measurement, so nobody knows which features earned their cost.
Avoiding these four is worth more than any hourly-rate negotiation.
How we estimate
We scope first. Before a number, we map the problem, the constraints, and the smallest version worth shipping — then estimate that, with the unknowns named. Tight iterations on a modern, controlled stack (Next.js, Bun, Drizzle, Postgres) keep the cost of change low, and production SEO/analytics from day one means you can see what's working instead of guessing.
The goal isn't the cheapest quote. It's the version where every unit of budget maps to something that ships and gets used.
So — what will your project cost?
To give you a real answer, we'd need about 20 minutes on scope. Small, well-defined builds and big, integration-heavy platforms live in very different places, and the honest range only narrows once the shape is clear.
If you tell us what you're building — a new product, a revamp, or an AI feature — we'll scope it and come back with a plan and a number. No obligation, and usually within 24 hours.
davr.dev is a six-engineer studio out of Tashkent, shipping production software since 2012. See what we do or how we work.