What custom software actually costs for an SME

Five things do most of the work. When a quote swings by a factor of five, it is almost always one of these.

• Scope.

  How many distinct jobs the software has to do. Logging and approving expense reports is small. That same tool with budgeting, forecasting, multi-currency, and a manager dashboard is four tools wearing one name. Scope is the biggest lever, and the one people underestimate most, because features feel free when you describe them out loud.

• Integrations.

  Software rarely lives alone. The moment it has to talk to your accounting system, your CRM, a payment processor, or a supplier’s ancient API, cost climbs. On a good day the connection is simple to write. On a normal day, someone else’s system behaves in ways nobody documented, and someone has to sit with that. Every integration is a small negotiation with a system you do not control.

• Compliance and data sensitivity.

  Names and emails are one kind of work. Health records, payment data, or anything under Québec’s Law 25 is another. Compliance shapes how the whole thing is built: where data lives, who can see it, how it is logged. That work is real, and it is invisible in a demo, which is why thin quotes tend to skip it.

• Data.

  Starting clean is great. Migrating fifteen years of records out of a spreadsheet graveyard, or out of a system nobody has admin access to anymore, is a project of its own. Messy data is one of the most reliably underquoted line items in this business.

• Polish.

  Empty states, error messages that make sense, the thing that still works on a phone at 11pm: that last stretch often takes more effort than people expect. You can decide how much polish you are buying. Decide it on purpose, before you discover it missing later.

Think in shapes, not feature lists. Here is roughly where things land in 2026, in CAD, for a genuinely custom build done by senior people.

• An internal tool or focused MVP: roughly $15,000 to $50,000.

  One clear job, a handful of users, light or no integrations. A booking system, an inventory tracker, a proof-of-concept before you commit. Often four to ten weeks of work. A lot of good SME software lives here, and it is fine to start here on purpose.

• A real business application: roughly $50,000 to $150,000.

  Multiple user types, a few integrations, dashboards, workflows, some reporting. The system a part of your operation genuinely runs on. This is the most common band for SMEs, and it is wide because “a few integrations” hides a lot.

• A larger or multi-part platform: roughly $150,000 to $330,000+.

  Several connected modules, deeper integrations, more users, real reliability expectations. You are no longer building a tool. You are building the thing the tool plugs into.

• A regulated or high-stakes system: $330,000 and up, sometimes well past it.

  Financial data, health data, strict audit and security requirements, or heavy integration with legacy systems. Cost here is often driven more by risk and rules than by feature count.

For reference on the inputs: senior Canadian developers typically bill around $100 to $160 per hour. Local agencies commonly land around $125 to $250. Experienced freelancers roughly $50 to $120. Offshore rates often look like $25 to $80 on paper. You usually pay some of that gap back in coordination, timezone drag, and the question of who owns the code and still understands it a year later.

The build is the down payment. Software you use keeps costing money. A quote that pretends otherwise is doing you no favours.

• Maintenance.

  Libraries get security patches. Browsers change. Integrations shift under you. A common rule of thumb is 15 to 20 percent of the build cost per year to keep things healthy. It is directional, and it is still a better planning number than zero, which is what most people budget.

• Hosting and services.

  Servers, databases, email delivery, monitoring, backups. For a typical SME application this is often modest: tens to a few hundred dollars a month. It scales with usage, and it never goes to zero.

• Change.

  Your business will change, and good software should change with it. The team that built it can usually make that change in a day. A team learning it from scratch needs a week. That is the quiet argument for owning your code and keeping a relationship with people who understand it.

A quote is a document about how someone thinks. Read it that way, alongside the price.

A good quote names assumptions. It says what is in, what is out, what happens when scope changes, and who owns the code and the accounts at the end. It talks about testing, handoff, and what maintenance looks like. It is specific about integrations, because that is where the surprises live.

A worrying quote is a single number, a short feature list, and a confident tone. Specificity takes work to fake. Confidence does not.

When one number sits dramatically below the others, it usually means one of a few things. They have quietly cut the scope you will actually need. They are planning to make it up in change requests later. They do not yet understand the integrations. Or you do not own what they build. In our experience, the cheapest quote often gets expensive once the corners start showing. You can find cheap work that is also good. Finding cheap work that is also complete, for genuinely custom builds, is rare.

Ask for a few quotes. Then spend more time comparing what they understood about your problem than comparing their prices.

You have real levers here. They do not require cutting quality. They require cutting ambition for a while.

• Shrink the first version.

  The single most effective move. Build the one workflow that hurts most today, ship it, use it, then decide what is next with real information. Half the features on most first specs turn out not to matter once the core is in your hands.

• Use boring, proven tools.

  You do not need a novel architecture. Standard, well-understood technology is cheaper to build, cheaper to hire for, and cheaper to maintain. Save the clever stuff for the part of your business that is actually unique.

• Bring clean inputs.

  Sorting out your own data, deciding your own rules, and being available for quick answers cuts more cost than any technical trick. Ambiguity is a lot of what you are paying to resolve.

• Defer the integrations you do not need yet.

  A manual export on day one. An automated sync in month six. That is often the right sequence, and it moves real money out of the initial build.

• Own the code.

  This will not cut cost on day one. It keeps future changes on terms you control. Owned code means you are never held hostage on the second project by whoever did the first.