What Actually Drives the Cost of Custom Software

People search for a custom software development rate the same way they’d search for a plumber’s call-out fee. We understand why — a number lets you compare, budget, decide. We still won’t give you one on a landing page, and any studio that does is quoting a placeholder, not your project.

That’s not evasive. It’s the honest answer to a question that has no fixed answer, because the price of custom software isn’t a property of the software. It’s a property of the decisions that shape it. Here’s what actually moves the number.

Scope is the first lever, and it’s the one you control

A “customer portal” can mean a login page and a form, or it can mean role-based permissions, audit trails, exports, and three integrations with systems you haven’t chosen yet. Both are real projects. Both get called “a portal” in the first email.

This is why a discovery workshop comes before any number does. Not as a sales step — as the point where scope stops being a word and becomes a written spec: screens, roles, data flows, what’s in and what’s explicitly out. Skip it and the number you get is a guess wearing a decimal point.

Team size and iteration count, not hours

“Cost per hour” implies the work is a fixed quantity divided by a rate. It isn’t. The same feature set built by one senior generalist over ten weeks and by a five-person team over three weeks can land at a similar total cost through very different paths — and the smaller team usually ships something more coherent, because fewer people means fewer handoffs and fewer places for the spec to drift.

We keep teams small on purpose: one person on the call is usually the person writing the code. That’s not a staffing philosophy for its own sake — it removes a layer that otherwise shows up in your invoice as “project management” without showing up in your software as a feature.

Iteration count matters more than headcount. Usable software every two weeks means you’re reviewing real screens, not a slide deck, and catching a wrong assumption in week two instead of week ten. Fewer surprises late in a build is the single biggest cost lever nobody puts in a pricing table.

What’s actually inside the number

Driver	What it changes
Number of user roles and permission levels	Data model complexity, testing surface
Integrations with existing systems	Discovery time, error handling, monitoring
Reporting and export requirements	Query complexity, UI surface area
Data residency / GDPR constraints	Hosting choice, what gets logged and where
Whether it replaces a live system	Migration plan, parallel-run period

None of these are exotic. They’re the ordinary questions any serious proposal has to answer before a number means anything.

Fixed price per phase, or a retainer

Once scope is written down, there are two honest ways to price the work. A fixed price per phase, quoted after a paid discovery step, works well for a project with a defined end state — replace this spreadsheet, launch this booking tool. A monthly capacity retainer fits a product that keeps evolving after launch, where the question isn’t “when is it done” but “how much of the team’s time do we need this quarter.”

Neither is cheaper in the abstract. They’re answers to different questions: one prices a destination, the other prices ongoing capacity. Picking the wrong one is how “custom software” projects turn into open-ended invoices — not because the work was mispriced, but because the pricing model didn’t match the shape of the problem.

Integrations move the number more than any single feature

A standalone tool that nobody else’s system needs to talk to is the cheapest kind of custom software to build, because its edges are entirely under your control. The moment it needs to read from an ERP, write back to a CRM, or reconcile with a payment processor, the cost stops being about the screens and starts being about the other system’s API — or lack of one.

We’ve built middleware against ERPs and CRMs that document their endpoints well, and we’ve built it against systems whose only reliable interface is a scheduled file export. Both are solvable. Neither costs the same, and neither is knowable until someone actually looks at what the other side offers. This is one of the first questions a real discovery conversation answers, and one no generic estimate can.

Ownership is a cost driver too

A quote that doesn’t mention source code, repository access, and documentation isn’t a complete quote — it’s missing the part that determines what happens after launch. Software you don’t own is a subscription with extra steps: every future change routes back through whoever holds the code, at whatever rate they set once you have no alternative.

We hand over the full source, the repository, and documentation at every milestone, not just at the end. That’s not generosity — it’s what “custom” is supposed to mean. If you can’t take your software and walk, you didn’t buy custom software, you bought access to someone else’s.

The honest version of the question

The searchable question is “how much does custom software cost.” The answerable one is “what is this specific piece of software, for these specific users, doing that off-the-shelf tools can’t.” Everything else — the roles, the integrations, the reporting, the hosting constraints — falls out of that answer, and so does the price.

If you already know the shape of the problem, a discovery conversation will get you a real number faster than another search query will. If you don’t yet, that’s fine too — that’s what discovery is for. You can see examples of the kind of software we’ve built, including our own products, on the work page, or read more about how we approach custom software specifically.

A price you get before scope exists isn’t a quote. It’s a placeholder waiting for the conversation that makes it real.

That conversation is a contact form away, and it costs nothing to have.