Skip to content
How to Scope a Custom Software Project Before You Hire a Developer: A Guide for Mid-Market Owners and Operators

How to Scope a Custom Software Project Before You Hire a Developer: A Guide for Mid-Market Owners and Operators

2026-11-03 · By the Yellow Coop Team

The takeaway

Most custom software projects don’t go sideways because the developers can’t code. They go sideways because nobody wrote down what “done” means, the first release was too big, and the contract paid for hours instead of working software. Fix those three things before you sign, and you take most of the risk off the table.

That’s not pessimism talking. It’s what the biggest studies of IT projects keep finding.

What the research says about IT project risk

Two large studies are worth knowing before you hire anyone.

  • The averages are bad. McKinsey and the University of Oxford looked at more than 5,400 IT projects. Large ones (initial budgets over $15 million) ran 45% over budget and 7% over time on average, and delivered 56% less value than predicted. Every extra year of planned duration added about 15% to cost overruns (McKinsey, Oct. 1, 2012).
  • The tail is worse. Bent Flyvbjerg and Alexander Budzier of Oxford studied 1,471 IT projects. The average cost overrun was 27%, but one in six was a “black swan,” with an average cost overrun of 200% and a schedule overrun of almost 70% (Harvard Business Review, Sept. 2011; author preprint).

Your project is probably smaller than $15 million, so don’t treat those numbers as a forecast. Treat them as a warning about shape: the average overrun is survivable, the outlier is what hurts. Flyvbjerg and Budzier’s own example is Levi Strauss, whose SAP project had a proposed budget under $5 million and ended with a $192.5 million charge against earnings in the second quarter of 2008 (preprint).

Step 1: Write the one-page outcome brief

Before you talk to a single agency, write one page that answers:

  • What business result changes? “Quotes go out in one day instead of four” beats “a new quoting portal.”
  • Who uses it, and how many? Name the roles, not just “staff.”
  • What does it replace? The spreadsheet, the old system, the manual handoff.
  • What must it connect to? Accounting, CRM, ERP, payment tools. Integrations are where scope quietly doubles.
  • What is out of scope? Write this list on purpose. It’s the cheapest risk control you’ll ever buy.

If you can’t fill this page in, you’re not ready to hire a builder. You might be ready to decide whether to build at all, since an off-the-shelf tool may do 80% of the job.

Step 2: Shrink the first release

The research points the same way twice. McKinsey found longer projects overran more, and listed short delivery cycles among the practices that help (McKinsey, 2012). Flyvbjerg and Budzier say smart managers “break big projects down into ones of limited size, complexity, and duration” (preprint).

In practice, that means a first release that one team can actually use for real work, followed by a decision point. Ask: what’s the smallest version that lets one department stop using the old way? Build that, use it, then fund the next slice.

Step 3: Run the stress test before you sign

Flyvbjerg and Budzier suggest a blunt readiness check: could the company absorb the hit if its biggest technology project went 400% over budget and delivered only 25% to 50% of the projected benefits (preprint)?

You don’t need to like the answer. You need to know it. If the honest answer is “that would sink us,” shrink the scope, phase the spend, or keep a fallback (the old system stays on until the new one proves itself).

They also recommend “reference class forecasting,” which just means estimating from how similar projects actually turned out, not from how this one is supposed to go. Ask every bidder for two or three comparable projects, what they were quoted at, and what they finally cost.

Step 4: Write a contract that pays for working software

A few terms carry most of the weight:

  • Pay against delivered, accepted releases, not only monthly hours.
  • Define acceptance. Who tests it, against what list, and how long they have to say yes or no.
  • Own the code and the accounts. Your company should hold the code repository, cloud accounts, domain, and admin logins from day one.
  • Require a change process. New requests get a written estimate before work starts, so scope creep shows up as a decision, not a surprise invoice.
  • Ask for a handoff package: documentation, deployment steps, and credentials, so another team could pick it up.

Step 5: Put one person in charge of the business side

McKinsey’s surveys of IT executives tied about half of cost overruns to two gaps: weak management of strategy and stakeholders, and not securing the internal and external talent to master the technology and project content (McKinsey, 2012). For an owner or operator, that means one named internal owner who can say yes, no, and “not this release,” plus someone technical enough to read the vendor’s work and tell you if it’s on track.

The short version

Write the outcome brief. Shrink the first release. Stress-test the downside. Pay for working software you own. Name one owner.

If an outsourced build is already running late and nobody can say why, or a big proposal is sitting on your desk, that’s the kind of call Yellow Coop’s CTO work covers: build vs buy decisions with cost and risk side by side, and outsourced partner oversight. If you just want a second opinion on a proposal, our Virtual level includes exactly that. Start with a conversation.

Sources