Not honestly, not from a conversation and a document. Every fixed price you've been given for custom software was either padded to cover what the vendor didn't know, or it was a number that will move later. The difference between the two is whether anyone did the work of finding out first.
Most projects can answer two or three. A quote produced without answers to the rest is a guess wearing a number.
We don't, and this isn't that. It's a fixed-scope piece of work with a defined deliverable and an end date.
One to two weeks, one price, agreed before it starts. The same commercial model as everything else we do.
A written specification: scope, user flows, integration requirements, data findings, risks, and a realistic cost and timeline range. Not a deck, not a set of recommendations, a document a developer can build from.
You own it and you can take it to any firm, including ones that aren't us. We'd genuinely rather run sprints that go elsewhere than have you suspect the recommendation was shaped by wanting the build.
The most common outcome is a smaller, cheaper, faster version one than the one you arrived with. That's the return on the fee, and it typically exceeds it several times over.
We're not available by the day or the month to think alongside you. That's a role for someone inside your business.
We won't run a three-month evaluation of ERP or CRM products for you. We'll give you an honest opinion on a call for free, and we hold no reseller relationships that would shape it.
We won't own your roadmap, run your backlog, or sit in your strategy meetings. Our horizon is this build; yours is the business.
Roughly the point of the whole thing. If the sprint concludes you shouldn't build, or shouldn't build with us, that's a successful sprint.
We sell defined work with a deliverable at the end. A discovery sprint is that. Open-ended thinking isn't, and we'd be bad at it.
Ask three firms to price the same custom software and you'll get three numbers that don't overlap. That isn't because two of them are wrong. It's because none of you has defined the same thing.
You described what you want in a call and a document. Each firm filled the gaps with assumptions, about how many integrations, how clean the data is, how many exceptions the workflow has, how many people need to sign off. Those assumptions are where the entire cost variance lives, and none of them were written down.
So the number you get is one of two things. Either it's padded, because a firm that's been burned before prices the risk of what it doesn't know. Or it's optimistic and it will move, through change orders, once the unknowns surface in week five. The cheapest-looking quote is very often the one with the least discovery behind it, which is exactly why it looked cheapest.
There's a third thing that happens, and it's worse: the project goes ahead on the optimistic number, hits the first real unknown, and stops. Half-built, over budget, with nobody willing to own the next decision. Every firm that does rescue work, including us, sees this monthly, and it's almost never a technical failure.
You can pay for discovery before the build, or you can pay for it during the build at a much worse rate and call it change orders.
Not only the people commissioning the project. That gap is where most bad specifications come from, the person who signs off describes the process as designed, and the person doing it describes the process as it survived contact with reality.
Not a list of what you use, we connect to each one and check what's genuinely available through its API, how far back the history goes, and how clean the data is. Roughly half of all scoping surprises live here, and they're all findable in an afternoon.
What happens when data's missing, when someone does it wrong, when two people act at once. Exceptions are most of real software and they're what quotes miss.
Explicitly, and it's the most valuable hour. Everything gets sorted into version one, later, or never, and “never” is a real category we'll push for.
Scope, user flows, screens, integration requirements, data findings, and the decisions made with the reasoning attached.
What could make this cost more, ranked, with what would resolve each one.
With the assumptions behind it written down so you can see what would move it.
Sometimes the answer is that an off-the-shelf tool does this, or that the process should be fixed before software touches it, or that a smaller automation solves eighty percent of it. You'll get that answer straight.
Nothing. The specification is yours. Take it to us, to three other firms for comparable quotes, or to nobody. If you take it elsewhere, you'll get better quotes than you would have without it, which is the point, and it's why the fee is what it is rather than free.
If you build with us, the sprint fee comes off the build.
Most common by some distance. The version one you arrived with contained three projects, and one of them delivers most of the value. You leave with a build that's cheaper and faster than the one you were budgeting for.
You came for a custom system and the actual problem is that two tools don't talk to each other, which is workflow automation at a fraction of the cost. Or you came for one thing and the data underneath it needs fixing first. This happens often enough that we'd be embarrassed to charge build prices before checking.
Sometimes the answer is that yes, this needs building roughly as you thought. You now have a document that lets any firm quote it accurately, including ones that aren't us. That's a better position than you were in, and it's worth the fee on its own.
Least common, most valuable when it happens. The tool exists off the shelf, or the process problem underneath won't be fixed by software, or the case doesn't hold up once someone has written the numbers down. We'll say so, and we'd rather lose the build than deliver one that shouldn't exist.
A custom system. The most common destination, and where process, pricing, and handover terms live.
A screen where a specific piece of work happens.
Something happening without anyone opening anything. Frequently the cheaper answer a sprint uncovers.
Visibility rather than a system to work in.
Software that's your product rather than your operation.
Integration or extension of a system of record.
A sprint that ends in "buy this off-the-shelf tool instead" is not a failed sprint. It's the cheapest possible outcome, and it happens more often than an agency page usually admits.
Because free scoping isn't free, it's priced into the quote, and it's done fast enough to win the work rather than thoroughly enough to be accurate. A firm doing unpaid discovery is incentivised to reach a number that closes the deal. One doing paid discovery is incentivised to reach a number that's right, and to tell you if the answer is not to build.
Then it saved you the build budget and did its job. It's the least common outcome and the most valuable one. You keep the specification and the reasoning either way.
Yes, and we'd encourage getting comparable quotes with it. Three firms pricing the same written specification will give you numbers you can actually compare, which is impossible when each is guessing at a different thing.
Honestly: nobody can tell you without doing the work above, and any firm giving you a confident number from a first conversation is either padding it or will revise it later. What a sprint gives you is a range with the assumptions written down, so you can see what would move it and decide whether it's worth proceeding.
One to two weeks, depending on how many systems are involved and how many people need to be spoken to. It's deliberately short, discovery that runs for months has become consulting, which is a different thing and not one we sell.
The people who actually do the work, and whoever has to sign off. Two or three hours of their time in total, spread across the sprint. The people doing the work matter most, they know the exceptions.
It includes one, and adds the parts a requirements document usually leaves out: what was checked in your actual systems, what the risks are, what was deliberately excluded, and why. A requirements list tells a developer what to build. A specification tells them enough to price it.
No. Our horizon is a build; yours is the business, and holding years of product context is a role for someone inside it. If you need that, you need a hire or a specialist consultancy, an agency offering it is describing a dependency rather than a service.
$1,200, and yes, if you build with us, the fee comes off. If you don't, you keep the specification and we've been paid fairly for the work.
We're in Ahmedabad, India, and stay available for calls in your US Eastern or UK working hours. The sprint runs on calls and written work, so distance genuinely doesn't affect it.
One to two weeks, a fixed fee, and a written specification you own, whether you build with us, build with someone else, or decide not to build at all.
