"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 | Organisational 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 |
What a multi-step process looks like once it is built into a system — roles, states and integrations — can be seen in the Michrazit case study, in the section describing how the manual process became a system. Michrazit — how the process was built into the system
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 — organisational 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 licences, 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 template
Scope 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, WhatsApp, 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 included
When 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 system