Build an internal tool when the required fit and control justify owning it over time; buy when a supplier can carry the responsibility more economically. Compare the whole operating choice, including maintenance, support, access, and the work your team will postpone.
AI-assisted coding changes the cost of getting a prototype onto a screen. It does not make every software subscription irrational. Nor does it mean buying is always safer. A tool that is badly matched to the workflow can create enough manual effort to erase the convenience of outsourcing its maintenance.
Define the smallest useful job
Start with the work, not the purchase category. 'We need a CRM' is too broad for a useful comparison. 'We need an authorized account owner to see the latest client commitment and the next agreed action' is a job you can evaluate.
List the essential inputs, outputs, users, permissions, and failure consequences. Separate what is genuinely required from what would be pleasant. The easiest way to make building appear necessary is to compare a long imagined wish list with a real supplier's limited product.
Also describe the current workaround. If the team can complete the job with a spreadsheet and a short meeting, the improvement needs to be worth the change. A new internal tool can add another place to update without removing any existing work.
Price ownership honestly
The build estimate should include more than generating the first version. Include review, deployment, access management, integrations, changes to the underlying workflow, support, and eventual retirement.
Google's toil framework identifies repetitive operational work. Read the explanation. Ask whether owning this tool will displace work the company exists to do.
The buy estimate also needs honesty. Include onboarding, configuration, limitations, manual workarounds, account administration, switching costs, and the risk that the provider changes the offer. Do not assume a subscription eliminates responsibility for how your team uses the product.
Use ranges if you lack evidence. A confident total built from uncertain inputs is less useful than a transparent comparison that identifies the biggest unknown.
A hypothetical comparison: client handovers
Suppose a five-person agency needs a client handover tool. A founder estimates eight hours to create a prototype and two hours a week to maintain it. Those figures are assumptions for this example, not benchmarks.
A purchased option costs money but requires only a short configuration exercise. It cannot represent one unusual handover step, which the agency currently handles manually. The build option represents that step exactly, but depends on the founder whenever access rules or integrations change.
The decision should turn on the unusual step's value and the founder's opportunity cost. If the step is infrequent and easy to document, buying may be sensible. If it is central to the agency's differentiation and repeatedly expensive, a narrow internal tool may deserve a trial.
The founder could also combine the choices: buy the general tool and build a small, well-bounded addition. Build versus buy is not always an all-or-nothing decision.
Make continuity part of the comparison
Who owns the tool when its original builder leaves or becomes unavailable? Can another authorized person understand the accounts, deployment, data model, and recovery procedure? If not, the apparent saving includes an unpriced dependency on one person.
Data recovery deserves a specific answer. PostgreSQL's official documentation describes different approaches to backup and restore, illustrating why the details matter. See the backup overview. Use the equivalent documentation for your actual stack rather than assuming every hosted service provides the same protection.
For a bought product, inspect export and cancellation before signing up. Can the records be used elsewhere, or does an export omit the relationships and attachments that make them meaningful? A cheap purchase with a poor exit path may become expensive later.
The counterargument: ownership can create learning
Some internal tools are worth building because the process itself teaches the team something important. A prototype can reveal that the workflow is poorly understood, or that a supposed requirement is unnecessary.
That learning does not require committing to operate the prototype forever. State whether the experiment is disposable, temporary, or intended to become production software. Give it a review date and avoid inviting the whole company into a tool whose owner still considers it an experiment.
There is also a limit to buying. If a supplier requires extensive customization and your team still performs most of the work manually, the product may be a poor fit despite its popularity.
A one-page decision worksheet
Compare build, buy, and a simple workaround against the same questions:
- Which required job does this option complete?
- What does it deliberately leave manual?
- What is the initial effort and recurring responsibility?
- Who handles permissions, failures, and changes?
- What work will the owner postpone to maintain it?
- Can information be recovered and exported?
- What would make us reverse the decision?
Choose the smallest reversible commitment that tests the largest uncertainty. The winning option is the one that serves the business with an ownership burden it can afford, not the one with the most impressive demo.