Most custom software estimates are built by counting features: how many screens, how many user roles, how many reports. That method produces a number, and the number is usually wrong, because for the kind of integration-heavy platforms we build, features are rarely what determines effort. The systems the software has to talk to are. A CRM with twenty screens and no external integrations is a materially smaller project than a CRM with five screens that has to stay in sync with three portals, an accounting package and a legacy booking system. Counting the screens tells you almost nothing about which of those two projects you are actually scoping.
Why feature counting misleads on integration-heavy builds
A feature list describes what a user does inside the software. It says nothing about what the software has to reconcile with outside itself, and for most of the platforms our clients need, that external surface is where the real engineering effort sits: keeping two systems' understanding of the same fact — a property's availability, a customer's contract status, a meter reading — consistent when neither system was designed with the other in mind. A feature-based estimate treats "sync listings to Rightmove and Zoopla" as roughly one line item alongside "add a filter to the search screen." The two are not remotely comparable in effort, risk or the number of things that can go wrong after launch.
What an integration surface actually contains
We estimate a build by first mapping every system it needs to exchange data with, and then assessing each one against a consistent set of questions, because the answers — not the existence of the integration itself — are what determine effort:
- What interface mechanism does the other system actually expose? A modern REST or GraphQL API with good documentation is a different proposition to a nightly CSV export, a screen-scrape of a portal with no API at all, or a supplier-specific format like RTDF or BLM that has to be generated to match an exact specification before a receiving system will accept it.
- Who owns the field-level system of record? When both systems can hold the same fact — a contact's phone number, a property's price — a decision has to be made, and built, about which one wins when they disagree, and what happens to the update that loses.
- What is the expected volume and update frequency? A batch sync run once a day is a different architecture to a near real-time requirement, such as a property's availability needing to update within minutes of a status change, which is the standard we describe for portal integration on our portal integration page.
- What is the failure behaviour? Every integration fails sometimes — an API goes down, a file arrives malformed, a webhook is missed. The question that actually drives effort is what the system does when that happens: silently drop the update, retry automatically, or surface it to a queue a person can act on. Building the third option properly, consistently, across every integration in scope, is a substantial share of the total effort on most of our projects.
Worked examples from the systems we actually integrate with
This is not an abstract argument. It maps directly onto systems we build against regularly. A property management platform integrating with Rightmove and Zoopla has to generate feeds in RTDF and BLM respectively — two different formats from a single internal property record — and separately handle enquiry capture and duplicate suppression when the same applicant contacts the same listing through more than one portal, work we describe in detail on the portal integration page. None of that shows up as a "feature" a client would list in a brief; it shows up as an integration surface that has to be estimated on its own terms.
Where an agency already runs Reapit or Alto as its core lettings or sales platform, adding a bespoke tenant portal or lettings CRM means the new build has to integrate cleanly with whichever of those two the agency already depends on, each with its own API shape and its own constraints on what can be written back versus only read. A hospitality group running Lightspeed for front-of-house EPOS and needing order injection from Deliveroo, Uber Eats and Just Eat is, in integration-surface terms, taking on four separate systems with four different failure modes — not one "delivery integration" feature — as covered on our EPOS integration page, and the same principle applies to a group running Tevalis or another EPOS platform instead. A legal practice's matter management build that has to stay consistent with Clio or LEAP as the existing case management system carries the same shape of problem again: the effort is concentrated in the boundary between the new system and the one it must not contradict, not in the new system's own screens.
Counting systems instead of features changes the estimate itself
Once a project is scoped by integration surface rather than feature count, the estimate looks different in a specific, useful way: it separates cleanly into the core build — the parts of the software that exist independently of any external system — and a set of integration line items, each estimated against the four questions above rather than lumped into a single "integrations" contingency figure. This is the difference between an estimate a client can interrogate and one they simply have to trust. If a supplier's API turns out to be worse documented than assumed, or a legacy system's export format turns out to need more transformation than expected, the client can see exactly which line item that risk sits against, rather than watching an undifferentiated total creep upward with no visible cause.
It also changes where risk should sit in the contract. A core build with no significant integrations is estimable with reasonable confidence up front. A build with five or six integration points, several of them against systems the team has not previously integrated with, carries a genuinely wider range, and an honest estimate says so rather than presenting false precision. This is exactly the gap a discovery and scoping sprint exists to close: mapping every system in scope, confirming what interface mechanism each one actually offers, and producing a phased estimate with a stated confidence level per phase, rather than a single number covering work that has not yet been investigated.
What this means for a buyer reading a quote
If a proposal for an integration-heavy build presents a single lump-sum figure with no breakdown by system, that is worth challenging directly, because it usually means the integration risk has been priced by guesswork rather than by investigation. A proposal organised around enterprise integration work as its own line, listing each system, its interface mechanism, and the confidence level attached to each, is not more expensive because it is more detailed — it is more honest about where the actual cost and risk in the project sit. Counting systems instead of features does not change how many hours a build takes. It changes whether the estimate reflects the work that will actually happen.