What you are actually paying for
A custom web app has no unit price. There is no box on a shelf and no cost of materials worth mentioning. What you pay for is time: the hours of the people who plan it, design it, build it, test it and put it online. Every honest quote is those hours, shared among roles, multiplied by each role's rate, with a range around the total because software is never fully known in advance.
That is why two quotes for what sounds like the same app can be far apart. One studio has assumed a sign-in page and an email form; the other has assumed single sign-on, roles, an audit log and a staff dashboard. Neither is wrong. They are pricing different apps that happen to share a name. The fastest way to compare them is to ask for the hours by role and the list of assumptions behind them.
This guide walks through the roles on a typical web app, what makes each one's hours grow or shrink, and three worked examples priced from our rate card when you open the page. We never type a price into the text of a guide, because rates and provider prices change. The examples below are always current.
The roles on a web app, and what each one does
Not every project needs every role full time, and on a small app one person may cover two of them. But every role below does work that has to happen somewhere. If a quote leaves one out, ask who does that work instead.
| Role | What they do | What makes their hours grow |
|---|---|---|
| Project manager | Runs the plan, the milestones, the sign-offs and the change orders. Your main contact. | More people to coordinate, more stakeholders on your side, more milestones, regulated work with formal records. |
| Software architect | Chooses the structure, the data model and how the parts talk to each other. Reviews the hard decisions. | Integrations with other systems, real-time features, strict security or data residency, many user types. |
| Product designer | Turns the brief into flows, wireframes and the finished screens, and checks them with your users. | The number of screens, how custom the look is, a full brand system, accessibility to a stated level. |
| Frontend developers | Build what runs in the browser: screens, forms, state, accessibility, responsive layouts. | Screen count, complex interactions, real-time updates, more than one language, offline behaviour. |
| Backend developers | Build the server, the database, the business rules, the integrations and the admin tools. | Payments, roles and permissions, integrations, search, file handling, reporting. |
| QA engineer | Writes and runs the tests, checks each milestone before you see it, and tracks defects. | Payments and money handling, regulated data, many browsers and devices, many user roles. |
| DevOps engineer | Sets up hosting, deployment, backups, monitoring and the path from a commit to production. | Higher availability, more environments, a cloud provider with more moving parts, compliance logging. |
| Technical writer | Writes the handover: how to run it, how to administer it, how it is built. | More admin features, more integrations, a handover to your own team rather than ours. |
Our estimates also show a line called Development. It covers the foundations: project scaffolding, standard screens and forms, the interfaces between parts, and the test suites. The named senior roles review it and keep the mission-critical parts, such as the data model, payments and security, for themselves.
What drives the hours
Seven decisions move the estimate more than anything else. Most of them are yours to make, which means most of the price is in your hands.
- 01
The number of screens
Each page or screen needs design, frontend work and testing. A screen is not just a layout: it is its empty state, its error state, its loading state and how it looks on a phone. Counting screens honestly is the single best thing you can do for an accurate quote.
- 02
The features behind the screens
Sign-in with roles, payments, an admin side, notifications, search and file uploads each bring backend and QA hours of their own. Payments in particular need careful testing, because a bug there costs money rather than patience.
- 03
Integrations
Connecting to an ERP, a CRM, an accounting package or a partner's API is where estimates go wrong most often, because the other system's documentation, test environment and quirks are outside anyone's control. Name every integration up front.
- 04
Real-time and multi-language
Live updates (a dashboard that moves, a chat, a shared editor) change how the backend is built. Supporting English and French means every string, date, number and email exists twice and is tested twice.
- 05
Design depth
Using your existing design system costs the least design time. A clean, standard look costs a little more. A custom design, and above that a full brand system with illustration and motion, costs the most designer hours, and some extra frontend hours to build it faithfully.
- 06
Compliance
Personal information brings privacy work: consent, retention, access requests and careful logging. Regulated data (health, finance, government) adds formal records, stricter access control and more testing, and it touches every role, not just the engineers.
- 07
Urgency
A tight deadline means more people working in parallel, which adds coordination. Rushing never makes software cheaper; a flexible date usually makes it a little cheaper.
Three web apps, priced from our rate card today
The worked examples below show the range from our rate card today, with the hours by role and the payment schedule. They are priced when you open the page, so they are never out of date. Open any of them in the estimator to change a choice and watch the hours move.
Worked example, priced now
A small web app: an internal tool
Six screens, sign-in for staff, a simple admin side and a clean standard design. The kind of tool that replaces a shared spreadsheet for one team.
- Build
- ≈ US$23,900 to US$36,600, delivered within 12 weeksCAD 34,100 to 52,100
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Estimated effort by role
- Development
- 139 to 212 h
- Frontend developer
- 23 to 36 h
- Project manager
- 20 to 31 h
- Senior backend developer
- 19 to 29 h
- Backend developer
- 18 to 28 h
- Product designer
- 15 to 23 h
- Senior frontend developer
- 14 to 21 h
- QA engineer
- 14 to 21 h
- Senior engineer
- 10 to 16 h
- Senior product designer
- 10 to 16 h
- Software architect
- 10 to 15 h
- Junior frontend developer
- 9 to 14 h
- Junior backend developer
- 9 to 14 h
- DevOps engineer
- 5 to 7 h
- Technical writer
- 2 to 4 h
How it is paid
- Deposit 30%
- CAD 10,230 to 15,630
- Discovery 6.6%
- CAD 2,250.60 to 3,438.60
- Design approved 6.6%
- CAD 2,250.60 to 3,438.60
- Core features 20%
- CAD 6,820 to 10,420
- Full build 13.3%
- CAD 4,535.30 to 6,929.30
- Testing and fixes 6.6%
- CAD 2,250.60 to 3,438.60
- Launch 6.9%
- CAD 2,352.90 to 3,594.90
- Holdback, 30 days after launch (10%)
- CAD 3,410 to 5,210
Worked example, priced now
A medium web app: a customer portal with payments
Sixteen screens, customer sign-in, card payments, email notifications, search, document uploads and a custom design, holding personal information.
- Build
- ≈ US$59,300 to US$90,700, delivered within 17 weeksCAD 84,400 to 129,100
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Estimated effort by role
- Development
- 337 to 516 h
- Product designer
- 59 to 90 h
- Frontend developer
- 54 to 82 h
- Senior backend developer
- 47 to 72 h
- Backend developer
- 46 to 70 h
- Senior product designer
- 39 to 60 h
- QA engineer
- 39 to 60 h
- Senior frontend developer
- 32 to 49 h
- Project manager
- 32 to 49 h
- Senior engineer
- 25 to 39 h
- Software architect
- 24 to 37 h
- Junior backend developer
- 23 to 35 h
- Junior frontend developer
- 22 to 33 h
- DevOps engineer
- 8 to 12 h
- Technical writer
- 7 to 11 h
How it is paid
- Deposit 20%
- CAD 16,880 to 25,820
- Discovery 7.7%
- CAD 6,498.80 to 9,940.70
- Design approved 7.7%
- CAD 6,498.80 to 9,940.70
- Core features 23.3%
- CAD 19,665.20 to 30,080.30
- Full build 15.5%
- CAD 13,082.00 to 20,010.50
- Testing and fixes 7.7%
- CAD 6,498.80 to 9,940.70
- Launch 8.1%
- CAD 6,836.40 to 10,457.10
- Holdback, 30 days after launch (10%)
- CAD 8,440 to 12,910
Worked example, priced now
A large web app: a regulated platform
Forty screens in English and French, a full brand design, integrations with other systems, live updates, analytics and regulated data, on a larger cloud setup with a support plan.
- Build
- ≈ US$140,000 to US$215,000, delivered within 30 weeksCAD 199,800 to 305,600
Prices in your currency are estimates from today's Bank of Canada rate. All invoicing is in CAD or USD.
Estimated effort by role
- Development
- 718 to 1098 h
- Product designer
- 223 to 342 h
- Senior product designer
- 149 to 228 h
- Frontend developer
- 122 to 187 h
- Senior backend developer
- 92 to 141 h
- QA engineer
- 88 to 134 h
- Backend developer
- 87 to 133 h
- Senior frontend developer
- 73 to 112 h
- Project manager
- 59 to 90 h
- Senior engineer
- 54 to 82 h
- Junior frontend developer
- 49 to 75 h
- Software architect
- 49 to 75 h
- Junior backend developer
- 44 to 67 h
- DevOps engineer
- 21 to 32 h
- Technical writer
- 16 to 24 h
How it is paid
- Deposit 20%
- CAD 39,960 to 61,120
- Discovery 7.7%
- CAD 15,384.60 to 23,531.20
- Design approved 7.7%
- CAD 15,384.60 to 23,531.20
- Core features 23.3%
- CAD 46,553.40 to 71,204.80
- Full build 15.5%
- CAD 30,969 to 47,368
- Testing and fixes 7.7%
- CAD 15,384.60 to 23,531.20
- Launch 8.1%
- CAD 16,183.80 to 24,753.60
- Holdback, 30 days after launch (10%)
- CAD 19,980 to 30,560
How to read the role breakdown
Compare the three examples role by role rather than by the total. A few patterns show up in almost every web project.
- Project management grows with the project, but not in proportion. A larger project has more milestones and more people to coordinate, yet the core of planning and reporting is there from the first week.
- Design jumps with design depth, not just screen count. Moving from a clean standard look to a full brand system changes the designer's hours more than adding a handful of screens.
- Backend hours follow the features. A small internal tool is mostly screens; a portal with payments and uploads is mostly rules, data and edge cases.
- QA rises sharply with payments and regulated data. Testing a payment flow means testing refunds, failures, retries and what a customer sees when a card is declined.
- Architecture and DevOps are small on a small app and essential on a large one. A platform with integrations and live updates needs someone to decide how the parts fit before anyone builds them.
If a quote you receive shows almost no QA, or no project management, the work has not disappeared. It has moved to you, usually after launch.
Where to cut, and where not to
Most budgets are tighter than the first estimate. That is normal, and there are good and bad ways to close the gap.
| Usually a good cut | Usually a bad cut |
|---|---|
| Fewer screens in the first release, with the rest planned for later | Less testing on payments or anything that touches money |
| A clean standard design instead of a full brand system, for an internal tool | No accessibility work on a public site |
| One language at launch if your users really are in one language | No backups, monitoring or a way to restore |
| An off-the-shelf tool for a side need, such as a help desk, instead of building it | Skipping the handover documents, so only the original team can run it |
| A flexible launch date | Removing the security review before launch |
Accessibility deserves a word on its own. The W3C's Web Content Accessibility Guidelines define three levels of conformance, A, AA and AAA [1], and AA is the level most organisations aim for. Building to it from the start costs far less than retrofitting it, and retrofitting is usually what happens when it is cut.
Security is similar. The OWASP Application Security Verification Standard is a published list of requirements for testing a web app's security controls [2]. Ask any studio which parts of it they check against, and when. A cheaper quote that leaves security until the end is a more expensive project.
Sometimes the right cut is not building at all. If your need is a simple booking page, a form or an online shop, a hosted product will cost less than a custom app for years. We will say so when it is true. Custom software earns its price when your process is your advantage, or when no product fits it.
What is not in the build price
The build is a one-off cost. Three other kinds of cost sit beside it, and a good estimate names all of them.
- Hosting, every month: the servers, the database, storage and backups, from the provider you choose, plus our management if we run it for you.
- Support and maintenance, every month if you want it: security updates, dependency upgrades, small fixes and someone to call when something breaks.
- Third-party costs: email sending, payment processing fees, maps, SMS and any licences. These are billed at cost and are often small, but they grow with use.
Our guide to what software costs after launch walks through those running costs with examples of its own.
Comparing quotes from different studios
- 01
Ask for the hours by role
A single total tells you nothing about what was assumed. Hours by role show whether design, testing and project management are in the price or quietly left out.
- 02
Ask for the assumptions
The screens, features, integrations and design depth each quote was built on. Two quotes are only comparable when the assumptions match.
- 03
Ask what is excluded
Hosting, support, third-party fees, content entry and data migration are the usual suspects.
- 04
Ask how changes are priced
Every project changes. A clear change order process matters more than a low first number.
- 05
Ask who owns the code
It should be yours once it is paid for, in your own repository, with the accounts in your name.
A deposit, milestone payments and a holdback after launch are how we split the risk on a fixed-price build. The schedules above show each milestone for the examples, and our guide on payments explains why it is set up that way.