Decisions

Should you buy or build your internal tools?

Published September 14, 2026 · Lefty Software LLC

Buy vs build for internal tools is a question I get asked after the spreadsheet has already failed, which is usually the right time to ask it. My honest default answer: buy. Mature off-the-shelf software handles the commodity parts of every business — accounting, payroll, email, scheduling, customer records — better and cheaper than anything you would commission. But "default" is not "always", and the interesting work is knowing which side your particular tool falls on. Here is the decision process I actually walk through with clients, including the answer that costs me work: sometimes the recommendation is to keep buying and not build anything.

When buying wins

Buy when the workflow is commodity, and most internal workflows are commodity. If dozens of unrelated businesses could use the same tool unchanged, a vendor has already built it, hardened it, and spread its cost across many customers. Signals that you are in buy territory:

• The process looks like a standard one — invoicing, expense approval, time tracking, a simple CRM — with only cosmetic differences in how you do it.
• The vendor offers an import path for your existing data and an API for the tools around it.
• Nobody in the business can articulate what your version of the process does that a standard version should not.
• The team adopting it would rather learn a proven interface than specify a new one.

Taking a configuration-heavy off-the-shelf tool and bending your process slightly toward it is usually cheaper over its lifetime than commissioning software that encodes your process exactly — because your process will change before the software does.

When building earns its keep

Build when the workflow itself is the advantage, or when no tool can describe it without breaking it. The reliable signals:

• The rules live in one person's head. A spreadsheet only one colleague can safely edit is a custom system with no documentation, no backup plan, and a bus-factor of one. That is an argument for building deliberately what you already built by accident.
• Your process is genuinely different. Racquet stringers tracking inventory to the half-reel, clubs juggling courts, coaches, and lineups — domain-specific precision is exactly what generic tools flatten away. The StringBench case study is this argument in product form.
• The workaround tax compounds. Duplicate entry between two systems, exports reconciled by hand, rules enforced by memory — each is small; together they are a silent payroll.
• Compliance or customer commitments demand exactness that a generic tool cannot evidence.

The questions that settle it

When a client brings me a tool idea, these are the questions that actually move the decision:

• What breaks if this workflow keeps running as it does for another year? (If the answer is "nothing much", the project is a wish, not a need.)
• Is the workflow stable enough to specify? Building software on a process that changes monthly means paying to encode each change.
• Have you tried to buy it first — seriously, with a trial and your real data, not a demo video?
• If you build it, who maintains it when the person who commissioned it moves on? Software is a pet, not a photograph.
• Can you get your data out of whatever you choose — vendor or custom? Ownership and exit paths belong in the decision, not the divorce.

The middle path: configure before you build

Most real answers live between the poles. Configure an off-the-shelf tool thoroughly before dismissing it. Automate the seams between purchased systems with a small integration instead of building a whole product. Build only the piece that is genuinely yours and let commodity software do the rest — a custom scheduling core can live happily beside purchased accounting and email. The worst pattern is the full custom build whose first module re-implements invoicing badly.

How I run the decision with clients

Discovery exists to answer this question before anyone commits to anything. I map the current workflow with you — who does what, in which tools, where it breaks — and I give an honest recommendation in writing, including "configure what you already own" or "keep the spreadsheet, it is fine" when that is the truth. New projects are fixed-price. I agree a written scope and quote with you before development starts, so the initial build has a defined cost. Changes and maintenance can be provided at an agreed hourly rate. And if buying is right, saying so costs me a project and buys a client who trusts the next recommendation.

If the decision goes the other way and a build makes sense, the engagement is the one described in what to expect when hiring a solo developer, and the budget math is in what a custom web app costs in 2026. The products in the CourtWiz case study — scheduling for racquet-sports clubs — show a build that earned its keep because the domain genuinely needed it. I am based in Bradenton and work with clients remotely; Gulf Coast businesses can read about custom software development in Bradenton, Sarasota & Tampa Bay, or start from my custom web app development service.

← More from the blog