The real drivers of web platform cost: roles, integrations, migration, design, bilingual work, security, hosting and team shape, and how to cut scope.
A web platform's cost follows its complexity, not its page count. The biggest drivers are how many kinds of user it serves and what each can do, how many other systems it talks to, how much existing data must move in, how deep the design goes, and how much security and upkeep it carries. Most of these multiply rather than add, which is why two platforms that look alike on a sitemap can differ widely in effort.
By web platform we mean a product people sign in to and use: a portal, a SaaS product, a marketplace, a booking system, a customer dashboard. You will not find figures here, and that is deliberate: a number named before a scope exists is a guess. Learn the drivers and any quote, from us or anyone else, becomes something you can test. For the mobile equivalent, read [how much a mobile app costs](/blog/how-much-does-a-mobile-app-cost).
Why cost multiplies instead of adding
Picture the platform as a grid. Every user role needs its own screens, permissions and tests. Every language needs its own content, layout checks and review. Every integration needs its own error handling. Add a role and many features change at once; add a language and every screen is touched. So the quickest way to lower a quote is to reduce one multiplier, not to shave a little from every feature.
Users, roles and workflows
An admin, a customer, a partner and a support agent each see different screens, trigger different actions and need different checks. The permission rules cost more than the screens: 'a manager sees only their branch and approves refunds up to a limit' is one sentence that touches the database, the interface, the audit trail and the tests. Access control is also a security control, so it needs a [threat model](/glossary/threat-modelling) as well as code.
A form that saves a record is cheap. A form that routes it through approvals, recalculates totals, notifies three people and handles exceptions is not. Ask which rules are real and which are habit, and write them down in plain language before design starts. Exceptions found on paper cost nothing; found in testing, they cost a lot.
Integrations, data and content
Each connection to another system, such as a payment provider, an identity service, an accounting or ERP system or a partner's [API](/glossary/api), brings documentation to read, a test environment, an approval process, error handling and monitoring. The unknowns sit with the other party: slow approvals, thin documentation, request limits. Count the integrations, note which have good documentation and a sandbox, and treat the rest as the riskiest lines of the estimate.
Moving from an old system is underestimated because attention goes to the new one. The work is in the old data: duplicates, missing fields, inconsistent formats, records that depend on rules nobody remembers. Decide early what must come across, what to archive and what to start fresh. Content has the same problem, since pages, documents and product descriptions must be written, cleaned or translated by someone. The code that imports data is rarely the expensive part; checking that it arrived correctly is.
Design, language and security
Familiar components and a small kit keep effort down. Custom motion, bespoke illustration and many unique page types push it up. Research and usability testing add time early and remove expensive rework later. A [design system](/glossary/design-system) costs more at first and pays back on every later screen, and accessibility to [WCAG](/glossary/wcag) is cheapest when it is built into the components, not fixed screen by screen afterwards.
English and Arabic is not a translation task at the end. A right-to-left layout mirrors navigation, icons, tables and forms, and Arabic needs its own typography and natively written copy. Planned from the first screen, it adds a modest amount to every screen. Retrofitted, it means reopening components built for left-to-right. Content volume matters too: every page, email and error message exists twice and must stay in step. See the [Arabic website checklist](/blog/arabic-website-development-checklist).
Threat modelling, secure coding, dependency scanning, testing and a review before launch take time, and so do sign-in with [multi-factor authentication](/glossary/multi-factor-authentication), audit logs and careful handling of personal data. Regulated sectors add questions about where data lives and who may see it. Doing this at the start is cheaper than adding it once the architecture is fixed. Confirm legal duties with qualified counsel; this article is not legal advice.
Performance, hosting and upkeep
Performance becomes a cost driver with very large datasets, heavy search, real-time updates or sharp traffic spikes. Standard pages over modest data need little beyond good practice; fast filtering over very large tables needs design work on the database, caching and monitoring.
Hosting is part build question (how many environments, how releases and rollbacks work) and part running cost that grows with use. Backups, monitoring and a plan for restoring service belong in scope. After launch, dependency and security updates, framework upgrades and small changes are a recurring line, not a surprise. The [secure-by-default web checklist](/blog/secure-by-default-web-checklist) lists what a platform should have in place.
How the work is organised
A **fixed scope** prices a defined product up front. It suits clear, stable requirements, and anything new goes through a change request. A **dedicated team** is paid monthly for capacity and suits a product that keeps evolving. [Pricing models](/company/pricing-models) compares them, and the [pricing page](/pricing) describes our three shapes, from a discovery sprint to a monthly team.
Your side of the table matters as much. One product owner who answers within a day keeps a team moving. A committee that reviews in rounds, or a scope that shifts weekly, adds cost whoever builds it. Weekly demos help because disagreements surface while they are still cheap to fix.
How to cut scope without hurting the product
| Safe to defer | Never cut |
|---|---|
| Second and third user roles | Access control and sign-in security |
| Automation of rare cases | Testing and a security review before launch |
| Advanced reports and custom animation | Backups and a restore plan |
| Languages beyond English and Arabic | Accessible components and the right-to-left foundations |
What to ask in a quote
A good quote states its assumptions. These questions expose them:
- Which user roles are included, and what can each one do?
- Which integrations are included, and who deals with it when a third party changes or fails?
- What is assumed about migrating data and content, and who checks it?
- How many languages, and is right-to-left design part of the base or an extra?
- What testing, accessibility work and security review happen before launch?
- How many environments, where is it hosted and who pays the running costs?
- How is a change in scope priced?
- What do I receive at the end: source code, documentation, access to every account? And what does support after launch cover?
When two quotes differ, compare their assumptions line by line before you compare totals. The gap usually sits in one or two lines. For how we approach this work, see [web development](/services/web-development), including [SaaS platforms](/services/web-development/saas-platforms) and [e-commerce](/services/web-development/ecommerce).