Next WrldMost companies shouldn’t build software for everything
When a tool is uncomfortable, the idea of building something of your own appears quickly. A system made exactly for us, without limitations or forced adaptations. It sounds reasonable.
But most needs already have an available answer. A CRM organizes client relationships. An ERP organizes billing, stock and accounting. Spreadsheets solve one-off calculations. SaaS platforms cover support, marketing and HR. And when two tools don’t talk to each other, often a simple automation or integration is enough to join them.
Building for every discomfort would be expensive and hard to maintain. Each new system asks for attention: fixing it, updating it, caring for it. If the problem is solved by better configuring what already exists, that is almost always the most sensible path.
Growing, or feeling uncomfortable with a tool, is not by itself a reason to build.
The right question is not “can we build it?”
Almost anything can be built. With time and budget, any flow can become a system. That is not the hard part.
The question that matters is another: is there enough business reason to build it? That is, is there a process important, particular and recurrent enough to justify its own investment, when proven tools maintained by others already exist?
Below, eight signs that help answer it. None decides on its own. But when several appear together, it is worth paying attention.
Signs it can make sense to consider your own software
1. The company adapts its processes to the tool’s limitations
The team stops working as would feel natural and starts working as the tool allows. The process needs three approval types, but the tool only supports one, so approval happens by message and then something approximate is recorded. Operations use intermediate states that don’t exist in the system, so everyone agrees on invented codes in a free-text field.
At first these adjustments seem minor. Over time they become the official way of working, although nobody decided it. When operations adapt to software instead of software supporting operations, something inverted.
2. Too many workarounds and parallel solutions
An extra spreadsheet completing what the system doesn’t record. A document with exceptions. Fields used for something different than designed, because there is nowhere else to put that information. Each workaround is born to quickly solve an unplanned case, and separately they seem harmless.
The problem is they accumulate. A point arrives where executing a process requires knowing five places: the main system, two spreadsheets, a chat and a document with clarifications.
When the real process lives outside the system, the system stopped representing the process.
3. The same data constantly moves between systems
The client is loaded in the CRM, loaded again in billing, copied to a tracking spreadsheet and forwarded by WhatsApp to whoever coordinates delivery. Each move is manual loading, an error chance and one more version of the same data.
Using several tools is inevitable. The problem appears when that movement is constant and manual over central data: clients, orders, prices, stock, progress states. Beyond time, confidence is lost: which is the right data, was it updated everywhere, who changed what?
4. Business rules are too particular
Some processes look simple from outside but have their own rules accumulated over years: validations before approving an operation, calculations with exceptions per client type, different permissions by role and amount, intermediate states that only make sense in that business.
Generic tools cover the common case and allow configuration up to a point. But when rules are very specific, configuration starts forcing the tool, and the team sustains those rules with manual work and memory. If those rules sustain quality, margins or compliance, the system should represent them correctly.
5. The process is important enough inside the business
Not every problem deserves its own software, even if annoying. An internal record consulted rarely or a monthly report tolerate an occasional workaround well.
The bar changes when the process touches sales, operations, clients, costs or growth capacity: whether an order is delivered on time, whether billing goes out without errors, whether the team can serve more demand without adding the same number of people.
Process importance turns an annoyance into a justifiable investment.
A small problem in a central process, repeated hundreds of times, weighs more than a large problem in a marginal one. That is why it is worth asking where the problem happens before asking how to solve it.
6. Volume turns small inefficiencies into large problems
With twenty operations per month, reviewing each case by hand is viable and coordinating by message works. But volume multiplies everything: what was a detail with twenty operations becomes structural with two thousand. Daily hours of manual loading, accumulated delays, errors that were exceptional and now appear every week.
The process didn’t change, quantity changed. When each point of growth requires adding manual coordination in the same proportion, the process stopped scaling.
7. The company loses visibility over what happens
There is a simple test: trying to answer basic questions without prior work. What state is each operation in? Who is responsible for each case? Where do cases get stuck? If answering requires joining information from several places, cleaning duplicates and building a special table, the company has no visibility: it has scattered data someone must consolidate each time a decision is needed.
That consolidation is paid twice. It consumes time before each decision and arrives late: when the summary is ready, the situation already changed.
8. Knowledge is concentrated in certain people
Some processes work because certain people know them by heart: which cases are exceptions, who to warn, which field not to touch, in which order to do things so nothing breaks. That knowledge is valuable but fragile. When someone goes on vacation, changes roles or leaves the company, the process suffers.
A well-designed system doesn’t replace people. It stores rules consistently so the team doesn’t depend on the memory of a few.
When not to build custom software
Recognizing the signs above shouldn’t automatically lead to building. There are situations where developing your own software is a bad decision, even if the problem is real.
When the problem is not yet understood well enough, building only freezes confusion into code. If the team can’t describe how it works today, first understand, then decide. And when the process changes every week, it needs to stabilize before systematizing: over something constantly redefined, the system is outdated before finishing.
It also isn’t worth building when a standard tool correctly covers the need. If an existing solution solves eighty or ninety percent of the problem well, forcing development to cover the rest rarely pays off. The same applies when the problem happens rarely and has little impact: systematizing an occasional friction is disproportionate.
Two cases deserve honesty. If you want to develop software to avoid changing a deficient internal process, the first step is simplifying the process, not digitizing it: a bad systematized process only produces errors faster. And if you try to fully replicate a mature SaaS product without a clear strategic reason, the result is usually a more limited, more expensive version of the same.
Not building is also a decision. And often the right one.
Before building there are several solution levels
Custom development is the last step of a ladder, not the first. The first level is the process itself: removing unnecessary steps, clarifying responsibilities. Many problems that look like software are really process problems.
Then comes better configuring current tools, which often have unused features or automations nobody enabled. Then automating specific tasks, integrating tools so they share information without manual loading, and adding a new platform when none of the current ones covers the need.
Only when those levels aren’t enough, because the process is too particular, central and recurrent, does building something of your own start making sense. The right solution can be on any of those steps. Skipping them out of haste usually costs dearly.
How to evaluate the decision from the business
There is no mathematical formula to decide. But there are questions that help think with judgment. How much time the problem consumes today, how many people it involves, how much rework it generates and what happens when an error occurs: an error fixed in minutes doesn’t weigh the same as one delaying a delivery or affecting a client.
Trajectory also matters: if the problem grows with the company, solving it today is cheaper than in a year. And particularity: if the process truly differentiates the business, a generic tool will hardly support it; if instead an existing solution covers eighty or ninety percent, ask whether the rest justifies development.
The last question is value: what would change if the problem were solved, in freed time, avoided errors, faster decisions or capacity to serve more demand. That answer, compared with build and maintenance cost, is the real decision frame.
An everyday example: when the CRM is no longer enough
A company runs operations with a standard CRM. At first it works well: clients are registered, opportunities advance by stages, the team knows where each case stands.
With growth, own processes appear: different client types with different conditions, commercial rules before approving operations, coordination with operations, hand-generated documents, information in parallel spreadsheets, follow-up by WhatsApp. The team responds with ingenuity: custom fields, support spreadsheets, parallel processes for what the system doesn’t cover.
With volume, patches weigh. The same data is loaded in three places. Nobody knows the real state without asking by chat. Validations depend on someone remembering to apply them. Knowledge is split across the CRM, spreadsheets and some people’s memory.
The problem isn’t that the CRM is bad. It is that the process evolved beyond what that tool was designed to represent. The business developed its own way of operating, and that way no longer fits a generic structure.
Possible exits vary: integrating the CRM with other tools, automating documents and notices, changing platforms or developing your own layer for those particular rules. None is right by definition. The decision should emerge after understanding the process: which part is generic and can stay in standard tools, and which part is own, central and recurrent enough to justify something custom.
The decision starts from the problem
Building custom software makes sense when there is an operational need important, particular and recurrent enough that existing tools can no longer solve reasonably.
The decision shouldn’t start by asking which technology to build. It should start by understanding which problem deserves solving.