How to ask for software work, and what we need to price it

Key takeaways

We price most jobs from a few paragraphs. Five things need to be in there: what the software should do, whether it exists already, what state it is in, whether we can get access, and what done looks like. You do not need a specification, wireframes or technical language. The thing almost every request leaves out is what happens today, and that is the part that decides the work.

The hardest part of buying software is often the first message. You know what is wrong, or what you want, but you do not know how much of it to explain, in what language, or whether you are supposed to have written something formal first.

So here is the honest answer from the other side of it. We price most jobs from a few paragraphs. What matters is not length or polish, it is that a handful of specific things are in there. Get those in and you will usually have a real price back without a meeting.

What we actually need

Five things. Nothing here requires you to know anything technical.

1. What it is meant to do. Describe the outcome, not the solution. "We need to stop rekeying orders from email into the accounts system" is more useful than "we need an API integration", because the second one might be wrong and the first one never is.

2. Whether it exists already. This is the single biggest fork in the road. Building something new and changing something that exists are different jobs with different risks, and the answer changes the price more than almost anything else you could tell us.

3. If it exists, what state it is in. Who built it, when it was last worked on, whether it is live, whether anyone still understands it. "No idea, the person who built it left in 2019" is a perfectly good answer and we hear it constantly. It is information, not a confession.

4. What we would be able to see. Can you give us the code, a login, access to the hosting? You do not have to arrange it up front, we just need to know whether it is possible. Work we can look at is far cheaper to price than work we have to guess at.

5. What done looks like. One or two sentences. "The order lands in Xero without anyone touching it." "The report comes out on the first of the month with last month's figures." A finish line makes a fixed price possible; without one, everybody is guessing at scope.

That is it. If your message covers those five, we can almost always give you a number.

What we do not need

Worth saying plainly, because people spend weeks on things that make no difference to us.

  • A specification. If you have one we will read it. If you do not, do not write one for our benefit. Writing a spec is a job in itself, and it is one we do properly if it turns out you need it.
  • Wireframes or designs. Useful later. They do not change a price at this stage.
  • Technical language. Genuinely. If you use the wrong word for something we will work out what you meant, and if we cannot we will ask. Nobody has ever got a worse price for describing something in plain English.
  • A solution. You are allowed to have one, and we will consider it. But tell us the problem too, because sometimes the thing you have been quoted for elsewhere is not the cheapest way to get what you actually want.
  • Certainty. "I think it is Python but I am not sure" is fine. So is "I do not know how many users". We will tell you which unknowns actually matter.

The same job, asked two ways

Here is a real shape of request, in the form we usually receive it first:

We need a system to handle our bookings.

Nothing wrong with that as a sentence. It is unpriceable, because it could be two days or two years and there is no way to tell from here.

Now the same job with the five things in it:

We take bookings by phone and email and write them into a shared spreadsheet, about forty a week. Two of us do it and we keep double booking. We want customers to book online and see real availability. Nothing exists yet apart from the spreadsheet and our website, which is WordPress and which our marketing agency runs. Done would be: a customer books a slot on our site, we stop maintaining the spreadsheet, and both of us can see the same diary. We would want it before the new year.

That is not a specification and it took two minutes. It is enough to price.

The difference is not effort. It is that the second one says what exists, what should change, and how you would know it worked.

The bit people leave out, and what it costs

Almost every ask is missing the same thing: what happens now.

People describe the future clearly and the present not at all. But the present is what determines the work. Whether the data has to come out of something else, whether anyone is currently doing this by hand, whether there is a system already that has to keep running while the new one arrives.

If we have to ask, that is a round trip and a day or two lost. If we have to guess, we price the risk in, and you pay for our uncertainty. Neither is what you want.

So if you add one thing beyond the five, make it a sentence about how it works today, including the bits held together with a spreadsheet and somebody's memory. Especially those.

What happens after you send it

We read it and do one of three things.

Price it. Most of the time. You get a real number, what it covers, and how long it takes.

Ask one or two questions first. Usually about access, or about the finish line. We try hard to make it one round trip rather than a conversation.

Tell you it needs sizing properly. Some work genuinely cannot be priced from a paragraph, usually because nobody knows what is in the existing system. Then we quote for a short piece of assessment work, priced up front, that ends with a written answer and a real price for the rest. You are never in an open-ended arrangement where the cost is whatever it turns out to be.

What we will not do is put a number in front of you that we know will move later. A price that is not real is worse than no price, because you make decisions on it.

If you would rather just answer questions

Not everybody wants to write a paragraph, and there is no reason you should have to. The get a price form asks the same five things as a short series of questions and takes about a minute. You can attach a screenshot, a document, anything you already have, or nothing at all.

Either route reaches the same place. Some people think best in prose and some would rather be asked. The information is what matters, not the format it arrives in.

One last thing

If you are unsure whether something is worth asking about, ask. We would rather tell you a job is too small for us to be the right answer, or that the thing you want already exists off the shelf for forty pounds a month, than have you not ask because it felt like a waste of our time.

Neither of those answers costs you anything, and both are more useful than a quote.

Matt Houldsworth, Founder, Software Delivered

Matt Houldsworth

Founder, Software Delivered

Matt has spent thirty years building software that has to work, from systems handling a hundred million database transactions an hour to ecommerce platforms turning over millions of pounds a month. He founded Software Delivered to price development honestly and to rescue the projects other people walked away from.

Software that needs rescuing?

Tell us what is going wrong and we will price the fix up front. No hourly billing, no commitment.