Most people who talk to us have never commissioned a database before.

Step 01 · “Hello”

First, we say hello. And there’s no charge for that.

We’ll arrange a time to talk – in person if that’s practical, or via Teams or Zoom. We’ll find out about you, your organisation, and what you’re hoping a database might do for you. You tell us what you need, outline your budget and timescales, and we’ll give you an honest assessment of whether we can help.

It’s also, frankly, a chance to work out whether we’re going to get on. That matters more than people sometimes think – you’re going to be working closely with us for weeks or months. We find you get a pretty good sense of it in the first conversation.

We’re a Microsoft house – Access for smaller systems, SQL Server and .NET for larger or web-based ones. If what you need sits outside that, we’ll say so here rather than waste anyone’s time.

Step 02 · Discovery

Getting properly under the skin of it.

This is when we really get to know you, your organisation and your processes. We’ll look at what you’re doing and how you’re currently doing it. We’ll talk to the people who will have a direct input into the design – and crucially, to the people who’ll actually be using the database day to day. Those are often different people, with different ideas about what the system needs to do. We need to hear from both.

Together, we build a picture of what works and should be carried forward, what needs to improve, and what can be left behind. We’ll also look at the other systems you use – to make sure your new database fits properly into the picture rather than creating new problems while solving old ones.

This stage is critical. Rushing it produces a system that solves the wrong problem beautifully.

Step 03 · The numbers

The written estimate.

Using everything we’ve learned, we put together a plan of the work to be done – what’s in scope, what’s out of scope, and a written estimate of the likely cost. Something you can take to your finance director and know exactly what you’re agreeing to.

Wondering how we arrive at that figure – and whether a fixed price is possible? We’ve written an honest answer to that. →

Step 04 · Design

The detailed design.

Now we get into the detail. Every screen, every button, every report – planned and described before a line of code is written. This is also where we get a much clearer picture of anything likely to be more complex than initially anticipated, so if the scope is growing we can have that conversation early rather than late.

If at this stage you decide some elements should be postponed or dropped, that’s a perfectly reasonable decision. Better to know now than halfway through the build.

Step 05 · Build

Building – in stages, with you involved throughout.

We don’t disappear for three months and emerge with something finished. We build in stages, rolling out early versions – with scaffolding still in place and a hard hat firmly on – so you can test and give feedback before the whole project is complete. If something isn’t right, you tell us before it’s too late to change it.

All our code lives in a GitHub repository that we share with you from day one. Full visibility at every stage – and full access to everything we’ve built, whatever happens.

Step 06 · Testing

Testing – properly, before anything goes live.

Before anything goes live, it gets tested properly – by us and by you. Real data, real scenarios, real users doing the things they’ll actually do. This is the stage where the edge cases surface. It’s much better to find them now, rather than after…

Step 07 · Go live

It's Go-Live day!

On go-live day, your staff get access to the system with real data. Then, typically, we all go to the nearest pub and celebrate a job well done.

Or rather – we stay around and resolve questions, provide on-the-spot training and support, and generally deal with anything that becomes apparent when real people start using a real system for the first time.

When we hand over, your team owns everything – the code, the documentation, the GitHub repository. You are not dependent on us to keep it running. That’s deliberate.

Systems that only their creators can maintain are a liability, not an asset.