Why there is no single price

Asking what custom software costs is like asking what a building costs: a garden shed and an office tower are both buildings. Two projects described the same way, such as "a customer portal", can differ enormously depending on how many user types it serves, which systems it connects to and how much data it migrates. A responsible estimate starts with the scope, not a price list.

The main cost drivers

  1. Number of features and screens. Each screen, form, report and workflow takes design, development and testing time. This is usually the biggest single factor.
  2. User roles and permissions. A tool used by one team is simpler than one where customers, staff, managers and administrators each see different data and actions.
  3. Integrations. Connecting to accounting, CRM, payment or scheduling systems adds work, and the effort depends on how good each system's API and documentation are.
  4. Data migration. Moving years of records out of spreadsheets or an old system often takes longer than expected, because old data is rarely clean.
  5. Platforms. A web application runs on every device with a browser. Adding native iOS and Android apps adds design, development, testing and app store work. See web app vs mobile app for how to choose.
  6. Design depth. An internal tool can use a clean, standard interface. A customer-facing product may need custom branding, illustration and more usability testing.
  7. Security and compliance. Handling personal, financial or health information adds requirements. In Canada, private-sector organizations are generally subject to PIPEDA, and in Ontario personal health information is governed by PHIPA. Meeting those obligations properly takes planning and testing time.
  8. Testing and quality. More complex rules, more user roles and more integrations all mean more scenarios to test before launch.
  9. Unknowns. Work that has never been done before, such as an unusual integration or a new algorithm, carries more risk, and estimates should say so.

How a development estimate is built

Most estimates come down to a simple formula: estimated hours × hourly rate, plus any third-party costs. The quality of the estimate depends on how well the hours are understood. A good estimate:

  • breaks the project into features and estimates each one separately;
  • includes time for discovery, design, testing, deployment and project communication, not just coding;
  • states its assumptions, such as "integration with the accounting system uses its standard API";
  • shows a range or contingency for uncertain items rather than a falsely precise single figure;
  • separates the first release from later phases.

Be cautious with any quote produced without questions about your process. If the developer has not asked who uses the system, what data it holds and what it connects to, the number is a guess.

Common pricing models

Fixed price

One agreed price for a defined scope. It gives budget certainty, but it only works when the scope is clear. Changes are handled through written change requests, and fixed quotes usually include a margin for risk.

Time and materials

You pay for the hours actually worked at an agreed rate, usually with regular reporting. It is flexible when requirements are still evolving, but the final cost is less predictable, so set a budget cap and review progress often.

Phased delivery

A paid discovery phase produces a detailed scope and estimate, followed by fixed-price or capped phases for each release. This combines the certainty of fixed pricing with room to learn, and is often the best fit for a first project.

Ongoing retainer

After launch, a monthly arrangement covers maintenance, support and a set amount of improvement work.

Ongoing costs to budget for

The launch is not the last invoice. Plan for these from the start:

  • Hosting and infrastructure: servers or cloud services, databases, backups and domain names. Small business applications are often inexpensive to host; costs grow with traffic and data.
  • Maintenance and security updates: keeping frameworks, libraries and servers patched, and adapting when connected services change their APIs.
  • Third-party services: email delivery, SMS, maps, payment processing fees and any software licences the system depends on.
  • App store accounts: if you publish mobile apps, Apple's Developer Program has an annual fee and Google Play has a one-time registration fee.
  • Improvements: once people use the system, they will find things to improve. Budget for a steady flow of small enhancements.

Remember that prices in Canada are normally quoted before sales tax, and HST applies to software development services provided in Ontario.

Seven ways to reduce the cost of a first release

  1. Start with a minimum viable product. Build the smallest version that solves the core problem, use it, then decide what to add.
  2. Choose one platform first. A web app that works well on phones can come before native mobile apps.
  3. Use existing products for standard parts. Payments, email, authentication and accounting rarely need to be built from scratch.
  4. Simplify user roles. Start with fewer permission levels and add more when they are actually needed.
  5. Clean your data before migration. Removing duplicates and outdated records yourself shortens migration work.
  6. Make decisions quickly. Delays waiting for feedback or approvals stretch timelines and cost.
  7. Invest in discovery. A clear scope reduces rework, which is one of the largest sources of budget overruns.

Questions to ask before you sign

  • What exactly is included, and what is explicitly out of scope?
  • How are changes requested, estimated and approved?
  • Who owns the code, and will we receive documentation and access to all accounts?
  • What does maintenance cost after launch, and what does it cover?
  • How often will we see working progress?
  • What happens if the project runs over the estimate?

Frequently asked questions

Can I get an exact price before discovery?

You can get a rough range based on a description, which is useful for budgeting. An accurate fixed price needs a defined scope, which is what discovery produces.

Is custom software eligible for government funding or tax credits?

Some projects that involve genuine technological uncertainty may qualify for programs such as the Scientific Research and Experimental Development (SR&ED) tax incentive, but routine business software usually does not. Ask an accountant who specializes in these programs before counting on it.

Is it cheaper to buy an existing product?

Often, for standard processes. Compare the total cost over several years, including subscriptions and staff time spent on workarounds. Our guide to custom vs off-the-shelf software walks through that comparison.

Want a realistic estimate?

Tell us what you want to build and we will help you scope a first release that fits your budget. Learn more about Custom Software Development or contact us.