Real software for real people (and why that is harder than it sounds)

“Real software for real people” is easy to print on a website. It is harder to defend in week nine of a project, when a stakeholder wants a clever exception, a developer wants an elegant abstraction, and the person who will actually click the button has not been in the room since the kick-off. At Always49 that sentence is not branding filler. It is the test we keep bringing the work back to. Does this help someone do a real job, in a real context, with the time and confidence they actually have?

A lot of software is built for an imaginary user who is calm, trained, on a large monitor, and fully invested in your information architecture. Real people are covering a lunch break. They are on a warehouse floor. They are a volunteer. They are a finance lead who opens the system once a month. They are a candidate trying to complete a check on a phone. If your product only works for the imaginary user, you have built a demonstration, not a tool.

That is why we do not treat software development as a separate craft from design. Code that is “correct” can still be hostile. A workflow that is technically complete can still ask someone to re-enter information they already gave you, or to remember a code that the system could have remembered for them. Those are development decisions as much as they are design decisions. They live in validation rules, empty states, permissions, and the shape of the data. You cannot sprinkle UX on afterwards and hope it sticks.

Custom software exists because off-the-shelf tools eventually run out of honesty. A generic platform will get you moving. Then the workarounds start: the spreadsheet beside the system, the WhatsApp group that is really the workflow, the person who “just knows how to make it behave”. We have a lot of respect for those workarounds. They are evidence of people trying to get the job done. They are also evidence that the software has stopped supporting them. Our job is to notice that moment and build something that fits the organisation rather than forcing the organisation to contort around a license.

We work that way with start-ups and with teams who have been running for decades. The brief changes, but the principle does not. AJG Parcels needed a proof of delivery system that could stand up in the north of Scotland, not a demo that looked good in Bristol. Comtec needed a portal that staff and clients could trust with translation work. BillyChip needed something that helps get food and drink to people facing homelessness, which is not a context that forgives fussiness. In every case the software had to disappear into the work.

There is an opinion buried in that, and we will own it: we think too much of the industry is still competing on features. Feature count is a comforting way to run a project because you can tick things off. Usefulness is less comforting because it requires you to watch someone struggle and then change your plan. We would rather have that discomfort in a prototype than after launch. Launch is a terrible time to discover that the clever bit was only clever to the people who built it.

Clean, maintainable code is part of being kind to real people too, even if they never see it. Software that cannot be changed safely becomes hostile the moment the organisation evolves, which organisations always do. We build to be supported and scaled, not to look impressive in a repository. That means saying no to a fashionable stack when a simpler one will last. It means documenting the why, not just the what. It means using AI to accelerate implementation without letting it scatter five different patterns through the same module.

If you are commissioning software this year, ask the team one question that cuts through the pitch: "who is the most extreme user of this product, and how will we know the software works for them?". If the answer is vague, you are about to build for a meeting! Always49 would rather build for the person who has to use it when nobody from the project team is standing over their shoulder. That is the only audience that can tell you whether the software is real.