Custom Internal Tools vs Off-the-Shelf: When to Build Your Own Operations Software

Prices are in US dollars. Euro and pound figures in parentheses are approximate, rounded conversions. Quotes are issued in the currency of your contract.

Every operations leader eventually owns a spreadsheet that has become a system. It has tabs that only one person understands, a weekly ritual of copying data from the ERP into it, and a growing list of mistakes that trace back to it. The question is what to replace it with: a product you can buy today, a platform you configure, or a tool built for the way your company works. This post gives you the comparison, the signs that you have outgrown what you have, and a decision rule that holds up in a budget meeting.

What are the three options?

What are the signs you have outgrown spreadsheets and SaaS?

• People re-key data between systems. If someone's job includes copying from one screen into another, you are paying a salary to be an integration. This is the most expensive sign and the easiest to measure.
• The spreadsheet has an owner. One person knows how it works, and the process stops when they are on holiday. That is a system with a single point of failure.
• You run three tools for one process. A ticketing product, a spreadsheet and an email thread that together form the real workflow. Nobody can report on it end to end.
• Workarounds have become training. New staff are taught which fields to ignore and which buttons not to press. The product no longer fits the process.
• Reporting is a monthly project. If the numbers the board sees take someone a week to assemble, the data is spread across systems that do not talk.
• Errors reach customers. A wrong price, a missed delivery, a duplicated invoice, traced back to manual steps. Each incident has a cost you can put a number on.
• The license bill grows faster than the team. Per-seat pricing for a tool half the company only views means you are paying for access, not value.

Two or three of these together mean the current setup is costing more than it appears to. Count the hours and the incidents for a month and you will usually find the case for change makes itself.

When should you buy off-the-shelf?

When the process is one that thousands of other companies run the same way. Payroll, expense claims, help desk ticketing, email marketing, document signing and general accounting are solved problems, and the products that solve them are better than anything you would build. The test is whether a vendor's demo matches your process at least 80 percent of the way without you explaining exceptions. If it does, buy, and change the remaining 20 percent of your process to match. The product's opinion is usually better than the habit it replaces.

Buying is also right when you do not yet know what you need. A year on a cheap product teaches you which features matter, and that knowledge makes a later build much cheaper to scope.

When should you configure a platform?

Low-code and configurable platforms suit processes that are mostly standard with a few company-specific fields, approval chains or forms. Internal request portals, simple case management and data collection apps fall here. The platform gives you forms, workflow and permissions, and you configure the rest in weeks. No-code vs custom development sets out the honest cases for each.

Watch for three limits. The first is integration with the systems that actually run your business, where the connectors are often shallow. The second is scale, since platforms price per user and per record and the bill can double when the tool succeeds. The third is the point at which configuration turns into code: once your team is writing scripts inside the platform to get around its model, you are building custom software on rented ground.

When should you build a custom internal tool?

• The process is your advantage. How you quote, schedule, allocate or fulfil is why customers choose you. Encoding it in someone else's product gives up the edge.
• It spans systems. The tool needs to read from the ERP, write to the CRM and trigger something in the warehouse. Off-the-shelf products connect to their own ecosystem, not to yours. Enterprise application integration explains what connecting those systems involves.
• The volume justifies it. A tool used by five people all day, or by fifty people for an hour a day, saves enough time to pay for itself in a year. A tool used by two people once a week does not.
• The data has to stay yours. Regulated data, commercially sensitive pricing, or a data model you want to keep for the next system.
• You have tried the first two. A product that nearly fit and a platform that nearly worked are good evidence that the process is genuinely different.

A custom tool is not a monolith. Most of the tools we build for operations teams are one screen and a handful of workflows, built on top of the systems the company already has. The expensive mistake is to build a replacement for the ERP when what the team needs is a better window into it.

What does a custom internal tool cost over five years?

The totals are closer than most buyers expect, and the custom line is the only one that falls over time while the others rise. The figures exclude the cost of manual work, which is where the real difference sits: a tool that removes two hours a day from ten people saves roughly a full salary every year. Build vs buy runs the same comparison for core systems rather than departmental tools.

The decision rule

How to start a build without betting the department on it

1. Map the process as it really runs. Not the documented one. Sit with the people doing it and record every handoff. Workflow automation with custom software shows how.
2. Pick the one workflow that hurts most. Build that first, in three to five months, and put it in front of the team. Expand from there.
3. Keep the data model honest. The tool should read from the systems of record, not become a second copy of them.
4. Run a short discovery. Three to eight weeks produces a scope and a price you can defend. The discovery phase explains what you receive.
5. Plan the rollout. The best tool fails if the team keeps the spreadsheet open beside it. User adoption for internal software covers the first 90 days.

How 7L approaches this

7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens. We were founded during the Greek financial crisis and have supported more than one hundred organizations since, often starting with exactly this question. Our honest answer is frequently to buy, and we say so in the first conversation. When the answer is to build, we start with one workflow, connect it to the systems you already run, and hand you code and data you own. Our enterprise software development guide covers the full process. If you have a spreadsheet that has become a system, tell us what it does and we will tell you which column of the table you are in.