If you've gotten three quotes for the same custom software project and they're wildly different, you're not imagining things. Custom software doesn't have a sticker price, and the spread between bids often says more about how each team scoped the work than about what the work actually costs. This guide explains what's underneath the number, the common ways engagements are structured, and the warning signs that tell you a low quote is going to get expensive later.
What actually drives the cost
A custom software quote is really a bet on effort. The bigger and less certain the effort, the higher the number. A few factors move it the most.
- Scope. How much are you building? A single internal tool that does one job is a different animal than a multi-role application with admin panels, reporting, and billing. The clearer and smaller the scope, the cheaper and more predictable the work.
- Complexity. Some features look simple and aren't. Anything involving permissions, money, scheduling, real-time updates, or compliance carries hidden depth. Edge cases, error handling, and "what happens when two people do this at once" are where the hours go.
- Integrations. Every external system you connect to, a CRM, a payment processor, an ERP, a legacy database, adds work and risk. Well-documented modern APIs are manageable. Old systems, undocumented endpoints, and vendors who rate-limit you are where timelines slip.
- Design. A back-office tool a few people use can lean on standard components. A customer-facing product that needs to feel polished, work on phones, and meet accessibility expectations involves real design effort, not just engineering.
- Seniority. Who's doing the work matters. Experienced engineers cost more per hour but tend to make fewer expensive mistakes, ask better questions up front, and produce code your future team can maintain. Cheaper, less experienced teams can deliver something that works on day one and becomes a liability by month six.
A useful mental model: you're not paying for lines of code. You're paying to reduce the risk that the thing doesn't work, doesn't get finished, or can't be changed later.
The common engagement models
How you pay shapes how the work goes. There are three main structures, and each is genuinely better for some situations than others.
Fixed-bid. You agree on a defined scope and a single price. Good when the requirements are clear, stable, and well-documented. The upside is budget certainty. The downside is that everything outside the agreed scope becomes a change order, so both sides spend energy policing the boundary. Fixed-bid also pushes the vendor to pad the estimate to cover their risk, you pay for the uncertainty whether or not it materializes. It works best for small, sharply defined projects where surprises are unlikely.
Time-and-materials. You pay for hours worked, usually against a rough estimate and a cap you both monitor. Good when the scope will evolve, which is most real software. The upside is flexibility: you can change direction without renegotiating a contract every time you learn something. The downside is that it requires trust and visibility, you need regular check-ins, a clear view of what's being built, and a partner who won't run the meter. With the right team, this is usually the most honest model because it matches what software development actually is: a process of discovery.
Retainer. You reserve a set amount of a team's capacity each month. Good for ongoing work, continuous improvement, maintenance, a roadmap that doesn't end at launch. The upside is a stable, dedicated team that knows your system. The downside is paying for capacity you might not always fully use. Retainers tend to make sense after an initial build, when you have a living product that needs steady attention.
Many real engagements blend these. A common pattern is a small fixed-bid or capped discovery phase to define the work, time-and-materials for the build, then a retainer for ongoing support. If you'd like to see how we structure this, our process page walks through it.
How to think about ranges honestly
Anyone who quotes a precise number before understanding your problem is guessing. The honest answer to "what will this cost" is usually a range, and the range narrows as the scope gets clearer.
- A small, well-defined internal tool sits at the low end.
- A multi-feature application with a few integrations and real design needs sits in the middle.
- A customer-facing product with complex logic, several integrations, compliance requirements, and ongoing scale sits at the high end.
The single best thing you can do to control cost is to invest in a short discovery phase before committing to a full build. A few weeks spent defining the problem, mapping integrations, and sketching the design turns a wide, scary range into a tight, fundable estimate. It feels like a delay. It's the opposite.
Red flags to watch for
Some warning signs reliably predict trouble.
- A lowball bid. If one quote is dramatically cheaper than the rest, ask what they're not counting. Often it's testing, error handling, deployment, or the integrations that turn out to be hard. You'll pay the difference later as change orders, or in rework.
- No ownership of the code. You should own the source code, the repositories, and the infrastructure accounts. If a contract leaves you unable to take your code to another team, you don't have an asset, you have a leash.
- Vague scope. A proposal that won't commit to what's being built is a proposal designed to bill more later. Clear deliverables protect both sides.
- No discovery, no questions. A team that gives you a firm price without asking hard questions about your data, your users, and your existing systems either doesn't understand the problem yet or doesn't plan to.
- One person, no continuity. Solo dependency is fragile. Ask what happens if the one engineer who knows your system gets sick or moves on.
Takeaway
Custom software pricing isn't mysterious once you know what's under the number: scope, complexity, integrations, design, and the seniority of the people doing the work. Pick the engagement model that matches how settled your requirements are, insist on owning what you pay for, and treat a short discovery phase as the cheapest insurance you'll buy. If you want a grounded estimate for a specific problem, tell us what you're trying to build and we'll give you an honest range rather than a guess.