Why the same project comes back at three very different prices
You wrote one email, described the idea in two paragraphs and sent it to three development companies. The first came back at 18,000, the second at 55,000, and the third quoted 90,000 and wanted a meeting before it would stand behind that number. At this point most buyers reach the same conclusion, which is that somebody here is either overcharging or guessing, and the job now is to work out who. In practice it is usually neither, and the real explanation is far more useful to you than the suspicion is.
A quote is a promise, and nobody can promise what they cannot see, so when a brief leaves half the project unsaid every company has to imagine that half before it can put a number on the page. One of them imagined a tidy internal tool for six people, standing on its own, connected to nothing. Another imagined the same idea with customer logins, online payments, an approvals chain and three years of old records dragged across from spreadsheets. Both of them are pricing honestly, because both are pricing what they were shown plus what they were forced to invent, and the distance between those two imaginations is exactly the distance between the two numbers.
The pattern is consistent enough to put figures on it. When an idea arrives as one short paragraph, the highest quote is commonly three to five times the lowest, which is why the responses feel absurd when you line them up on a page. Once the brief answers the questions in this article, meaning who uses the system, what the rules are, what data already exists and what it all has to connect to, that spread usually closes to somewhere around 20 to 30 percent, and a 20 percent difference is an ordinary commercial choice rather than a mystery.
So the purpose of a brief is not to satisfy a supplier's paperwork. It is the cheapest tool you own for controlling your own budget, because every sentence you write removes a guess that somebody else was otherwise going to make on your behalf and charge you for. At Linkysoft we watch the same idea land on our desk in both forms, sometimes from the same client a month apart, and the difference in what we can responsibly commit to is dramatic. If you want a sense of what these briefs eventually turn into, our case studies are a reasonable place to calibrate before you start writing.
What a quote is actually pricing: days of work, not features
Underneath every proposal, however elegantly it is dressed up, sits one piece of arithmetic: the price is the number of working days the job will take multiplied by a daily rate, and everything else in the document is detail hanging off that. Once you know this you can read any quote backwards, and reading a quote backwards is where all the useful questions come from.
Try it with a real number. Suppose a company quotes you 60,000 in your own currency, and their blended rate, meaning the average across the senior and junior people who will touch the work, is 500 a day. That is 120 developer days, which is roughly six months for one person working alone, or eight weeks at the very least for a team of three, and realistically nine or ten once you count the testing and review time that a team cannot skip. So if the proposal in your hand promises all of that in three weeks, then either the days are wrong or the rate is, and it is worth finding out which before you sign anything.
This hands you the single most revealing question a buyer can ask: how many days is this, and how are those days split between the parts of the work. A company that has genuinely estimated will answer in about a minute, because the split is sitting in the spreadsheet the number came out of. A company that cannot answer has not estimated your project at all, it has priced its impression of your project, and impressions move once the work starts.
The split itself surprises most first time buyers, because only about half of those days go into building the screens you will ever see. On a typical custom build we see something close to 50 percent on building the features, 18 percent on testing and fixing whatever the testing finds, 12 percent on setting up servers, environments and the machinery that carries the work safely from a developer's laptop to your staff, 10 percent on coordination and meetings, and another 10 percent on revisions after you look at the first version and change your mind about something, which you will do and should do. None of that is padding. It is the difference between a demo and a system your business can lean on, and it is worth understanding before you put two custom system quotes side by side and compare only the totals.
Start with the outcome you want, not a list of features
The opening paragraph of your brief should not describe software at all. It should say what your business will be able to do once this exists that it cannot do today, and how you personally will know that it worked. Getting a quotation back to a customer takes two days today and ought to take the same morning, and month end invoicing eats three days of one person's week when it should take an afternoon. That is the register to write in.
This matters commercially rather than editorially, because a supplier who understands the outcome can often propose a cheaper route to it. We have more than once replaced a requested module with a two day change to an existing process, and the client simply kept the difference. That conversation is only available when the destination is known, since a supplier shown nothing but the feature you guessed at has little choice but to price the feature you guessed at.
The counter example is the brief that opens with a request for a dashboard with graphs on it. Nobody reading that can tell what decision the graphs are meant to support, how often anyone will look at them or which numbers actually matter, so it gets priced widely and defensively, which is another way of saying expensively. A dashboard that answers one question well is often three days of work, whereas a dashboard that must answer every question anybody might one day think of is three weeks.
Here is the shape worth imitating almost word for word. "We run a dental clinic with four chairs and about 60 patients a day. Reception confirms appointments by phone and writes them in a paper diary, so we get double bookings most weeks and roughly one patient in six does not turn up. We want patients to book and confirm online and reception to work from one shared schedule, so that missed appointments drop below one in ten and mornings are not spent on the telephone." Four sentences, a measurable outcome, and any competent supplier can begin estimating from it immediately.
Describe how the work happens today, step by step
Next, write down how the job gets done at the moment as a numbered list, starting from the moment a customer first makes contact and ending when the money has arrived and the file is closed. Name who does each step and what they use to do it, whether that is a system, a spreadsheet, a printed form or a phone call. Ten to twenty lines is usually plenty.
We would argue this is the most valuable page in the entire brief, and it is also the one buyers skip most often because it feels like writing down the obvious. It is not obvious to us, and more importantly it is where the exceptions live: the paper form that comes out when the internet is down, the group chat where the drivers actually get their instructions, the one spreadsheet that only Samira understands and that quietly runs your pricing. Every one of those is real work with a real cost attached, and leaving it out of the brief does not make it disappear, it just delays the discovery until month two, when discovering it is expensive and everybody feels ambushed.
While you are there, put the volumes next to the steps. How many orders, patients, invoices or jobs pass through each stage on an ordinary day, and how many on your busiest day of the year. This is not a small detail, because ten a day and ten thousand a day are genuinely different pieces of engineering even when the screens look identical, and at the higher number the searching, the reporting and the way records are stored all have to be built differently from the first week. Retrofitting that later costs several times what building it properly would have cost at the start.
If you are not technical, please do not feel obliged to draw a diagram. Plain sentences in the order things actually happen are more useful to us than any flowchart, and a photo taken on your phone of the paper form your staff fill in tells us more in ten seconds than a page of careful description. We would far rather have the messy truth than a tidy summary of it.
Count your screens and the kinds of people who use them
This is the section where you can start pricing your own project. Make a list of every screen a person will look at, one line each, and mark next to it whether that screen only shows information or whether somebody can add, edit and approve something there. That single distinction accounts for most of the difference in cost, because reading is cheap and changing is not.
The rates we work with in practice are easy enough to apply yourself.
- A screen with a list, an add and edit form and a few rules behind it is typically 2 to 5 developer days, including its testing.
- A report screen with filters and an export to a spreadsheet is 3 to 5 days.
- A plain information page with no logic in it comes in under a day.
A small management system usually lands somewhere between 12 and 25 screens once the list is written honestly, so multiply it out and you have a range you can work with.
Do that multiplication and you will land within roughly 30 percent of a serious estimate before you have spoken to a single supplier, which happens to be exactly the precision you need in order to decide whether to start at all. If your own arithmetic says 100 developer days and your budget will stretch to 40 of them, you have learned something important on a Tuesday evening for free, and you can go back and cut the screen list rather than spending six weeks learning the same thing through quotations.
Count your user roles in the same sitting, because a role is a kind of person with genuinely different permissions: a receptionist who books but cannot refund, a manager who approves, an accountant who sees the money but not the medical notes. Each additional role adds roughly 8 to 15 percent to the build, which on that 120 day project is another 10 to 18 days, because every screen has to be built once and then checked again from the second role's point of view, and then a third time from the third. Listing four roles where two would do is a real cost, and an entirely avoidable one.
Which brings us to the advice we give most often at Linkysoft and that nobody expects to hear from a development company: the smaller option is very often the right one. Three tidy screens your staff open every morning are worth more than fifteen that sit there unused, and the other twelve can always be added next year out of the money the first three have earned you by then.
Integrations and data migration: the short sentences with the long price tags
An integration simply means making your new system talk automatically to another system, so that information moves across without a human retyping it: your accounting package, your payment provider, your courier, a government portal, the machine in the workshop. It is one line in a brief, and it is regularly the largest single item in the quote that comes back.
There are really two price bands here and they sit a long way apart. Connecting to a modern service that publishes proper documentation and offers a test environment, meaning a practice version we can safely experiment against, is typically 3 to 8 developer days. Connecting to an older system, a bank, or a government portal with no documentation, no test environment and a support line that replies in ten working days runs 10 to 30 days, and in our experience this is the single most common cause of a project overrunning. Not the design, not the features, but the connection that nobody could test.
So write far more than the word itself. Name the system and its version, say who owns the login, say whether a test environment exists, and name the person at your end who can get the other vendor's technical contact on the phone within a week. That last detail is worth more than it sounds, because a great deal of the delay on integration work is not writing code at all, it is waiting for somebody else's IT department to grant access.
Old data deserves the same honesty. Moving 5,000 to 50,000 records out of spreadsheets into a clean structure is usually 4 to 10 days, and that assumes the spreadsheets are reasonably consistent with each other. Duplicates, four files that disagree, or free text typed where a date should be can double it, so a safe planning figure is 5 to 10 percent of the build cost for migration alone. Say in the brief how many years of history genuinely need to come across, because the honest answer is often two rather than ten, and the rest can sit in a read only archive for a fraction of the price.
Rules, approvals and the awkward exceptions that break estimates
Your staff carry dozens of rules in their heads that have never been written down anywhere, and software cannot infer a single one of them. Someone in your office knows who is allowed to give a discount and how large it may be, the bookkeeper knows what happens when a customer pays half now and half on delivery, and between them they can tell you which manager approves a refund above a certain amount and who stands in while that manager is on holiday. Every one of those has to be settled by a person, and the only real question is whether it gets settled now and cheaply in a document, or later and expensively in the middle of a build.
Exceptions are where estimates go to die. The ordinary case, an order placed and paid and delivered, is quick to build. The five odd cases arranged around it, the cancellation after dispatch, the partial refund on a discounted item, the record entered twice by two people, frequently cost more together than the ordinary case did on its own. Listing them does not create that cost, it moves it out of the category of surprise and into a visible line on a quote, which is precisely where you want it to be.
Most of this can be covered in ten minutes by answering six questions about each main process. What happens when something is cancelled, when it is returned, when it is paid late, when it is paid only partly, when the same thing is entered twice, and when the person who started it has since left the company. Write one sentence for each and you will have removed more risk from your budget than any other page you could possibly produce.
The money tells the same story. Briefs shorter than a page typically generate change requests worth 25 to 40 percent of the original quote within the first three months, and those changes arrive at the moment when you have the least bargaining room left and the work is already half built. A brief that covers the outcome, the current process, the screens, the roles, the rules, the data and the integrations usually keeps changes down to 5 to 15 percent, which is normal and healthy, since no plan survives contact with real users completely intact and nobody honest will pretend otherwise.
Put numbers on scale, speed and how much downtime you can survive
Four numbers quietly decide a surprising amount of the engineering, and they take about a minute to supply.
- How many people will be using the system at the same time during your busiest hour, rather than in total.
- How many records exist today, and roughly how many there will be in three years.
- How large the files are, because a system storing scanned contracts and one storing medical images are different animals.
- Whether it has to work outside the office, on a phone, in a van, or with no internet connection at all.
Availability is the one thing people request without knowing what it costs. In plain terms, 99.5 percent uptime means the system may be offline for about 3.6 hours in a month and still keep its promise, while 99.9 percent allows about 43 minutes. The monitoring, the backups and the spare capacity standing behind that second figure typically add 15 to 25 percent to hosting and setup, so ask for it when an hour offline genuinely costs you real money, and resist asking for it out of instinct.
Say plainly in the brief whether the system will hold anything sensitive, such as health records, identity documents or card payments. This is not a formality, because it changes how the system is tested, where it is allowed to be hosted and who may see what, from the very first week rather than after somebody reviews it three months in and asks for changes that are painful by then. Where any of that applies, the security requirements belong in the brief itself and not in an afterthought.
Finally, say who is going to keep the system running after launch, because somebody has to. Hosting, updates, monitoring and support typically come to 15 to 20 percent of the build cost per year, so a 60,000 build carries roughly 9,000 to 12,000 a year behind it. A quote that leaves all that out has not made your project cheaper, it has only made the document shorter, and you will meet the difference in month four.
Say your budget and your deadline out loud
Most buyers hide the number because they believe that naming it guarantees the supplier will spend every last unit of it. The fear is understandable, and the outcome is the opposite of what they expect, because hiding it costs them more. A company that cannot see the ceiling either guesses high to protect itself, or designs something excellent that you cannot afford, and then you both spend a fortnight unwinding a proposal that was never going to happen.
Treat the number as a design constraint instead of a secret. Telling us the range is between 30,000 and 45,000 lets us come back and say what genuinely fits inside it, what should move to a second phase, and what is not achievable at that level at all, so you can decide with your eyes open. That is the most useful conversation in the whole buying process, and it cannot take place while the most important constraint is being withheld. If you are unsure how to set the range in the first place, start from your own screen arithmetic further up and check it against what the system has to earn or save you.
Dates work the same way, so do not just give a date, give the reason sitting behind it: the season, the lease that ends, the audit, the licence that expires, the trade show you have already paid for. A real reason can be planned around, phased, or partly met with a smaller first release, whereas an invented deadline simply adds a safety margin to your price, because the supplier has to buy that risk from somewhere.
Set your expectation for turnaround too. With a complete brief, a serious company can come back with an itemised quote in 3 to 5 working days. With a vague one you are buying either two to three weeks of back and forth questions by email or a padded figure with the uncertainty quietly priced into it, which means the afternoon you saved by not writing the brief gets spent anyway, with interest. Naming the budget in writing at the start is what buys you the fast, itemised answer.
What to leave out of the brief
Leave out the technology. Unless something in your business genuinely requires a particular database or a particular framework, meaning the ready made set of building blocks a team writes its own code on top of, naming one because you read about it somewhere narrows the field of suppliers who can bid, rules out people who would have built it faster in the tools they know best, and occasionally doubles the price for a benefit you will never see. Describe the problem and let the proposals argue about the tools.
Leave out finished designs at the quoting stage. Pixel level layouts take you weeks and often get rebuilt anyway once the process underneath is properly understood, whereas a rough sketch on paper or a screenshot of a website you admire communicates the same intent in five minutes flat.
Leave out comparisons with enormous products, because asking for something like the big marketplace app describes years of work by hundreds of people and says nothing at all about your business, your volumes or your rules. It reads as ambition rather than as a requirement, and it cannot be priced.
Two popular additions deserve some candour. A companion mobile app usually adds 40 to 70 percent on top of an equivalent web build, so for most first year projects a well built responsive website that behaves properly on a phone is the more sensible spend, with the app following once you know what people actually do all day. And asking for artificial intelligence features before your data is clean, complete and gathered in one place is money spent about a year too early, because those features learn from the data you already hold, and messy data teaches them the wrong lessons.
Then stop writing. A brief that does its job is 3 to 6 pages, and past about fifteen pages they begin repeating themselves, which buries the three paragraphs that actually decide the price somewhere in the middle where nobody reads them carefully.
A brief you can write in ninety minutes
Here is the whole thing as a skeleton you can copy into a blank document tonight and fill in section by section.
- The outcome in one paragraph: what the business will be able to do that it cannot do today, and how you will know it worked.
- The current process as numbered steps, naming who does each one, what they use, and the daily and peak volumes.
- The screen list, each one marked as either view only or add, edit and approve.
- The roles list, with a line each on what that person may and may not do.
- The integrations, each with its system name, its version, who owns the login and whether a test environment exists.
- The existing data: where it lives now, roughly how many records there are, and how many years of history really have to move.
- The rules and exceptions: discounts, approvals, cancellations, partial payments, duplicates, and people who have left.
- The budget range, the date, and the reason behind the date.
Add three practical lines at the end that suppliers rarely receive and always need: who at your company answers questions during the quoting period, how quickly they can answer, and what you will use to decide between the offers that come back. That last line keeps everybody honest, including you.
Realistically this is about ninety minutes for a first draft, plus another hour after somebody who does the work every day has read it and told you what you got wrong, which they will. Where the project is large or genuinely unclear, a paid scoping phase is worth considering, because it costs roughly 5 to 10 percent of the expected build, runs over one to three weeks, and typically turns an estimate accurate to plus or minus 50 percent into one accurate to plus or minus 15 percent. On a large project that is a cheap way to buy certainty, and the planning it produces belongs to you whoever eventually builds the system.
How to read the quotes that come back
When the proposals land, four checks separate the serious ones from the hopeful ones.
- Does it show days, or only a total?
- Does it name what is excluded, given that a quote with no exclusions has not really been thought about?
- Does it say what happens when something takes longer than expected, since something always will?
- Does it price the first year of running the system as well as the work of building it?
Then there is the cheapest number, which deserves friendlier treatment than it usually gets. A quote sitting well below the others is rarely a bargain and rarely a swindle, because it is almost always pricing a smaller project: that supplier read your brief and imagined less than the others did. So write back and ask which of your screens, which roles and which integrations are included in that figure, and in our experience the gap explains itself in one email, after which you can either compare the two properly or ask the low bidder to quote again against the full list.
Give yourself a fair comparison as well, by sending every company the same brief on the same day with the same deadline to reply. It sounds obvious, and yet the most common reason quotes turn out to be impossible to compare is that each supplier received a slightly different and slightly improved version of the story as the buyer's own thinking developed over the fortnight.
If you have a brief in progress, even a rough one, send it to Linkysoft and we will tell you what is missing before you send it to anybody else. It costs you nothing, and it is a great deal cheaper for everyone than finding the gaps in month two. You can start that on our contact page, and there is more guidance of this kind waiting on the blog.
