GUIDE · WEB SYSTEMS · BUDGET
Budgeting a web system: what do you define before asking for a quote?
The price of a business system is not set by the number of screens. It is set by who uses it, what it replaces, and what it connects to.
Onezero LabsUpdated 11 min read
| Factor | What to ask | Why it matters |
|---|---|---|
| System type | Internal operations, a portal for external users, or a multi-step process? | Determines authentication, permissions, design and robustness |
| Roles and entities | Who are the users and what "things" do they work on? | Every extra role = permissions and screens; every entity = a data model and states |
| Integrations | Which systems does data flow to, in which direction, and what happens when they are down? | A two-way link to a legacy system is usually the single most expensive item |
| Data migration | What moves from the previous system, in what quality, and who cleans it? | Almost always missing from the first quote; almost always needed |
| Testing and rollout | Who tests, on which scenarios, and how do users learn to work? | A system that was not rolled out is a system that was not built |
"How much does a system like that cost?" usually gets one of two bad answers: a number thrown out before anyone understood what the system does, or "it depends" with no explanation of what on. This guide gives the explanation. It is not a pricing guide — there is no rate table in it — but a scope guide: how to describe a system so it can be priced, which costs tend to be missed, and what a responsible estimate depends on. Whoever arrives at a requirements meeting with the questionnaire at the end will get a quote that can be compared — and will not discover the data migration a month after signing.
Identify the system type
Before counting screens you need to know which of three families the system belongs to, because each family drags in a set of requirements that does not show up in the screen diagram:
| Type | Who uses it | What comes with it "for free" | Examples |
|---|---|---|---|
| Internal operations | Employees, usually a few dozen, who know the domain | Organizational sign-in, permissions by department, reports, export; functional design is enough | Order management, inventory, service tickets, internal approvals |
| Portal for external users | Customers, suppliers or partners — untrained and unforgiving | Self sign-up and sign-in, data separation between customers, product-grade design, accessibility, support | Customer portal, supplier area, submission system |
| Multi-step process | Several user types moving an entity from stage to stage | A state machine, notifications, history and audit, an internal SLA per stage, documents generated along the way | A tender, a credit approval, recruiting, a claim |
Scope scenarios: roles, entities, screens and integrations
A system's scope is described by four numbers you can count before writing a line of code: how many roles (user types with different permissions), how many entities (the "things" the system manages — an order, a customer, a document), how many screens (list, details, form, report — per entity and role), and how many integrations (external systems data flows to or from). The three scenarios below show how the four numbers move together.
| Scenario (illustration) | Roles | Entities | Screens | Integrations | Migration and rollout |
|---|---|---|---|---|---|
| A. Internal ops tool replacing a shared spreadsheet | 2 — operator, manager | 3 — task, customer, note | ~8 — list/details/form per entity + one report | 1 — organizational sign-in; export to Excel | A one-time import from the spreadsheet; an hour's training for one team |
| B. Customer portal on top of an existing system | 3 — customer, service rep, admin | 4 — account, request, document, message | ~15 — including sign-up, password recovery, account area and admin screens | 3 — two-way CRM/ERP, email/SMS, identity | No migration (the source stays in the ERP); rollout = customer communication and first-month support |
| C. Multi-step process system for several user types | 4 — submitter, reviewer, approver, admin | 5 — case, stage, document, decision, note | ~25 — a screen per stage and role, history, dashboard, reports | 4 — identity, documents/signature, email, read-only link to the old system | Migrating open cases with cleaning; a parallel run; training per role |
Before describing scope for development, it is worth confirming that development is the answer at all: for some scenarios — mainly A — an off-the-shelf system or an adapted platform is enough. How to decide between the three routes, in a separate guide.
Buy a system, adapt a platform or build from scratch?The costs you don't see at first
The first quote you receive will almost always price what is visible — screens and features. The following four items do not appear in the screen diagram, and in business-system projects they are often a large share of the actual work:
| Item | What it actually involves | The question the quote must answer |
|---|---|---|
| Data migration | Mapping fields between old and new, converting formats, handling partial records, trial runs, the final migration on switchover day | What moves, what stays in an archive, and who owns a record that cannot be converted? |
| Data cleaning | Duplicates, one customer name spelled three ways, empty fields that were mandatory, codes nobody remembers the meaning of | Who cleans — your team by rules the vendor defines, or the vendor? And at which stage? |
| Testing | Edge scenarios per role, testing the integrations when the other system returns an error, acceptance testing by the users themselves | Who writes the acceptance scenarios, and what happens when they fail — a fix inside scope or a change? |
| Rollout | Training per role, user documentation, a parallel run alongside the old system, heightened support in the first weeks, switching the old system off | How long do both systems live side by side, and who decides when they disagree? |
Estimate and dependencies: what the number depends on
A responsible estimate for a business system always comes in two layers: a range, and the assumptions behind it. The range without the assumptions is meaningless — the same range could describe a two-role system or a four-role one, with one integration or three. These are the assumptions that should appear next to any range you receive:
- The number of roles and entities counted, and the list of screens derived from them — not "a management system" but a list.
- Which integrations are included, in which direction, and what is assumed about the other system (is there a documented API? a technical contact? who pays for a change on its side?).
- Whether migration, cleaning, acceptance testing and rollout are included — or explicitly marked as not needed or as your responsibility.
- What counts as a change: an added role? a new field on an entity? another report? And how a change is priced.
- What is deliberately excluded — brand design, content, third-party system licenses, cloud hosting, for example.
A binding number — not a range — can only be given after requirements, when the lists above have become a document that can be signed. A vendor who gives a binding number in the first meeting is either working with very large safety margins or will make up the difference through change requests. What such a requirements document looks like, and what it must contain, in a separate guide with a downloadable template.
A requirements document example — a filled-in templateScope questionnaire — fill in before asking for a quote
Ten questions. The answers do not need to be perfect — "we don't know" is a legitimate answer that tells the vendor where requirements need to start. Whoever answers these ten gets quotes that can be compared, because every vendor priced the same thing.
- Who are the users? A list of roles, how many people per role, and whether they are your employees or external users.
- What does each role do in the system? Three to five main actions per role, in the business's language.
- What "things" does the system work on? A list of entities (order, customer, case, document) and which states each one has.
- Which process does the system replace, and how is it done today — spreadsheet, email, group chat, an old system?
- Which other systems need to talk to the new one? For each: which way the data flows, and who owns it.
- Which of the existing data must move? How many records, in what quality, and who can clean it.
- What must keep working on switchover day, without even a day's interruption?
- Which reports or exports are required, for whom, and how often?
- Who on your side will decide open questions during the project, and how much time do they have for it?
- What will not be in the first version — even if it comes later?
The answer to the last question is usually the biggest saving. A business system does not have to launch with every role and every report in the first version — it has to launch with the core process working end to end, and the data correct.
What we do at this stage
Before a quote we do a short mapping of the system: roles and actions, entities and states, the integrations and the state of the existing data. The output is a scope document — what is included, what is not, what is deferred to the next version — and the estimate is based on it, with the assumptions written beside it. If the mapping shows that an existing platform is enough, we will say so. What the web systems and portals service looks like, and which kinds of systems we build — on the service page.
Web systems and portals development — what is includedWhen the need is broader than a single system — a process that crosses departments, or a product the business itself runs on — that is the custom software development service, which also has a section on what a system includes beyond its screens.
Custom software development — the anatomy of a systemFAQ
Frequently asked questions
There is no single number, because "web system" covers an internal tool for two roles as well as a customer portal with a two-way ERP link. The budget is set by four numbers you can count in advance — roles, entities, screens and integrations — and by four items that do not appear in the diagram: data migration, cleaning, testing and rollout. A responsible estimate gives a range with its assumptions after a short mapping, and a binding number after requirements. A number given without those is a guess.
In a consumer app the cost is driven by screens, user experience, the stores and a backend serving many anonymous users. In a business system the cost is driven by roles and permissions, a data model with states, integrations with existing systems, and migrating data from a previous system. That is why the app pricing guide does not translate to a system — the expensive items are different.
No. A portal displayed on top of an existing system — where the data stays — needs no migration. A system for a new process that did not exist before also starts empty. Migration is needed when the new system replaces an existing data source: a spreadsheet, an old system or folders of documents. Either way the answer — needed or not — should appear in writing in the quote.
In our experience, not the number of screens. Three things: a two-way integration with an existing system that has no documented API or technical contact; a multi-step process with many states and exceptions that surface along the way; and low-quality existing data that must be cleaned before migration. Any of the three can be bigger than all the screens combined.
You can get a range with assumptions — after a short mapping and with the scope questionnaire filled in. A binding number without requirements is either a large safety margin you pay for, or a commitment that will be corrected through change requests. The cheapest route to an accurate quote is to pay for a short requirements phase and end it with a scope document any vendor can price.
The scope questionnaire from this guide, even if some answers are "we don't know". Also: an example of the process as it runs today (the spreadsheet, the emails, a screenshot of the old system), a list of systems that need to connect with a technical contact for each, and an initial decision on what stays out of the first version. With those, the first meeting ends with an initial scope document instead of a list of questions.
Keep reading
- ServiceSoftware DevelopmentSystems, backend, architecture. Code that lasts.
- ServiceWeb Apps & SystemsWebsites, platforms, dashboards. Idea to production.
- GuideAn app requirements document: a filled-in template that shows what to defineNot a feature list. A document a developer can price and a manager can sign off.
Let's talk
Got a project to scope?
One conversation. You leave knowing what the first version needs to contain and what it will take to build it.
Straight. To the point. On time.