What actually drives the cost of custom software development

The cost of custom software is set by a small number of decisions rather than by a feature list: how wide and how deep the scope runs, how many systems you integrate with and how well those systems behave, what compliance and accessibility obligations apply, how ambitious the design and the non-functional requirements are, how much legacy data has to move, and which team model you choose. Change any one of them and the estimate moves with it. Most of them are yours to set before anyone writes a line of code.

Scope: breadth versus depth

Breadth is the number of distinct things a system does: quoting, scheduling, invoicing, reporting. Depth is how thoroughly it does any one of them. Briefs almost always describe breadth, because breadth is easy to picture, and almost always underspecify depth, because depth only becomes visible once real people use the thing.

Take a single approval step. The breadth version is one button and one status change. The depth version asks who can approve on someone's behalf, what happens when the approver is away, whether a partial approval exists, how a decision is reversed, who sees the audit trail, and what the system does when two people act at the same moment. Same box on the diagram. Very different amount of work.

A rough way to think about effort: it scales with the number of workflows multiplied by the states each workflow can be in, multiplied by the roles that can act on those states. Screens are the visible surface of that arithmetic, not the arithmetic itself. When an estimate feels heavy relative to the page count, depth is usually the reason, and it is the first place to look when you want the number to come down.

Integrations: maturity matters more than count

Counting integrations tells you very little. What matters is the condition of the system on the other side. A current, documented API with a sandbox, stable authentication and predictable errors is a known quantity. A legacy endpoint with no test environment, undocumented behaviour, aggressive rate limits and a nightly file drop is a research project wearing the same label.

Four questions predict most of the cost. Is there a sandbox you can break without consequences? Is there documentation that matches what the system actually does? Is there a person who can answer a question within a week? And does the vendor require a certification or review process before you go live, as payment, banking and health systems often do?

Two integrations that look identical on a slide can differ widely in cost, and the difference is rarely the code you write. It is whether anyone at the other end can answer a question this week.

Integrations also carry a long tail. Each one adds failure modes, retry logic, reconciliation and monitoring, and each one becomes a thing that can break on a Tuesday because a third party shipped a change. That maintenance reality belongs in the conversation early, alongside the web application work it supports.

Compliance, accessibility and security are scope, not paperwork

Obligations change what gets built, not just what gets documented. Canadian privacy law, provincial health and public sector rules, data residency expectations, retention and deletion policies, consent capture, role-based access and tamper-evident audit logging all express themselves as data models, screens and tests. A system that must prove who changed what and when is a different system from one that simply stores current values.

Accessibility follows the same pattern. Designing to WCAG 2.2 AA from the first wireframe costs a modest amount of care: sensible heading structure, visible focus, colour contrast that survives the brand palette, components that work from the keyboard. Retrofitting the same standard after launch means reopening the design system, the markup and the test suite at once. It is the clearest example on this list of a requirement that is inexpensive early and painful late.

Security obligations behave the same way. Single sign-on, secrets management, encryption at rest, penetration testing and vulnerability response are all easier to design in than to bolt on, and buyers in regulated sectors often ask for evidence. If any of this applies to you, say so in the first conversation rather than the third; our notes on security and compliance cover what usually gets asked.

Design ambition, data migration and the requirements nobody writes down

Design ambition is a real cost lever and a legitimate choice. A clean, conventional interface assembled from a mature component library is faster to build and easier to maintain. A distinctive product with bespoke components, considered motion, illustration and a documented design system takes longer, and it is worth it when the interface is the product or carries the brand. Neither is wrong. What is expensive is deciding late which one you wanted.

Data migration is the item most often missing from a brief. The question is never really how many records there are. It is how clean they are, how many duplicates and orphans exist, whether anyone can still explain the meaning of a field created years ago, and whether the true system of record turns out to be a spreadsheet on someone's desktop. Plan for profiling the data before you commit to a shape, for at least one rehearsal migration, and for a reconciliation step where the business confirms the numbers match.

Then there are the non-functional requirements: expected concurrency, acceptable response times, uptime targets, offline behaviour, bilingual EN/FR content, observability, backup and recovery objectives. None of them appear on a feature list. All of them change architecture. A system that must keep working when the network drops is not the same system with an extra checkbox, and finding that out during testing is the expensive way to learn it.

The team model changes the shape of the cost

How the work is staffed changes both the total and where the risk sits. There is no universally right answer, only a fit with your timeline, your internal capacity and how much coordination you want to own.

Mixed models work too, and often should: a studio team for the initial build, your own developers alongside them, and a handover that leaves your people able to maintain the result. That only holds if the code, the accounts and the documentation are genuinely yours. How a team works day to day matters as much as the model on paper, which is why we publish how we work in plain language.

How to spend less without gutting the product

The productive cuts share a shape: they reduce what you build now without reducing what you can build later.

• Sequence by evidence. Make the first release the smallest thing that tells you something true about real use. Everything after that is informed rather than assumed.
• Trim depth before breadth. Ship the main path of a workflow and handle rare exceptions by process for a while. A person handling a handful of odd cases each month is usually cheaper than code that handles them from day one.
• Defer low-volume integrations. If a system exchanges a handful of records a week, a manual step or a scheduled export can hold the line until volume justifies the build.
• Buy the boring parts. Managed authentication, managed databases, an established CMS for content pages. Custom work should go where your business is actually different.
• Settle the cheap-early decisions early. Accessibility, languages, roles and the data model cost little to fix in week one and a great deal to change in month six.

Two things are false economies. The first is skipping tests around money, identity and permissions, where defects are expensive in ways that never appear on an invoice. The second is skipping observability, because a system you cannot see into costs more to support for its entire life. A simple prioritisation rule helps: rank each candidate by how many people it affects multiplied by how often they hit it, divided by the effort to build. Then be honest about the denominator.

How OlDevs helps, and what to send us

OlDevs has been building software from Vancouver since 2014, and we work through these drivers with you before quoting rather than after. You get one accountable team across design, build and delivery, a working demo every week so progress and scope stay visible, accessibility to WCAG 2.2 AA as a default rather than an upgrade, bilingual EN/FR capability where you need it, and full ownership of all code, designs, accounts and intellectual property. Clients outside Vancouver are served remotely, on video calls in their own time zone, with on-site visits when the work calls for it.

The most useful thing you can send is not a specification. It is the workflows that matter most, the systems you have to connect to, the obligations you carry, and the date something has to be live. From that we can tell you which drivers dominate your project and where the honest trade-offs sit. Request a quote and you will hear back within one business day.