We run five products of our own โ a league platform at 48,000 pages, a booking SaaS, a national sports directory, a standings tool, and an officiating app on both app stores. That means we have paid the real cost of custom software, including all the parts that never appear on a quote.
The ranges
| Scope | Typical cost | Timeline | Example |
|---|---|---|---|
| Internal tool | $15,000โ40,000 | 6โ10 weeks | Quoting calculator, scheduling dashboard |
| Customer-facing app | $40,000โ90,000 | 3โ5 months | Booking system, member portal |
| Full platform | $90,000โ150,000+ | 5โ9 months | Registration, payments, multi-role admin |
| Ongoing maintenance | 15โ25% of build/yr | Continuous | Hosting, updates, support, small changes |
Canadian market rates, 2026. That last row is the one most budgets omit entirely.
What actually drives the number
How many kinds of user there are
This matters far more than feature count. Software with one type of user is straightforward. Software where an admin, a manager, a staff member and a customer each see different things, with different permissions, is several applications wearing a trench coat. Every role roughly adds a third again to the build.
Whether money moves through it
The moment your software takes payments it acquires refunds, failed transactions, reconciliation, tax handling, payout timing, and a whole class of edge cases that only appear in production. Payments are never a single line item.
What it has to talk to
Integrations with accounting, inventory, CRM or scheduling tools are usually the largest single item on a serious quote, and the one clients mention last. If the other system has a poor API โ or none โ that integration can cost more than the feature it supports.
How wrong it is allowed to be
An internal tool where a mistake means someone re-enters a row is cheap. Software where a mistake means a customer is double-charged or a tournament schedule collapses on the day needs testing, error handling and recovery paths that can double the engineering.
The cost nobody quotes for
Maintenance. Budget 15โ25% of the build cost annually for hosting, dependency updates, security patches and the small changes every real system needs. Software is not a purchase, it is a thing you own. Any quote that ends at launch is describing half the project.
When you do not need custom
Most businesses are better served configuring something off the shelf, and we say so regularly. Custom becomes the right call at a specific point: the tool does not exist, per-user or per-transaction fees have grown past what a build would cost, or the platform has started dictating how you operate instead of the reverse.
There is a fourth trigger people underrate. If the data running your business lives inside a vendor you cannot export from, you do not own your operation โ you rent it. That is often the moment the arithmetic flips regardless of the monthly fee.
How to compare quotes properly
- โAsk what happens after launch, and what that costs annually
- โAsk who owns the code and whether you can take it elsewhere
- โAsk what is explicitly out of scope โ this reveals more than the inclusions
- โAsk what they would build first if the budget were half
- โAsk what they have built for themselves, not just for clients
That last question is the one we would ask. Software that ships is not the hard part. Software still maintainable in year three, that survives a traffic spike, that a non-technical admin can actually run โ you only learn that by living with it. We have carried our own products through all of it, which is why we build for the maintenance phase rather than the demo.