"How much will it cost?" is the first question we get on nearly every call, and the honest answer is always the same: it depends on decisions you haven't made yet. But "it depends" isn't useful when you're planning a budget, so here are the real numbers — the ranges we quote, the costs that surprise people, and the pricing traps to avoid.
What actually drives the price
Three factors dominate every estimate we produce:
Scope. Not the number of screens — the number of decisions the software has to make. A five-screen app that handles payments, roles, and third-party integrations costs more than a twenty-screen brochure app. Every "and it should also…" in a requirements document is a multiplier, not an addition.
Platforms. Web only is the cheapest path. Adding mobile roughly doubles the surface area unless you use a cross-platform framework — we default to React Native precisely because one codebase covering iOS and Android changes the economics of the whole project.
Team location. The same senior engineer costs 3–5x more in San Francisco than in Southeast Asia or Eastern Europe, with far less difference in output than the rates suggest. Distributed teams with strong process are how most SMEs make custom software affordable at all.
Realistic ranges by project size
Ranges, not quotes — but these reflect what we actually see:
- MVP (8–14 weeks): roughly $25,000–$75,000. One platform, one core workflow done well, enough polish to put in front of real users. The goal is learning, not completeness.
- Mid-size product (4–8 months): roughly $75,000–$250,000. Multiple user roles, integrations with payment or accounting systems, an admin panel, real security and testing discipline.
- Enterprise systems (8+ months): $250,000 and up, sometimes far up. Legacy integrations, compliance requirements, and migration of existing data are usually what push these budgets — not the features.
If a vendor quotes a complex product dramatically below these ranges, the missing money reappears later as change requests, missed deadlines, or code you'll pay someone else to fix. We've inherited enough of those projects to say that with confidence.
The costs nobody puts in the proposal
Maintenance. Plan for 15–20% of the initial build cost per year. Dependencies need updating, operating systems and browsers change, small bugs surface under real usage. Software that receives zero maintenance doesn't stay the same — it quietly degrades.
Integrations. "It just needs to connect to our accounting system" is rarely just. Third-party APIs have quirks, rate limits, and versions that get deprecated. Budget integration work explicitly rather than hoping it's included.
Infrastructure. Hosting for a typical SME product runs $100–$1,000+ per month depending on scale, and it grows with usage. It's controllable — see our guide to cutting cloud costs — but it isn't zero.
Your own time. Someone on your side has to answer questions, review builds, and make decisions weekly. Projects where the client disappears for a month cost more, every time.
Fixed price vs. time and materials
Fixed price sounds safer and often isn't. It only works when scope is genuinely nailed down, which is rare for anything novel — and it incentivizes the vendor to argue about scope instead of solving your problem. Time and materials with a capped budget and short milestones gives you the same financial ceiling with far better flexibility. Whichever model you choose, weekly demos of working software are the real risk control.
How to keep a budget honest
- Start smaller than feels comfortable. The cheapest feature is the one you discover you don't need before building it. Before committing to custom at all, it's worth reading our take on when custom software beats off-the-shelf — sometimes the right answer is "don't build this."
- Pay for discovery. A one-to-two-week discovery phase costing a few thousand dollars routinely saves tens of thousands by killing bad assumptions before they're coded.
- Insist on milestones you can see. Working software every two weeks, not a big reveal at month five.
- Treat change requests as decisions, not failures. Requirements evolve. A good process makes the cost of each change visible before you approve it.
What to do with these numbers
Use them to sanity-check proposals, not to skip the conversation. Two projects with identical descriptions can differ by 2x depending on the details, which is why serious software development partners scope before they quote.
If you have a project in mind, we're happy to give you a real estimate — with the assumptions written down so you can hold us to them. Get in touch and tell us what you're trying to build.