You probably won't be surprised that our answer is "It depends..."

But what does it depend on? And can you know in advance what the final figure might be?


What does a database cost?

What affects the price of a database?

In database design, complexity = development time = cost. 

Note that when designing a database, size isn't typically a major factor, if, by size, you mean the amount of data. Storage is cheap - but developer time is not. So, if you simply need a way of storing a list of more than a million rows of data, because your Excel spreadsheet has given up the ghost, well, a couple of days of work might be enough. So in that case, a budget of perhaps £1500 would work.

But if you want us to design a database with, say, 5000 rows of data that need to be presented in numerous, flexible ways, with security at varying levels, and access for people across the world, connecting live to other tools and applications.... that'll be more expensive. It could be £10,000 or more.

In short, it's impossible to say "A database design will cost X" until we know what you're expecting from your database. That's why our first step is always to sit down with you (in person or remotely) to chat about your requirements, timescales and expectations - as well as your budget.  And, of course, that first conversation is never something we'd charge for.

But first, let's talk about the number one question we get asked...

Will you give me a fixed price database design?

The short answer to that is that yes, we can give you a fixed price.

But you might not like it.

Bear with us as we use an analogy...

Here's why designing
and building a database
is a bit like climbing a mountain.

Imagine standing at the foot of a mountain.

You've climbed many other mountains. You may even have climbed this one.

Of course, you have a pretty good idea of what's involved.

But what will the weather be like at the top? Will there have been a rockfall since you last climbed it, out of sight right now, blocking the usual route?

The thing is, there's just no way of seeing every snag, every problem and every challenge that you'll encounter. And that's a fact, too, of building and designing databases, no matter how good and experienced the developers.

So that raises a question.

What do you do when you hit an unexpected issue?

If we're working as we'd like to, when we design a database, you're simply paying for our time. We've given you an initial estimate, and we've given you refined estimates after the database design phase, but you're paying for our time to turn those designs into reality. So, if we hit a problem that means it's going to take longer than anticipated, you'll end up paying more than anticipated... for that element of the work.

But in the fixed price scenario, here's what happens. We know, just as you do, that we'll hit these issues along the way, no matter how careful the planning. And we know that our developers have to be paid for their time, whether that time was foreseen or not. So when we produce our fixed price quote for you, we have to build into that quote, the unknown amount of time to fix things we don't yet know about.

There are two laws of time management. Law 1 says that everything takes longer than you think. Law 2 says that everything still takes longer than you think - even if you take Law 1 into account.

And so we have to include a margin for unknown future issues for every screen, and every piece of code.  Yes, that means that you won't pay more than you thought you would. But it also means that you're likely to be paying more than you could, and perhaps should, have paid. We assume all the risk, and to continue to operate as a business, it's evident that we must mitigate against that risk.

How much is the margin? The most common figure I've heard from developers is that they will charge at least double on a fixed price contract. We typically charge rather less than that, but we also wouldn't be able to produce the fixed price until we've got to the end of the design stage, and so have a clearer view of what's involved.

Some clients don't mind paying that extra for the security of a fixed price, and if that's you, then fine. But many prefer to pay what it takes to build the database, and share that risk as well as the rewards.

Finally, to give you an external perspective, I'd like to mention what respected developer Armen Stein, of US developers "J Street technology" says on the issue: If you're paying for our time by the hour, and we hit a problem, we're all on the same side - trying to fix it as quickly as possible. But if you've paid a fixed price, we're immediately on opposite sides of the table, trying to work out whether the issue is foreseeable, and "our" problem, or a change of scope for the database, and so "your" problem. He says - and we agree - it's usually better to avoid these "Us versus them" scenarios right from the start.

Let's start by having a conversation

0 of 350