Why you should disclose your budget to your software developer

Choosing a developer? You’ll learn far more, and build a much stronger partnership, if you reveal your budget up front. 


Imagine you run a distribution company. At the moment, you manage your consignments with spreadsheets. You want an online system that allows your drivers to specify the times when they’re available, team members to manage routing and scheduling, and clients to log in and track their deliveries.

You put together a list of the features you want, send it to five developers, and ask them to provide a price. And you duly receive five prices, probably accompanied by a plan setting out what each provider will do for the price they’re quoting.

Now you know how much you could pay five suppliers to work towards your feature set – but not much more. At this early stage, there are far too many unknowns for you to compare their plans objectively, so you’re comparing apples, oranges, and unicorns. With price tags attached.

More seriously, you don’t really know whether the developers’ efforts will genuinely help your business, or how the relationship between you would actually work from day to day. You’re no nearer choosing the one who would be best to work with for the next few months, or even years.

What’s more, by approaching the market this way, you’re setting up a perverse incentive: Although you want developers to reveal information, you’re actually giving them a very good reason to hide it. They can see you’re focused on price, so they’re more likely to lowball early on to gain you as a client. But they’ll claw back that discount later by cutting corners on functionality, quality, testing or security.

Finally, your relationship has started off on the wrong foot, because you’ve tried to gain advantage over suppliers, playing them off against each other while keeping your own cards close to your chest.

This secretive, adversarial negotiation style undermines trust before it’s had a chance to grow. But more to the point, it’s simply not effective in terms of the outcome it leads to. So why not go for something more open and honest?


Software is not a rug

Focusing on money at the start is completely understandable. When you’re thinking about buying something, you naturally want to know how much it will cost. And unless you’re haggling in a Moroccan bazaar, the price is set by the seller. So it’s only natural to ask them, and expect that they can answer.

Cost also gives you something solid to hold on to. It promises an objective, quantitative benchmark that you can use to compare suppliers on a simple sliding scale, and a bulletproof rationale for selecting one over another. You went to the market and you got the best deal. End of story.

The problem is, buying enterprise software is not like buying a rug in a market. It may look like you’re buying a ‘thing’ – the finished application. But that ‘thing’ doesn’t exist until you buy it; it’s only brought into being by the time, skills and ideas of software developers. You’re buying a process, not a product.

You’re also selecting a partner who will work deep inside your business, and gain access to your most valuable data. It makes sense to get to know them before you let them through the door.

More art, less science


Software is a problem to be solved, not just a thing to be created. Any specs you agree in the early stages are subject to change, because insights always emerge during development.

When you say, ‘I need an online system for managing deliveries,’ the project sounds clear and simple, with firm boundaries. But in reality, writing software is a fuzzy, messy process that’s closer to art than science.

All software reflects a workflow, and there are many trade-offs to be made in terms of how and where to automate it. When we’re developing software, many questions, insights, and queries come up every single day, and they all have to be prioritized against each other. Many only come to light once other questions have been resolved, making them impossible to predict at the outset.

When you hire a developer, you’re not renting a robot to build a component according to a blueprint. You’re asking a deep thinker to apply their creativity and insight to your individual problem, and give you the best solution they can.

For all these reasons, it’s fiendishly difficult to put a price on software up front. However, it may be possible to put a value on it. Let me explain how…

A solution that makes sense

With so many decisions, there are many possible solutions. But all you need is the one solution that makes business sense for you. You could measure that in terms of saving time, saving money, reducing errors or making life better for your team (which I personally think more firms should aim for).

Meanwhile, as developers trying to give you a meaningful proposal, we’re looking for constraints that will narrow down the options. What are the immovable pillars around which we can build your software? Where are the lines we shouldn’t cross?

Time can be a constraint – for example, if you need to launch on a certain day. Scope can be a constraint, dictating which features are in or out. And cost can be a very useful constraint, because it determines which features make business sense for you, and which are too expensive. Cost also imposes a time limit in terms of billable hours available, which in turn affects decisions on scope. Once cost is set, many other things fall into place, and the field of options narrows from almost infinite to merely very wide.

Softly, softly

So sharing budget information is helpful. But what’s the best way to do it?

You could come right out with your budget and ask, ‘What can we get for this?’ But you’d obviously worry that you wouldn’t get the best deal. If you say you have a budget of $50k, but your software only costs $10k in reality, you risk a supplier taking your $50k, delivering a $10k solution, and pocketing your $40k.

To sidestep this ‘all or nothing’ dilemma, we take a ‘softly softly’ approach. Both sides set out their positions, throw in some numbers, and gradually converge on an agreement.

First, we’ll ask you what you’re using now and what you’d like to add or change. We might talk about what it cost you originally, or what overheads it imposes on you. All this gives us a picture of the project in business terms.

Based on that, we might explain that we’ve built something similar to what you want, and that it cost $35k.

Now, that’s important information for you, because it shows we’ve handled enough projects to know what ‘projects like this’ cost. If a developer tells you, ‘We can’t tell you anything up front,’ that suggests they don’t really know what they’re doing.

Strong foundation

With a few cards on the table, it’s time for us to ask you what budget you have in mind. Is this a $5k problem, a $50k problem, a $500k problem? And why?

Let’s say you respond that the new system will save you about $100k per year in admin costs and reducing errors, and that you’d pay up to $50k to achieve that.

Crucially, that figure doesn’t come from us. It’s not a reflection of ‘what software costs’. It’s a reflection of value: what the solution would be worth to your business. At the same time, it’s in touch with our ballpark price and the things we can provide. So it’s mutually acceptable, commercially sound, and technically realistic. And it’s a very strong foundation for our relationship.

Maybe you want to attach some strings to your $50k. You might not want to spend it all at once. You might want us to build a pilot solution first, or postpone some decisions until later. That’s fine. The $50k figure is still very useful to us, both before the project and during it.

Working to a fixed budget takes a lot of discipline – on both sides. We’ll need your help to analyze workflows down to the last detail and make either/or decisions on which solution to choose. But the reward for you is an application that solves the most important problems in your workflow really well.

If you want to approach other suppliers too, we’d encourage you to use the same approach. Have a chat, float a budget, and invite proposals. You’ll learn far more about their service than you would from a basic quote. And if they don’t tell you that much – or can’t – that’s some valuable information right there.

At the end of the day, a negotiation isn’t a battle. It’s about both sides finding out information so they can make a deal that works. So if the best way to get truly useful information is to disclose your budget, why wouldn’t you do it?