What we settle before we write a line of custom software

Most software that disappoints was not built badly. It was built before anyone agreed what it had to do on a bad day.

Abstract lattice of code lines, illustrating custom software development

Most software that disappoints was not built badly. It was built before anyone agreed what it had to do on a bad day — when the upstream system is down, when the data arrives twice, when the person who used to approve things by hand is on holiday. Those days are the product. Everything else is typing.

Who the system is for, specifically

We start by naming the three or four people who will actually open the screen: the dispatcher at six in the morning, the finance lead closing the month, the support agent with an angry caller on the line. A feature list written for "the business" always collapses later into contradictions. A feature list written for named roles tends to survive contact with reality.

  • The dispatcher who opens the screen first thing in the morning
  • The finance lead who has to close the month from it
  • The support agent reading it with a caller on the line
  • The engineer who will be woken up when it misbehaves

A feature list written for "the business" collapses into contradictions. One written for named roles survives contact with reality.

What the system is allowed to be wrong about

Every integration eventually serves stale or incomplete data. The useful question is not how to prevent that, but which numbers must be exact and which may lag. Stock counts that drive a picking decision are not the same as a dashboard refreshed every ten minutes. Deciding this up front changes the architecture; discovering it in production changes the weekend.

How we will know it worked

Before the first sprint we agree what we will measure after release and where that measurement comes from. If no one can point at the report, the goal is a wish rather than a requirement. It also keeps us honest: a feature nobody can show the effect of is a feature we should probably not build yet.

The first release is deliberately small

We would rather put a narrow slice in front of real users in weeks than a complete vision in months. The slice has to be genuinely useful end to end — one process, done properly, with the monitoring and the handover notes. Everything we learn from it is cheaper than everything we would have guessed.

More articles

Working on something similar?

Tell us about your project

Send us a short description of what you are building — or what is not working — and one of our engineers will come back to you.

Talk to us about your project Back to Blog