The Cheapest Software Quote Is Often the Most Expensive. Here’s How to Tell in 10 Minutes

Most software proposals get read the way terms and conditions get read. Quickly, hopefully, and with a vague plan to deal with any problems later.

I understand why. You’ve spent weeks talking to agencies, and now there’s a 25-page PDF full of phrases like “scalable, modern architecture.” One quote says $42,000, another says $53,000, and you’d love to pick the one that felt right on the call and get started.

Here’s the catch. A proposal doesn’t describe what you’ll get. It describes what the agency has agreed to be responsible for, and anything outside that line quietly becomes your problem.

Full disclosure before we go on: I run Enlight Lab, which is a software agency, so I’m teaching you to scrutinize people like me. I’m fine with that. The founders I work with are happier when they’ve asked hard questions up front, and the agencies worth hiring don’t mind being asked.

You don’t need to be technical for any of this. You need a pen, a highlighter and ten minutes.

What ten minutes can and can’t do

Let me be straight about the promise. Ten minutes won’t give you a full review of a 25-page document. It gives you a first pass that answers one question: is this proposal clear enough to be worth a deeper look, or is it hiding more than it shows?

If the first one takes you twenty minutes, that’s fine. By the third, ten is realistic.

The whole method rests on one idea, so here it is up front: what’s missing from a proposal usually matters more than what’s in it. So don’t read it forwards, from the pitch. Read it backwards, from the risk.

Before you start

Print the proposal, or open it somewhere you can highlight. Use three colors:

• Red for exclusions: things that are not included.
• Yellow for assumptions: things the price only holds if they’re true.
• Blue for gaps: things you expected to find and didn’t.

Then set a timer. This is how I split the ten minutes:

Minutes	What you’re doing
0 to 2	Price, payment and what triggers it
2 to 4	Exclusions
4 to 6	Assumptions
6 to 7.5	Team, timeline and acceptance
7.5 to 9	Ownership and access
9 to 10	After launch, then your verdict

Skip the executive summary and the “About us” page. You can admire the design afterwards.

Minutes 0 to 2: Start at the price page

Go straight to the commercial section and look for four things.

What kind of price is it? Fixed price, time and materials, or a capped estimate? All three can be right in the right situation. A fixed price on poorly understood requirements tends to end in arguments about what was “in scope.” Time and materials on a vague brief can drift. A cap only helps if the proposal says what happens when you hit it.

What triggers each payment? Payments tied to milestones you can see and test are healthy. Payments tied to calendar dates mean you’re paying for time that has passed, whether or not anything useful exists yet.

What does a change cost? Look for a rate card or a described process. If change requests aren’t mentioned at all, mark it blue. Software projects change, and a proposal that pretends otherwise is either naive or setting a trap.

Is the number precise while the scope is fuzzy? A price to the nearest dollar attached to a loose description is a guess wearing a suit.

Write the headline number at the top of the page and put a question mark next to it. We’ll fix that question mark in a few minutes.

Minutes 2 to 4: Hunt for exclusions

If you only have time for one step, make it this one. Exclusions are where a cheap quote turns into an expensive project.

Some proposals have a tidy “Out of scope” section. Lovely, read it. Most don’t, so you have to find exclusions by noticing what never gets mentioned. Here’s the checklist I run through, and you should copy it into your notes:

• Discovery or requirements work. Included, charged separately, or assumed to be finished already?
• Design. Are screens and user flows part of the price, or are you supposed to bring them?
• Testing and QA. Does someone other than the developer verify the work?
• Deployment. Who sets up hosting, the release pipeline and the production environment?
• Hosting and third-party fees. Cloud costs, email services, payment processors, mapping or AI APIs. These are rarely in the quote and always in the bill.
• Data migration. If you already have customers or records, who moves them, and who cleans them first?
• Integrations. “Integrates with your CRM” can mean a weekend or a quarter. Is each integration named?
• Project management. Is someone coordinating the work, or is that quietly you?
• Training and documentation. Will your team know how to run the thing once it exists?
• Support after launch. We’ll get to this one properly in a moment.

Highlight every exclusion or omission in red and scribble a rough cost beside it. A guess like “maybe $5,000 to $10,000” is plenty. You’re not budgeting yet, just comparing honestly.

A quick, fictional example

Say Agency A quotes $42,000 and Agency B quotes $53,000. Agency A excludes deployment, formal QA and a handoff period. Agency B includes all three, but excludes cloud fees and ongoing support.

Now add some made-up numbers. Suppose deployment, QA and handoff would cost about $9,000 if you bought them separately. Cloud and third-party fees come to roughly $3,600 in the first year for either build, and first-year support is about $6,000 for either.

• Agency A: $42,000 + $9,000 + $3,600 + $6,000 = $60,600
• Agency B: $53,000 + $3,600 + $6,000 = $62,600

The $11,000 gap between the quotes has shrunk to $2,000, and that’s before you ask which team is actually better at the work. These figures are invented to show the mechanics, so your real numbers will differ. The lesson is to ask every agency to price the same list of items, because the headline number alone says little about what you’ll spend.

Want a second pair of eyes on your proposals? If you have two or three quotes and can’t tell which one to trust, I’m happy to look at them with you. Book a 30-minute conversation.

Minutes 4 to 6: Find the assumptions

Exclusions are what the agency won’t do. Assumptions are what the agency is relying on. When one of them turns out to be wrong, the price, the timeline or both can change, and usually not in your favor.

They tend to hide in phrases like these:

• “Assuming the client provides…”
• “Based on the current API documentation…”
• “Subject to final requirements…”
• “Client will be available for…”
• “Using the existing codebase as is…”
• “Third-party services will perform as expected…”

None of these is a red flag by itself. Honestly, I’d worry more about a proposal with none, because it means nobody has thought hard about the project yet.

For each assumption, ask whether it’s reasonable, testable and owned.

Reasonable: could it realistically be true? “The existing system has a documented API” is fine if you’ve seen the documentation, and a gamble if you haven’t.

Testable: can it be checked early? “We’ll validate the CRM integration in the first two weeks” turns a risk into a milestone, which is exactly what you want.

Owned: who pays if it turns out to be false? Sometimes it’s the agency and sometimes it’s you. Either can be fine, as long as it’s written down.

Highlight each assumption in yellow, then pick the three that would hurt most if they were wrong. Those become your questions for the next call.

One more thing to check here. If the proposal has a timeline, see which assumptions it leans on. A 12-week delivery date that quietly assumes you’ll give feedback within 24 hours, every single time, isn’t a 12-week date. It’s a wish.

Minutes 6 to 7.5: Team, timeline and acceptance

Three quick checks.

Who actually does the work? Look for named roles. You want to know who makes technical decisions, who writes the code, who tests it and who your day-to-day contact is. A phrase like “our experienced team” tells you nothing. The person who impressed you in the sales calls may not be near your project once it starts, so ask to meet the delivery lead before you sign.

Are the milestones things you can see? “Phase 2: Development, weeks 4 to 10” is a calendar entry. “Week 6: working onboarding flow, demonstrated on a test environment, checked against these five scenarios” is a milestone. Look for demos, working software and a clear description of what you’ll be shown.

How will you know something is done? Acceptance criteria are the most underrated part of any proposal. If it says nothing about how work is reviewed, how long you have to accept it or how defects are handled, then “done” gets decided by whoever argues longest.

Minutes 7.5 to 9: Ownership and access

Founders skip this section more than any other, and it’s the one they most often wish they hadn’t. You don’t need to be a lawyer to spot the questions, only to notice whether the proposal answers them.

Who owns the code? Look for any wording about intellectual property. “You own everything” on a sales call and “rights transfer on final payment” in a contract are two different promises. Neither is automatically wrong, but you should know which one you’re getting, and whether the agency brings its own reusable components that you’d only be licensing.

Who controls the accounts? Repositories, cloud hosting, domain names, app store listings, payment accounts, analytics. The healthy default is that these live in accounts your company controls from day one. If they sit in the agency’s accounts “for convenience,” ask when and how they transfer.

Who can access production and your data? A good proposal says something about credentials, access and how your data is handled. Silence doesn’t mean a bad agency, but it does mean you need to ask.

Who else touches the project? Subcontractors and third-party tools are normal. Undisclosed ones are a problem.

Mark every unanswered question in blue. None of these is a reason to walk away. They’re reasons to get the answer in writing before you sign, with a lawyer reading the contract. I’m a technologist, not a lawyer, and this is exactly where proper legal advice earns its fee.

Minutes 9 to 10: After launch, and your verdict

Find the section on what happens once the product is live. If there isn’t one, you’ve just learned something.

You’re hoping to see:

• A warranty or defect period. How long will the agency fix bugs at no extra charge?
• A support arrangement. What’s included, what are the response times, and what costs extra?
• A real handoff. Documentation, run instructions, deployment steps, a knowledge transfer session. “We’ll hand over the repository” gets you a folder, and a folder isn’t a handoff.
• An exit path. If you stop working together, how does another team pick it up without starting over?

Now go back to the headline number with the question mark. Add your red estimates, weigh the yellow assumptions, and you have a far more honest comparison figure.

Then give the proposal one of three verdicts:

1. Clear enough to proceed. Scope, price, ownership and handoff are all visible. Move on to contract review.
2. Good, but needs answers. The approach makes sense, but there are material gaps. Send your questions and judge the agency by how it responds.
3. Too vague to compare. Don’t guess. Ask for a revised proposal, or consider paying for a short discovery phase to remove the unknowns before committing to the full build.

Phrases that should make you pause

None of these automatically rules an agency out. Each one deserves a follow-up question.

• “Fixed price, fixed timeline” with no discovery. Ask what happens if an assumption turns out wrong.
• “Support available as needed.” Ask for response times and a price.
• “Ownership transfers on completion.” Ask what “completion” means, and what happens if the relationship ends early.
• A price far below the others. Ask what was left out. Often it’s a smaller project that happens to share the same name.

If the proposal involves AI

AI proposals need a few extra lines in your notes. The demos are more persuasive and the gaps are bigger. Check whether the proposal covers:

• How quality will be measured. Real test cases, not a handful of impressive examples.
• What happens when the system is wrong. Fallbacks, human review, and limits on what it can do alone.
• What it costs to run. Model usage, hosting and monitoring at your expected volume, not just at prototype scale.
• Where your data goes. Which providers see it, and what their retention terms are.
• Who watches it after launch. AI systems change behavior over time, and somebody has to own that.

If the proposal is mostly a demo and a promise, treat it as a prototype proposal and price it that way.

Send these questions back

You don’t need a long email. Pick the five or six gaps that matter most and ask them plainly. Something like this works:

Thanks for the proposal. Before we go further, could you help me with a few points?

1. Which items are excluded from the price, and can you estimate deployment, QA, hosting and handoff?
2. Which assumptions would change the price or timeline if they turned out to be wrong, and how early can we test them?
3. Who will be on the delivery team, and can I meet the technical lead?
4. What will we see at each milestone, and how is it accepted?
5. Which accounts and repositories will our company control from day one?
6. What support, warranty and handoff are included after launch?

Then watch how they answer, not only what they say. A good agency is glad you asked. They answer clearly, push back on a point or two, and probably mention something you hadn’t considered. A weaker one gets defensive, changes the subject or replies with a longer deck.

That reaction tells you more about the next six months than anything in the proposal.

The 10-minute cheat sheet

Screenshot this and keep it next to your proposals.

Minutes	Look for	Mark it
0 to 2	Price type, payment triggers, change costs	Question mark by the headline number
2 to 4	Discovery, design, QA, deployment, hosting, migration, integrations, support	Red
4 to 6	“Assuming,” “subject to,” “based on.” Pick the top three risks	Yellow
6 to 7.5	Named team, visible milestones, acceptance rules	Blue for gaps
7.5 to 9	Code ownership, account control, data access, subcontractors	Blue for gaps
9 to 10	Warranty, support, handoff, exit. Then choose a verdict	Proceed, ask, or revise

What this method won’t do

It won’t tell you whether the agency’s technical choices are right, catch every legal issue, or replace a call with a past client about how the team behaved when things went wrong.

What it does is turn a document written to be agreed with into one you can question. In ten minutes you’ll know what you’re being offered, what you’d pay on top and where the risk sits.

If you’d like help applying it to a real proposal, book a 30-minute conversation and bring the documents with you. I’ll tell you which questions I’d ask and where I think the real costs are hiding.

We also publish a guide to choosing a software or AI agency, with a 25-question scorecard you can use alongside this method. Download now