What custom software should cost.

The most common question we get is some version of “how much will this cost,” and the honest first answer is uncomfortable: not yet. Not because we are coy about pricing, but because a price is a function of how well the work is specified, and most software conversations start before anyone can specify the work. The question that feels like it should have a number attached is exactly the one that can’t, until something else happens first.

This is why the two standard answers to “what should custom software cost” are both a little dishonest. The open-ended hourly arrangement is honest about uncertainty and dishonest about its incentives: it bills the discovery you should have done before signing, and it bills it at the same rate as the building. The lowball fixed bid is the mirror image. It quotes a confident number for a scope nobody has pinned down, and it makes that number back through change orders once the unspecified parts surface. Both are responses to the same underlying fact, which is that the scope was vague when the price was set.

So the useful move is to attack the vagueness directly. Before a build, the thing worth buying is a small, bounded piece of work that turns “we want a system that does roughly this” into a written, checkable definition of what the system does. We sell that as a verification audit on existing systems, and the same discipline scopes a new build: a behavior catalog, the specs, the surfaces, written down before the larger number is quoted. Once the scope is legible, a fixed price is no longer a gamble for either side, which is why we can offer the entry tier as a fixed price scoped in one call. The number isn’t brave. It’s just possible, because the unknowns were converted into knowns first.

On hiring in-house instead

A fair version of the cost question is whether a shop costs less than hiring. Sometimes it doesn’t, and you should hire. The comparison people get wrong is the one between a contractor’s rate and a salary, because that compares the wrong things. An in-house team is a standing capability you keep; a build is a defined outcome you keep. The real question is whether what you need is ongoing capacity or a specific system delivered with the record that lets your eventual in-house team own it. If you hire first and build without that record, you have paid twice: once for the salaries, and again later when someone has to reconstruct what the early code does. The artifact is the hedge. A build that ships with its specs, tests, and gate transcripts is one your future hires can read instead of excavate.

On how long it takes

“How long does a custom project take” has the same shape as “how much does it cost,” and the same trap. The schedules that slip are almost never the ones that were honestly scoped and then executed; they are the ones where the scope kept revealing itself during the build. A spec that has been written down and checked doesn’t eliminate surprises, but it moves most of them before the clock starts, which is the only place a surprise is cheap. We ship builds in weeks rather than quarters not by working faster in some heroic sense, but by refusing to begin the long part until the short part, the specification, is done. The estimate you can trust is the one that comes after the scope is legible, not the one offered to win the meeting.

That is the whole answer, compressed: the price, the timeline, and the build-versus-hire decision are all downstream of one thing, which is whether anyone has written down, in checkable form, what the software is supposed to do. Spend the small money on that first. Every number you actually care about gets more honest once you have.