Two things drive custom software development cost: how many systems your software has to stay in sync with, and how many separate organizational units it has to serve at once. Screen count barely moves the number. Two products with the same twenty screens can differ by a factor of three in price because one of them talks to a single database and the other has to keep Slack, Salesforce, a payroll provider and three regional rule sets agreeing with each other. If you are comparing quotes and the numbers look irreconcilable, that is almost always where the difference lives.
What custom software development cost actually pays for
When you ask how much does custom software cost, you are really asking about four separate things that vendors bundle into one figure.
Hours at a rate. This is the part everyone understands. Industry hourly rates cluster by region: Eastern Europe typically $40-100, Western Europe $75-200, the US $100-250. Those are benchmarks, not any single vendor’s price list, and they explain less than people expect. A team at $60/hour that needs three times the hours is not cheaper.
Scope that is visible. Screens, forms, reports, the mobile app. This is what a stakeholder points at in a demo, and it is the smallest part of the estimate on any serious build.
Scope that is invisible. Integrations, data migration, roles and permissions, audit trails, environments, error handling for every case where an external system does not answer. Nobody demos this. It routinely dominates the budget.
Risk. How much the vendor does not know yet about your business. An estimate on a vague brief is padded, renegotiated later, or both.
The cost of custom software is the sum of those four, and the last two are where estimates diverge. A useful test when you read a quote: find the line items that have no screen attached to them. If there are none, the vendor has priced the demo, not the system.
Why integrations cost more than screens
A screen is bounded work. You build it, you review it, it is done. An integration is not bounded by its interface — it is bounded by the other system’s behavior, which you do not control.
Take a single connection to a CRM. The happy path is a day of work. Then come the real questions. What happens when the auth token expires mid-sync? The API rate-limits you during the month-end spike and half the queue fails quietly. A write half-succeeds, so you have a record on one side and nothing on the other. Then the vendor changes a field type in a minor release. Each of those is a design decision, a piece of code, a test, and a thing to monitor in production. We wrote about this failure mode in detail in the context of sales automation, where the same conclusion held: most integration failures are not bad logic, they are expiring tokens, rate limits and half-succeeded writes at the system boundary.
Now multiply. Five integrations are not five times one integration, because they also have to agree with each other. If Slack says a shift was swapped, payroll has to agree, and the compliance report has to reflect the same version of events. That reconciliation layer is invisible in the UI and is often a third of the backend work.
This is not specific to any one industry. We saw the same shape in a fintech build, where integrations turned out to be one of the largest hidden contributors to the budget — the visible interface grew modestly while the operational surface behind it grew much faster.
What "it has to scale to several locations" really adds
This line appears in almost every brief, usually as a single sentence near the end. It is not a sentence. It is an architectural layer, and it is priced as one.
Multi-location means at minimum:
| Requirement | What it actually adds |
|---|---|
| Roles and permissions | A permission model that is per-location, not global. Who sees whose data, who approves across units, what a regional manager can do that a local one cannot. |
| Data isolation | Every query gets a scope. Every report gets a scope. Mistakes here are data leaks, so this needs tests, not just care. |
| Regional rules | Different payroll rules, different overtime thresholds, different reporting obligations per region — configurable, not hardcoded. |
| Aggregation | Reports that roll up across locations without double-counting people who work in more than one. |
| Wdrożenie | You cannot deploy a change to all locations at once if their rules differ. That means feature flags and staged migration. |
A single-office version of the same product skips all five. That is the honest answer to why two vendors quoting the same feature list can be far apart on custom software cost: one of them read that sentence and one of them did not.
An example from our practice
We built SAMAY, an HR and workforce platform for a client in Krakow. The feature list reads like a standard admin product: digital check-ins, time tracking, shift planning, absence management, storage for personnel documents, automated payroll calculations, and compliance reporting.
If you priced that list by screens, you would get a modest number. The actual shape of the work was different.
Where the budget actually went
The check-in and time tracking screens were the straightforward part. The budget went into two places. First, the integrations — the platform had to sit inside the tools the company already ran, from Slack for everyday shift and absence communication to Salesforce on the commercial side. Every one of those connections needed the boundary work described above: what happens when the external system is down during a check-in, how a change made in one place propagates, how you prove after the fact which system was the source of truth for a given payroll entry. Payroll automation makes that last question expensive, because a wrong number is not a bug report, it is a person’s salary.
What multi-location added
Second, the multi-location requirement. The system had to work for one office and for a network of offices across regions at the same time. That meant the permission model, data isolation, region-specific payroll rules and region-specific compliance reporting all had to exist as first-class concepts from the first architecture decision, not be retrofitted. Data migration from the previous tooling had to respect those same boundaries — you cannot import a flat export into a scoped system without deciding, row by row, which scope each row belongs to.
The engineering conclusion we took from that build: the requirement that costs the most is almost never the one written in the largest font. “Multi-location” was one line in the brief and one of the largest cost drivers in the project.
What to watch out for
Discovery is not overhead. A discovery phase that maps your integrations, your permission model and your regional variations converts unknown risk into priced scope. Skipping it does not save money; it moves the cost into change requests at a worse rate.
Fixed price vs time and materials is a question about certainty, not about safety. On a well-defined scope, fixed price genuinely protects you. On a vague brief, the vendor either adds a buffer or expects to renegotiate later — the same conclusion we reached when breaking down what actually sets an app budget: scope, not the idea. Time and materials is the honest model while scope is still moving, provided you get a per-sprint cadence and the right to stop. A practical pattern: discovery on time and materials, then fixed price on the scope discovery produced.
Compare custom software development rates last, not first. A rate tells you nothing about the hours. Ask each vendor how many hours they assigned to integrations and to the permission model. The spread in those two line items explains most of the spread in the totals.
Watch for estimates with no data migration line. Your existing data is messy, and cleaning it is real work that has to happen before go-live, not after.
Ask who owns the integration when the other vendor changes their API. If that is not written into the contract, it becomes an argument later, usually at the worst possible moment.
What to prepare before asking for an estimate
You will get better custom software development pricing if you arrive with four things written down: the list of systems the software must talk to and in which direction data flows; the org chart translated into roles and what each role may see; the list of locations and every rule that differs between them; and a description of the data you already have and where it lives. That document does more for the accuracy of a quote than any feature list.
Wniosek
Integration surface drives custom software development cost, together with the permission and isolation model behind multi-location support and with everything the contract still leaves unknown — not the number of screens in the design file. Regional rates set the unit price, but architecture sets the hours, and your requirements set the architecture — requirements you can write in one sentence and pay for over a year. The SAMAY build is a clean example: a conventional HR feature list, with the budget concentrated in integrations and in making one system serve one office and a network of offices equally well. If you want a number that survives contact with your actual environment, start with the integration map and the permission model. That is the work we do first on every custom software development engagement.
