The build versus buy conversation almost always gets framed as a cost question, which is understandable because cost is the number that fits in a slide, and it is also the reason the conversation usually reaches the wrong conclusion. When a company compares the licence fee of an existing product against an estimate of what it would take to build something similar, the comparison looks decisive, since the product exists today and the estimate is a guess and guesses about software have a well earned reputation. What that comparison leaves out is that the two options are not producing the same outcome at all, because one of them adapts the software to how the company works and the other adapts the company to how the software works, and only one of those directions preserves the thing that made the company worth studying in the first place.
I want to be careful here, since this is not an argument that buying software is a mistake, and there are whole categories where buying is obviously right and building would be a form of self harm. The argument is narrower, which is that a company usually has one or two processes that are genuinely its own, refined over years by people who understood the domain, and those processes are where the advantage lives, and handing them to a generic product is how the advantage quietly gets traded away for a faster start.
The Commodity Test
The useful question is not whether software can be bought but whether the process it encodes is a commodity. Payroll is a commodity, in the sense that the rules are written by the state, everyone in the same jurisdiction follows them identically, and there is no version of running payroll that constitutes an advantage over a competitor, so buying that capability is straightforwardly correct and building it would consume attention that has better uses. Accounting is mostly the same. Email, calendars, document storage, the tools everyone needs and nobody differentiates on: buy them, configure them lightly, and stop thinking about them.
Then there is the other category, and it is usually smaller than people expect and much more valuable than they realize. It is how a logistics company decides which driver takes which route when three orders arrive at once and one of them is from the customer who always calls. It is how a manufacturer sequences jobs on a machine that has quirks nobody has written down. It is how an agency prices work, which is never a formula, and how a distributor decides what to hold in stock based on a set of signals that live partly in a system and partly in the head of the person who has been doing it for eleven years. That knowledge is the business. It was expensive to acquire, it was acquired by being wrong repeatedly in a specific market, and it is the reason the company is not interchangeable with the one down the road.
These are also, without exception, applications that deal in transactions and commitments rather than in attention, which is a distinction we have written about at length because it determines what standard the software has to be held to. When a dispatch decision is wrong, a truck goes to the wrong place and a customer is owed an explanation, and no amount of eventual consistency makes that acceptable.
Buy the process that everyone runs identically and build the one that only you run.
What Generic Software Does to a Process
A product that serves thousands of companies has to be built around what those companies have in common, which is not a criticism of the people building it but a description of the constraint they work under, since a feature that helps one customer and confuses forty is a feature that will not survive a roadmap meeting. The result is software shaped like the average of its market, and the average is precisely the part of the process that is not an advantage, because if everyone does it that way then doing it that way distinguishes nobody.
What happens next is familiar to anyone who has spent time inside an organization that runs on purchased operational software. The process gets adjusted to fit the tool, usually gradually and usually with good intentions, and each adjustment is small enough that nobody objects. A field that does not exist becomes a convention about typing something into the notes. A step that the product does not support becomes an email sent at the right moment by someone who remembers. An exception that used to be handled thoughtfully becomes an exception that is handled by exporting to a spreadsheet, doing the real work there, and typing the result back in.
That spreadsheet is the most informative artifact in the entire company, and it is almost always ignored. It is not a workaround and it is not a sign that someone is being difficult, it is a specification, written by the person who understands the process best, describing exactly the part of the operation that the purchased software could not hold. It survives because the work genuinely needs it. And it is worth noticing what it costs to leave it there, since it has no history, no permissions, no validation, no backup that anyone has tested, and exactly one person who knows how it works.
The spreadsheet running beside the official system is a bug report which usually points at the part of the business that makes the money.
The Advantage Compounds
When the process lives in an application the company owns, something changes in how improvement works, and this is the part that is difficult to see from a cost model. A person who spots a better way to sequence the work can have it in the software within a week rather than submitting it to a vendor's roadmap where it will be evaluated against the needs of every other customer and quite reasonably declined. The refinement gets encoded, it becomes how the company operates rather than something the good employees remember to do, and the next refinement builds on it.
Over a few years that produces a gap that is genuinely hard to close, because a competitor can buy the same products, hire similarly capable people, and read the same material, but they cannot buy a system that has absorbed a decade of decisions specific to a market nobody else was paying attention to. This is the ordinary and unglamorous version of a moat, and it looks like nothing from the outside, which is exactly why it lasts.
There is a second effect that shows up in the daily work, which is that people stop fighting their tools. An operational app that matches how the work is actually done removes the friction that consumes a surprising fraction of an operator's day, and the friction was never in the interesting part of the job but in the reconciliation, the double entry, the checking that the export matched the system, and the small daily irritations that a purchased product cannot remove because removing them would mean becoming a different product.
Why This Is Affordable Now
The historical argument against building was strong and it was mostly about cost, since building an operational application used to mean a team, a stack of infrastructure, a long project, and a maintenance commitment that frightened everyone who had watched such a project go badly. That argument has weakened considerably, and our whole thesis at Reepolee is built on noticing why.
An internal operational app has a known number of users, who are employees, on machines the company controls, inside a network the company knows. It does not need to survive a traffic spike from a link that went viral. It does not need a hundred thousand concurrent sessions, a global edge network, a message queue between every two components, or a caching layer to protect a database that will never see meaningful load. When you remove the machinery that exists to handle scale you do not have, what remains is a database with a well designed schema, a set of forms, a set of reports, and the business rules in between, and that is work a small team can do well and maintain for years without drama.
The remaining cost is mostly the writing of predictable code, which is the part that generation handles well, since the shape of a form that edits a table is derivable from the table, and so is most of the validation and most of the plumbing. What is left over for people is the part that was always the point, which is the modeling of the domain and the judgment about how the process should work.
Where This Argument Fails
I would rather name the limits than let someone read this as encouragement to build everything, because there are several ways this decision goes wrong and I have seen most of them.
The most common failure by a wide margin is building a commodity. A company decides that its invoicing is special, or its document storage has unique requirements, and it spends a year rebuilding something that could have been bought on a monthly subscription and configured in an afternoon. The test is uncomfortable but simple, which is whether a competitor doing this differently would gain anything, and if the answer is no then the thing is a commodity regardless of how much internal opinion exists about it.
Closely related is building on an unstable process, since encoding a process in software is a bet that the process is worth encoding, and if the company is still discovering how the work should be done, or if the market is shifting underneath the operation, then the software will be an expensive record of an idea that was abandoned. A process that has been running consistently for a few years and has a person who can explain why each step exists is a good candidate. A process that three people describe three different ways is not ready.
The failure that deserves the most respect is underestimating the tail. Software that runs an operation does not get finished, it gets maintained, and the maintenance runs for as long as the business does. Regulations change, an integration partner alters an API, a browser deprecates something, a report needs a new column because the tax rules moved. A company that builds must accept a permanent low level commitment to keeping the thing alive, and organizations that are honest about this build successfully while organizations that treat it as a project with an end date tend to end up with a critical system nobody has touched in four years and nobody wants to open.
Underneath the tail sits the people problem, since a system built by one capable person and maintained by nobody is a liability wearing the costume of an advantage. This has to be planned for at the start, with the code kept boring enough that a competent developer can pick it up, dependencies kept few enough that the project still builds in five years, and the decisions written down while the reasoning is still fresh.
Integration weight belongs in the estimate too, because an in-house app rarely lives alone and usually needs to exchange data with accounting, with a bank, with a supplier, with whatever the larger group standardized on, and each of those connections is a small ongoing obligation rather than a one time piece of work, which is manageable and is not free.
And there is a category where buying is right even though the process feels specific, which is anywhere the real product being sold is regulatory maintenance. In domains where the rules change several times a year and somebody else is professionally responsible for tracking them, the licence fee is buying vigilance rather than features, and that is usually a good trade.
This Is Why Our Approach Looks the Way It Does
Everything in our approach reads differently once you accept that the software being discussed is an operational system a company owns and intends to keep, and I think the principles are difficult to justify in the abstract and almost self evident in that specific light.
We say to design for the next developer because an in-house app outlives the person who wrote it, usually by a lot, and the whole advantage evaporates if the system becomes unmaintainable in year six. We treat the database as a foundation and insist on naming columns like you mean it because the schema is where the company's process is actually recorded, and a schema that lies about the domain will keep the business from changing its mind later. We prefer explicit generated code over hidden behavior because the refinements that compound have to be readable by whoever wants to make the next one. We keep the runtime smaller than the problem because an internal app with two hundred users does not earn the machinery, and every moving part is a thing that has to survive a decade of updates. And we own where the software runs because a process that constitutes a competitive advantage is a strange thing to keep entirely on infrastructure somebody else controls and can reprice.
None of those are aesthetic positions, they are what falls out of taking the in-house operational app seriously as a category, and it is the category the framework was written for.
How We Think About It
What we look for is the seam between the commodity and the craft, and in most organizations that seam is visible within a day of watching people work, because it is wherever the official system stops being used and something informal takes over. We buy the standard parts without arguing about them, and we build the part where the company's actual knowledge lives, keeping it small, keeping the schema honest, and keeping the dependency count low enough that the thing can still be understood and rebuilt years from now by someone who was not there when it was written.
The companies I have watched benefit most from this were not the ones with the most ambitious systems. They were the ones that identified the two or three places where their way of working was genuinely better, encoded exactly those, and left everything else alone.