A retail site selection study is methodical work: draw the catchment area, measure the population and its spending power, count the competition, estimate potential turnover, and present all of it in a form a business owner can use to decide whether to open a shop or not.
This is what the firm does for a living. Yet the work lived, as it does in many companies, in a pile of spreadsheets, document templates and habits picked up by watching colleagues. Every analyst had their own version, and the complete method existed nowhere in a form you could run.
Why nobody sells this tool
This is the classic case for building something internal. Geomarketing software exists and it is good at what it does. None of it does what this firm does, because what this firm does is precisely its own way of working, which is to say its competitive advantage.
A software vendor is not going to model the method of a twenty-person consultancy. Paying a subscription for a generic tool and then patching the rest together by hand in a spreadsheet means paying for half the problem.
Until recently, the answer was that custom development cost too much to be worth it. The cost of building has collapsed, and the calculation has changed with it.
Build from the work, not from the specification
The engagement did not start with a specification. It started by watching analysts produce a real study, step by step, noting where they lost time, where they copied things across, and where they hesitated because the method was ambiguous.
The application was then built in short iterations, with generative artificial intelligence helping to write the code. A usable version arrived within weeks, and changes followed the pace of feedback from use, in days rather than in quarterly releases.
That speed changes the relationship people have with the tool. When a change takes a quarter, users stop asking and work around it. When it arrives within the week, they report everything, and the tool converges on the real work.
What the tool produced beyond the tool
The most lasting effect was not planned. To write the application, the method had to be made explicit: what data goes in, in what order, under what rules for resolving conflicts, and which conclusions can be defended.
That clarification has value of its own. The expertise stops being an individual skill passed on by apprenticeship and becomes an asset of the company, something that can be handed over, argued about and improved. A new recruit becomes productive considerably faster, because the method is in the tool.
What kills an internal tool, and how to avoid it
It is worth being blunt about the risk. An internal tool rarely dies because it was badly designed. It dies because nobody maintains it, because it has no tests, because nobody is watching it, and because only one person knows how it works.
Those four points are part of the engagement, or it is not worth starting. The code sits in a repository the client owns, the hosting is theirs, the jobs that feed the application are monitored, and the operating documentation is delivered with it.
What transfers
The question to ask is not whether you could build the tool, because the answer is almost always yes. It is whether your way of working is your advantage.
When it is, building can be justified, because no vendor will model an advantage that belongs to you alone. When the need is standard and regulated, like payroll or accounting, buying remains the right choice and there is nothing to discuss.
The end client is not named. The figures quoted are those of the engagement.