How to check a software quote before you sign it
A quote you can check names what is being built, what is excluded, who owns the result, what a change costs and what happens if it overruns. A quote that is a price and a paragraph commits you to whatever the supplier later says it meant. Read it for those five things before you read the number, because the number is the only part that cannot hurt you after you sign.
A price is not a quote
Most software disputes are not about money. They are about the sentence "I assumed that was included", said in month four by someone who was never unreasonable and never told otherwise.
The quote is where that gets settled, and it gets settled in your favour only if the document is specific. A single line reading "Bespoke booking platform, £38,000" is not a quote. It is a price attached to a word, and the word means whatever the supplier decides it meant once the work is under way and your deposit has gone.
None of what follows requires you to be technical. It requires you to read a commercial document the way you would read a building contract, and to notice what is missing rather than what is there.
The eight things a quote has to contain
Go through the document and tick these off. Anything you cannot find is a question, and how it gets answered tells you more than the answer does.
- A list of what is being built, at the level of screens or features rather than phases. "User management" is a heading. "Staff can be invited by email, given one of three permission levels and deactivated" is a scope line.
- An explicit exclusions list. The absence of one is the single most common cause of a dispute. A supplier who has written down what is not included has thought about the job.
- Who does what on your side. Content, photography, approvals, test data, access to your existing systems. Projects slip on the client's tasks more often than the developer's.
- The integrations, named. Not "connects to your accounts package" but "Xero, via their API, syncing invoices one way". Integrations are where estimates go wrong, because the other system's limits are not negotiable.
- What happens to the data you already have. Migration is a project of its own and is quietly left out of perhaps half the quotes we read.
- Testing, and who signs it off. Whether there is a period of user acceptance testing, how long you get, and what counts as a defect rather than a change.
- What happens after launch. How long defects are fixed free, what support costs, what hosting costs, and what the annual running total is.
- The payment schedule tied to deliverables, not to dates. Paying on dates means you can pay in full for work that has not arrived.
Fixed price, day rate, or capped
Each model moves the risk somewhere different. None of them is dishonest, and a supplier who explains which one they are offering and why is telling you something useful about how they work.
| Model | Who carries the risk | Suits | Watch for |
|---|---|---|---|
| Fixed price | The supplier | A scope that is genuinely settled | Padding, and a hard line on every change |
| Day rate | You | Work that will genuinely be discovered as it goes | No ceiling, and no incentive to be quick |
| Capped time and materials | Shared | Most SME projects | What happens at the cap, in writing |
Is the number reasonable?
Rates published across the UK market in 2026 put a mid-level developer at roughly £400 to £550 a day and a senior at £600 to £800, with London agency teams quoted around £600 to £900. Agencies commonly add 40% to 60% over the cost of the individual to cover management, testing and everything that is not typing.
That gives you a sanity check rather than a valuation. Divide the quote by a plausible blended day rate and see how many days it implies, then ask yourself whether the thing being described could be built in that time. A £38,000 quote at £650 a day is about 58 days, which is roughly three months of one person. If the document describes a platform with a customer app, a staff portal, payments and reporting, three months of one person is not a bargain. It is a warning.
Cheap quotes fail more often than expensive ones, and they fail later, when the money is gone. The useful question is not whether a price is low but whether the days behind it are real.
The clauses that decide who owns the result
This is the part that costs people years, and it is usually three sentences near the end that nobody reads.
- Intellectual property transfers on final payment. If the contract is silent, in the UK the developer generally keeps copyright in what they wrote. Silence is not neutral here. It favours them.
- You get the source code, in a repository you control. Ask where it will live and whose account owns it. "We keep it in our GitLab" means you have bought the use of something, not the thing.
- Accounts are in your name. Domain, hosting, payment gateway, third-party services. Every one registered to your company, with you as the billing owner, from day one rather than at handover.
- An exit clause. What you receive if you part company: code, database export, documentation, and a defined handover period. Agree it while everyone is cheerful.
We have written separately about the five things that make up a website and who tends to end up owning each of them. The same logic applies to a bespoke system, with higher stakes, because a system you cannot take elsewhere is a system whose price is set by whoever holds it.
What a thin quote looks like
None of these is proof of anything on its own. Two or three together is a reason to slow down.
- A total with no breakdown of what makes it up.
- No exclusions, no assumptions and no dependencies listed.
- A timeline in weeks with nothing to deliver at the end of each one.
- Hosting, support and licence costs after launch left unmentioned.
- A deposit above about a third before anything has been produced.
- No named people, or a team that will be "allocated on commencement".
- A change process described as "we will be flexible", which means it is undefined and will be defined later by the party holding your code.
- Pressure to sign this week for a discount. Real capacity constraints exist, but they are explained rather than counted down.
What a fair change process looks like
Your requirements will change. Everyone's do, and a supplier pretending otherwise is either inexperienced or planning to charge for the surprise. What matters is that the mechanism is agreed before you need it.
A fair one is short. A change is written down, estimated in hours against the agreed rate, and approved by you in writing before any work starts on it. Small adjustments during a review are absorbed rather than invoiced. There is a threshold, stated in the contract, below which nobody raises paperwork.
The detail that tells you most is what happens when the change is the supplier's misunderstanding rather than your new idea. A quote that treats every deviation as chargeable, including their own mistakes, has moved all of the risk to you while charging you as though they carried it.
Getting a second pair of eyes
Nobody thinks twice about a survey before buying a building or an accountant before signing a lease. A £40,000 software commitment gets signed on a PDF and a good feeling about the person who sent it, largely because it is not obvious who you would even ask.
If you want an independent read on a quote or a specification before you commit, send it over. We read these regularly, we are happy to sign an NDA first, and it is a short conversation rather than a sales process. Sometimes the useful answer is that the quote is fair and you should sign it, which is worth knowing too.
Email hello@flitzen.co.uk or call +44 (0) 7587 557 546. Attach the quote and the spec if you have one, and say what is making you hesitate.
Common questions
A feature-level scope, an explicit exclusions list, your own responsibilities, named integrations, what happens to existing data, a testing and sign-off period, post-launch support and running costs, and a payment schedule tied to deliverables rather than to dates. A quote missing the exclusions list is the most common source of later disputes.
Generally the developer. Under UK law copyright in commissioned software usually stays with whoever wrote it unless the contract assigns it, so silence works against the client. Look for a clause transferring intellectual property on final payment, and for source code held in a repository your company owns.
Only when the scope is genuinely settled, because a fixed price forces the supplier to price the risk and to defend the boundary afterwards. Day rates suit work that will genuinely be discovered as it goes but give you no ceiling. Capped time and materials suits most SME projects, provided the contract says what happens when the cap is reached.
Divide the total by a plausible blended day rate, around £600 to £900 for a London agency team in 2026, and see how many days it implies. Then ask whether what is described could be built in that time. Underpriced projects tend to fail later than overpriced ones, once the budget has gone and the work has not.
Yes. Send it to hello@flitzen.co.uk with the specification if you have one. We will read it under an NDA if you prefer and tell you what we think, including when the answer is that it looks fair and you should go ahead.
Where to go next
Want a straight answer about your own setup?
Tell us what you are running now and what is going wrong with it. We will say what we would do, including when the answer is that you do not need us.