Software shaped around how your business already works

When custom software is the right answer

We turn down custom software work regularly, because a great deal of it should not be built. If an established product covers most of what you need at a fraction of the price, buying it and configuring it properly is the better business decision and we will tell you so. Being willing to say that is what makes our recommendation worth anything when we say the opposite.

Custom software genuinely makes sense in a handful of situations. The first is when your process is unusual enough that every available product forces expensive compromises, which is common in specialised trades, education and regulated environments. The second is when the process is the business, so the software is not overhead but part of what makes you better than competitors. The third is when you are paying for several products that almost do the job and spending significant staff time moving data between them.

The fourth situation is the most common of all. A business has grown around spreadsheets and email, the arrangement is now failing, and no product exists because the process was invented internally over fifteen years. That process usually contains real intelligence about how the work should be done, and the right answer is to encode it rather than abandon it.

Understanding the work before designing the system

Every custom build starts with time spent watching how the work actually happens. Not how the manual says it happens, and not how the manager believes it happens, but how the person doing it at four on a Friday afternoon actually gets it done. The gap between those three descriptions is where most failed projects live.

We pay particular attention to the exceptions. Any supplier can build the normal case. Real businesses are full of situations where a rule is bent for a long standing customer, where a manager overrides a price, where an order is accepted before the paperwork exists because the alternative is losing the job. Software that refuses to allow those things will be abandoned within a month. Software that permits them while recording who authorised what is software people can actually use.

The specification that protects both sides

Everything we learn becomes a written specification describing the system in ordinary language. It covers every screen, who can reach it, what it shows, what the buttons do, which rules apply, what happens in the awkward cases and what reports exist. It is written to be read by the business owner rather than by a programmer.

This document does several jobs. It lets you approve a plan before serious money is committed. It gives us a definition of finished, which protects you from a project that never ends and protects us from scope that grows silently. It gives your team the chance to correct our understanding while correcting it is free. And it forms the basis of the estimate, which is why our numbers hold up better than figures produced from a conversation and a hunch.

Building in stages you can see

Development is delivered in slices you can log into and use. Typically the first slice covers accounts, permissions and one complete workflow from beginning to end, so the shape of the system becomes real early. Subsequent slices add the remaining areas, each demonstrated as it arrives.

The reason is economic rather than philosophical. Feedback is cheap while the surrounding code is still flexible and expensive once everything is wired together. A client who sees a working screen in week three and says the order of steps feels wrong has cost us an afternoon. The same comment in week fourteen is a rebuild. Visible progress converts expensive surprises into inexpensive corrections.

What you own at the end

On completion you receive the source code, the database structure and the deployment documentation. The software is written in Python and Django, which thousands of developers know, using conventional patterns rather than clever tricks that only their author understands. If you ever decide to work with somebody else, everything they need is already in your hands.

We take that position deliberately. A supplier who needs to trap clients has already conceded something about the quality of their work. We would rather keep clients because leaving would be a loss, not because it would be difficult.