Tagbookshop software

We’re deep into building our next update right now, which seemed like a good reason to explain what that actually involves. It isn’t someone sitting down and writing new code for a few days. It’s a process, and most of it happens before a line of code changes.

We start with what customers tell us

Every update begins with a review: ideas submitted through Software Ideas, feedback from customers directly, and what our own support team hears on the phones every day. We look at what’s urgent and what will genuinely benefit customers, not just what’s easiest to build.

This step takes longer than people expect. We test what we’re told against the software itself before we act on it, because a suggestion that sounds right in a phone call doesn’t always hold up once you’re inside the actual system. Thoroughness costs time here, and we spend it.

Planning it properly

Once we know what we’re building, we scope it: what the change actually involves, and what else in the software it touches. A newsagency’s software talks to a lot of different parts of itself, magazines, lottery, gifts, loyalty, so a change in one place can affect something you weren’t expecting elsewhere. Understanding that before we start building saves everyone trouble later.

Building it, then testing it, and testing it again

This is the part most people picture when they think of software development, and it’s the smallest piece of the whole process, by far. After the build comes testing. Then more testing. Then testing again. It’s repetitive by design.

We document it before we release it

Once the change is solid, we write it up properly, so it can be explained clearly to customers rather than dropped into an update with no context. Good software isn’t just software that works. It’s software people understand how to use.

Beta testing, in real shops

Before anything goes to every customer, it goes to a small group of engaged customers in live, trading shops. Real stock, real customers, real Saturdays. That’s a different test than anything we can run in-house, and it catches things our own testing sometimes doesn’t.

Only then do we release it

All of that has to happen before an update reaches your till. It’s slower than just shipping code, but it’s why updates tend to work the way they’re supposed to when they land.

We’re in the middle of this right now, building the next one. It’s the same process every time, because it’s the one that works.