Why there is no number on this page
A published range answers a question the buyer has not asked yet. Two companies can describe the same platform in one sentence and need entirely different builds, because the sentence hides how many roles touch the work, how many exceptions the process carries, and what already exists that has to be connected to. A figure quoted before any of that is known is a guess, and both sides find that out during the build.
What follows is the list of variables that actually move the scope. Read it as a self-assessment: the more of these you can answer about your own operation, the narrower the estimate anyone can give you, including us. A fixed quote follows the first conversation, because that conversation is what turns the variables into a scope.
How many roles there are, and how different they are
Each role is another view of the same data: a different navigation, a different set of permissions, and often a different dashboard. Two roles that differ only in what they may edit add little. Two roles that need different screens, different queues and different figures are close to two products sharing one database, and they get built that way.
Outside parties weigh more than internal ones. Every client, supplier or contractor who gets in adds an exposure decision: what they see, and what they must never see. That decision has to be enforced where the data is read, tested, and documented. An internal role is a convenience; an external one is a boundary, and boundaries get reviewed one at a time.
What counts is not job titles, it is distinct permission sets. Six titles that see the same thing are one role. Two titles that see different rows are two. Ask how many genuinely different answers the system has to give to the question of what this person may see. That count, and not how many people work there, is what moves the access layer.
How much of the process is a state machine
A process that is one form and one inbox is a form. A process with states, owners, elapsed time, approvals and exceptions is a state machine, and each one carries its own transitions, its own permissions per transition, its own history and its own edge cases. Counting the state machines predicts the scope better than counting screens.
The happy path is the easy part. What moves scope is the return, the reversal, the partial approval, the case that skips a step because a manager said so. Every exception either becomes a modelled transition with a record, or it becomes a message in a chat that nobody can audit later. Deciding which is which is a scoping conversation, not a coding one.
Once a process carries committed response times, something has to watch the clock, raise the item before it is late, and report the pattern afterwards. That is a queue, a rule per state and a report. It earns its scope where a missed commitment costs you a client, and it is overbuilt where nothing was promised in the first place.
Does money move through it, and what has to connect
When a platform calculates what somebody has earned — commission scales, threshold validation, a monthly close that moves through an approval flow — the tolerance for error disappears. Figures have to reconcile, every change needs an actor and a timestamp, and the close needs a flow that someone signs. A read-only dashboard can be wrong for an afternoon. A commission module cannot.
Every system that already exists is a source, a destination or both, and each one brings its own authentication, its own idea of what a record is, and its own outages. Integrating against a documented interface is work. Integrating against a system whose owner is a third party and which has no interface is a negotiation before it is work.
Years of history in spreadsheets with private conventions are not copied, they are excavated, with the people who know the exceptions in the room. Some migrations take days and some are the single largest item in the build. What decides it is not volume, it is how many unwritten rules ended up stored in the way somebody formatted a column.
What narrows the estimate before you ask for a proposal
Write the process down as it actually runs, not as the manual describes it: the overrides, the exceptions, the step somebody skips when the client is important. A process that is already documented removes the part of the build that is agreement rather than code. When it does not exist, we do that as a diagnosis first, and that is the honest order.
Then decide what goes into the first version. Scope runs away when a platform tries to carry every process at once. One complete process, running on real data with the people who use it daily working inside it, tells you more about the rest of the build than any document. Everything after that is scoped against something that already works.