You've received three proposals for the same project, and they're miles apart. The lowest is a small fraction of the highest. You don't know which one is right, or what number to put in next year's budget.
Let's draw a line first: this article isn't about a small brochure site. It's about enterprise projects with several stakeholders, integrations and approval steps. In a project like that, the price isn't set by the number of pages; it's set by the uncertainty inside the project. Below we cover the factors behind that uncertainty, the pricing models, and how to read the proposals in front of you side by side.
Why do enterprise website prices vary so much?
Because the teams sending proposals often aren't pricing the same work. They read the same brief, imagine different projects, and each prices what they imagined.
Broadly, you'll see three kinds of proposal:
- Template site. A ready-made template filled with your content. Fast and affordable, but the integrations, security review and approval process an enterprise project needs are usually out of scope.
- Agency. Takes on design and development together. Scope and quality vary a lot from agency to agency; some outsource part of the work.
- Studio. Runs research, design and engineering in one team. The proposal usually starts with a discovery phase, because a studio wants to understand the problem before pricing it.
Most of the numbers you see when you search for "website design cost" belong to the first group. In an enterprise project, the real cost isn't in drawing the screens; it's in getting those screens to talk correctly to the systems behind them, and getting sign-off from the right people.
What really drives the price?
An enterprise project's budget depends less on page or screen count than on the factors below.
Scope and uncertainty. How clear is what needs to be done? A team that knows its problem and goal needs less discovery. A project that starts with "sales are falling but we don't know why" needs research first.
Research. Are user interviews, usability tests and analytics review in scope? Research looks like an extra line in the budget, but it's the line that most reduces the risk of building the wrong thing.
Multi-stakeholder approval. In large companies, a design decision can pass through the business unit, IT, legal, marketing and senior leadership.
Integrations. ERP, CRM, single sign-on (SSO), payment systems, internal databases. How many systems a site or app has to talk to is often a bigger cost than the design itself.
Data protection and security review. If personal data is processed, privacy notices, consent flows and retention rules become part of the design, shaped by the data protection laws that apply to you. Your IT team's security review and penetration testing requirements also affect the schedule and scope.
Multiple languages. Two languages, maybe more. Each language isn't just translation; it means content management, search engine settings and a design that copes with text of different lengths.
Enterprise design system and group companies. If group companies will use the same components, you need a reusable design system rather than a single site. That raises the cost of the first project and lowers the cost of the ones after it. We discuss the role of design systems in enterprise redesigns in how enterprises should approach a product redesign.
Content. Who provides the copy, images and video? If content production is in scope, it's a separate line item; if not, when the content arrives sets the project's schedule.
After launch. Maintenance, hosting, updates and small improvements. Launch day isn't the end of a project; it's the beginning.
Currency, payment plan and timing. Budgets are often approved in one currency while proposals arrive in another. If the project runs for months, exchange rate and price changes affect what the budget is really worth. Tying payments to milestones, agreeing which date sets the exchange rate and deciding which fiscal year the budget sits in matter as much as the amount.
Mobile app pricing: how is it different from web?
Mobile app pricing adds a few mobile-specific layers on top of the factors that drive web projects.
Platform choice. Will the app be iOS only, Android only, or both? Two separate native apps give the best performance and platform experience, but mean two separate codebases. Cross-platform solutions (one codebase, two platforms) are enough for most enterprise apps and make maintenance easier.
Device features. Camera, location, notifications, offline mode, biometric login. Each needs its own design and testing. In apps for field teams especially, offline mode can be the hardest part of the project.
App store processes. The App Store and Google Play have review rules, account requirements and update cycles.
Maintenance. Operating systems update every year, and the app has to keep up. In mobile, maintenance isn't optional; it belongs in the budget from the start.
How much does it cost to build an app?
Projects start from around $10–15k. The final budget for an app depends on these factors:
- Platform: iOS only, Android only, or both?
- Back-end and integrations: How many systems, such as ERP, CRM or authentication, will the app talk to?
- Research and design scope: Are user research and a design system in scope?
- Personal data and security: Are there data protection requirements and a security review?
- Maintenance after launch: Who takes on operating system updates and new development?
When research, design and development sit in one team, these items aren't priced one by one; they're read as a single scope. Use the questions below to work out your own budget.
Where does an enterprise project budget start?
Beyond that starting point, your scope sets the rest.
To work out your own budget, run the factors above through these questions:
- Are the problem and goal clear, or do you need a discovery phase first?
- Is user research in scope?
- How many systems need integrating, and are they documented?
- Is personal data processed, and is a security review needed?
- How many languages and platforms are there?
- Is the design system just for this project, or will group companies use it too?
- Who will provide the content?
- Who will own maintenance and development after launch?
The questions you can't answer are what discovery needs to settle.
Pricing models: fixed price, retainer, team augmentation
How a proposal is priced matters as much as the amount. There are three basic models you'll meet in large companies:
Fixed price. A set amount for a set scope. It fits procurement most easily, because the budget is known up front. But it needs a very clear scope. If the scope is uncertain, the team either prices the risk in or every change turns into a new proposal.
Retainer. Regular team capacity for a set period. It suits companies that want to keep improving the product after launch. It can be planned as an annual line in the budget cycle, but it needs a product owner to prioritize what gets done each period.
Team augmentation. People from an outside team work inside your team in specific roles. It's flexible, but management and accountability for results stay largely with you. Without a strong internal product team, it may not deliver what you expect.
In practice, many enterprise projects combine these models: a fixed-price discovery phase, then a design and development phase with a settled scope, then a retainer after launch.
How do you read three proposals side by side?
The easiest way to compare proposals is to write down what each one covers in the same table before you look at the amounts. You can fill in the table below with your own proposals:
| What to check | Proposal A | Proposal B | Proposal C |
|---|---|---|---|
| Is the scope written clearly? Are exclusions stated? | |||
| Is there a discovery or research phase? | |||
| Is there usability testing? | |||
| Is a design system delivered? | |||
| Are integrations in scope, and which ones? | |||
| Are data protection and security requirements addressed? | |||
| Are source code and design files handed over to you? | |||
| Is there post-launch maintenance and a warranty period? | |||
| How are revision rounds defined? | |||
| Is the payment plan tied to milestones? | |||
| Which currency is it priced in, and who carries the exchange rate risk? | |||
| Who will work on it, and is any work outsourced? |
Once you've filled it in, you'll usually see this: the lowest proposal is the price of the narrowest scope. The highest is sometimes genuinely expensive, and sometimes covers work the others never wrote down. Empty cells are the questions to ask the teams who sent them.
If you also want to judge teams by how they work, not just by their proposals, see how to choose a UX design partner.
Send your scope in a few sentences to hello@things.ist; we'll get back to you within 48 hours.
Why does the cheapest proposal usually cost more?
Because work that isn't in the proposal doesn't disappear; it just gets postponed.
Rework. A product designed without research gets redesigned after launch, wherever users get stuck. That second round is the price of the research skipped in the first. One way to lower the risk is to audit the existing product before starting a big project; we cover that in should you redesign or audit first.
Scope creep. In a project that starts with a narrowly defined scope, the "we thought this was included" conversations begin. Every extra piece of work means a separate proposal, a separate procurement approval and a separate delay.
Switching suppliers. If the project stalls or the result falls short, you need a new team. The time lost in that process is often more expensive than the money.
Files that aren't handed over. If source code or design files aren't delivered to you, you stay dependent on the same team to develop the product.
The shortest way to a realistic budget: a good brief
Proposals are only as good as the brief. A brief that states the problem, goal, scope, integrations and decision process clearly makes teams price the same work. Then the proposals really become comparable.
FAQ
How long does an enterprise website take? It depends on scope, integrations and the approval process. In enterprise projects, the timeline is often driven more by approval rounds and integrations than by design and development.
Which currency should proposals be in? Either can work; what matters is stating clearly who carries the exchange rate risk. On long projects, tying payments to milestones and stating in the contract which date sets the exchange rate protects both sides.
Are maintenance and hosting included in the price? In most proposals they're a separate line. If it isn't written, ask; who takes on what after launch should be clear from the start.
Does designing with AI make a project cheaper? It speeds up some work: synthesizing research notes, producing variations, prototyping. But the things that set the cost of an enterprise project, such as approval processes, integrations and making the right decision, are still human work. We explain where AI fits in the design process in what is an AI-augmented design studio.
Can we ask for proposals before our budget is settled? Yes. Give a range, or start with a short discovery phase. By the end of discovery the scope is clear, and the budget for the next phase becomes much more reliable.
Let's pin down your budget together
In short, here's who we are: a studio that works with AI and does design and development in one team. Things is one of the pioneering and leading companies in AI-driven design in Turkey. Since 2018 we've brought more than 50 products to life, and our work has won a Red Dot award. In enterprise projects, our first job is to settle the scope with you.
Send your scope in a few sentences to hello@things.ist; we'll get back to you within 48 hours. You can also reach us through our contact page.
Design. Engineering. Mastery.