How to read a developer's quote: 9 red flags before you sign

A quote for a website or app is hard to judge if you've never bought one. Two quotes for the "same" project can be five times apart, and both can look reasonable. Most bad projects weren't bad quotes so much as incomplete ones: what wasn't written down became an argument later.

Here are nine things to check before you sign.

1. The scope is one paragraph

"Build a booking app like Calendly" is an idea, not a scope. A usable quote lists the screens or features, who uses each one (customer, staff, admin), and what's not included. If there's no "not included" list, everything you assumed is a future disagreement.

2. Nothing about the admin side

Customers see the front. Someone on your team needs to manage bookings, refunds, users and content. Admin screens are often a third of the work, and often missing from cheap quotes.

3. No hosting, email or launch

Who sets up the server, the domain, and the emails the app sends (password resets, receipts)? Who pays for them? A quote that ends at "development complete" leaves you with an app that isn't live.

4. No mention of testing

Ask how the developer will check that it works and keeps working: automated tests for the key flows (sign-up, payment, booking), and a staging copy you can try before launch.

5. Silence on who owns the code and accounts

The quote or contract should say that the code is yours once paid, that accounts (hosting, repository, app stores, payments) are created in your name, and that credentials and documentation are handed over at the end. If it says nothing, ask. This one line saves a lot of pain later. (See Do you actually own your website?)

6. Most of the money upfront

Some upfront payment is normal. Most of the money before anything is delivered, with no milestones, leaves you with no leverage if things slow down. Look for payments tied to working, delivered pieces.

7. No process for changes

You will change your mind. That's fine, but the quote should say how changes are handled: written, priced and approved before work, not added to a surprise final invoice.

8. A fixed price on a big unknown

A fixed price for a brand-new, well-defined app is reasonable. A fixed price to "fix everything" in someone else's existing code, before anyone has read that code, is a guess. Honest developers ask to assess first or give a range.

9. Nothing after launch

What happens when a bug appears the week after launch? Look for a short fix window for defects, and a clear price for ongoing support if you want it.

How to compare quotes fairly

Make one list of everything you need: features, admin, hosting, email, testing, launch, handover, support. Then mark each quote against it: included, not included, unclear. Now you're comparing the same thing, and "unclear" becomes your list of questions.

Good questions to send:

• What exactly is not included?
• Who owns the code and the accounts, and when?
• How are changes priced and approved?
• What's the payment schedule, and what's delivered at each step?
• How long do you fix defects for after launch, and what does support cost after that?

Want a second pair of eyes?

My Second Opinion on a Quote is a written review of a proposal before you sign: what's missing, what's risky, whether the price and timeline are realistic, and the questions to ask. From $130, within three working days. I'll say at the start whether I could take the project on, and the review is written the same way either way.