How to Estimate Your Internal System Budget Before Asking for Quotes

An internal system's budget isn't determined by "screen count" or "feature count", but by 5 variables: business-flow complexity (including exceptions), integration level, data condition, permission complexity, and operations commitment. Estimate these 5 variables yourself before asking for quotes, and you'll compare proposals on a single frame of reference — instead of staring at numbers 3–5x apart.

TL;DR (Executive Summary)

  • Problem: Internal software quotes come back 3–5x apart with no basis for comparison, because requirements are described in "screens" instead of the variables that actually create cost.
  • Solution: The 5-variable cost framework + a scope-cutting matrix + a pre-RFQ checklist.
  • Result: Apples-to-apples quote comparison, cheap quotes with missing line items exposed, and scope cut deliberately rather than quality cut silently.

I've spent 14 years as a Delivery Manager, sitting on both the quote-writing side and the quote-evaluating side. What few people say plainly: most quote gaps exist not because one vendor is pricier, but because each is pricing a different product — inferred from the same vague requirement.

"Software budget" — redefined from the delivery floor

The common definition: budget = the number in the build contract. The correct definition from the field:

Software budget = Total Cost of Ownership (TCO) over the system's life — build, operations, modifications as the business changes, and the exit cost when replacement becomes necessary.

Across projects I've delivered directly, operations + modification costs over the first 3–4 years typically equal the initial build cost. A quote that's cheap to build but locks you into expensive modifications (or into dependency on the single person who understands the system) is an expensive quote.

The 5-variable cost framework

Variable Question to answer yourself Budget impact
① Business flows + exceptions How many flows? How many "happens occasionally" exceptions per flow? Largest — exceptions are where cost hides
② Integration level Which running systems must it talk to? Do they have APIs? Integrating with a legacy system without APIs can cost more than the main feature
③ Data condition Where does old data live (Excel, legacy software)? Is it clean? Must it migrate? Migrating dirty data is the most-forgotten line item
④ Permissions How many roles? Multi-level approvals? Data only some people may see? Every approval tier is a tier of logic + testing
⑤ Operations commitment What's the damage if it stops for a day? Who helps when it breaks at 8 PM? Drives infrastructure, monitoring, SLA — the part cheap quotes ignore

How to use it: answer these 5 questions in writing before meeting any vendor. That document becomes the appendix to your RFQ — and the yardstick every quote must be normalized against.

Why "screen count" is the wrong measure

Two systems with the same 10 screens can differ 5x in cost: one is CRUD data entry and viewing; the other has 3-level approval flows, real-time inventory sync, and 5 years of Excel data to migrate. A vendor that prices by screens — or accepts a screens-based description without asking about business exceptions — has already told you something about its process maturity.

The 3 cheap-quote traps

  1. Happy-path pricing — only the forward flow is counted; every business exception ("what if the customer returns part of an order?") becomes billable extras later. Exceptions typically make up 30–50% of the real workload.
  2. The empty data line — "load in the old data" sounds simple, but 5 years of unstandardized Excel is a sub-project. A quote with no data-migration line item is a time bomb set for the final month.
  3. Nothing after handover — silence on warranty, response times when things break, and the cost of small modifications. A cheap build price buys the vendor a monopoly position at the operations stage.

The scope-cutting matrix — when the estimate exceeds budget

When estimates exceed budget, most businesses cut wrong: keep the feature count, squeeze the price — and quality gets cut silently (testing dropped, exception handling dropped). The right way to cut follows a matrix:

Core business Supporting business
High frequency Build to full depth (incl. exceptions) Build a minimal version
Low frequency Semi-automate (human + tool) Cut — keep it outside the system

The principle: cut breadth (number of processes), keep depth (completeness of core processes). A system that does 3 things properly creates real value; a system that does 10 things halfway creates 10 places for work to jam. Before cutting, also ask the root question: does this process need custom software at all, or is an off-the-shelf SaaS enough?

Pre-RFQ checklist

Frequently asked questions

How can a business with no IT staff estimate this?

The 5-variable framework is designed to be answered in business language, no programming knowledge needed: you describe workflows, exceptions, and where data lives. Converting that into technical complexity is the vendor's job — your job is making sure every vendor receives the same description, detailed enough that nobody gets to "interpret it the cheapest way".

How much budget should go to contingency?

For internal systems involving legacy data migration or integration with running systems, a reasonable contingency in my experience is 15–25% of the build cost. More important than the number is the rule of use: contingency is spent only on late-discovered exceptions, never on features invented mid-project — new features must pass through their own prioritization round.

If you're holding several quotes that differ by multiples and don't know which to trust, or want to pressure-test whether your requirement description is tight enough, you can see how I approach web apps and internal systems, or share your case. I typically respond to cases that fit my expertise and current availability.