Should I build an internal tool or buy existing software?

Question

VX-N · Accepted Answer

Buy when the process is common and a mature product exists. Build when the process is how you actually compete, when no product fits without painful workarounds, or when per-seat pricing across a growing team exceeds what a focused build would cost. The question to ask is not 'can we build it' but 'do we want to own it forever'. Every internal tool is a permanent maintenance commitment: dependencies age, the person who understood it leaves, and the tool quietly becomes load-bearing for processes nobody documented. That commitment is worth taking on for the process that makes you money; it is a bad trade for a commodity job — accounting, payroll, email, and scheduling are solved problems, and building your own version of one is paying to reinvent a product with a fraction of the testing. A middle path works surprisingly often: buy the platform, build the thin custom layer that makes it fit. You get the vendor's maintenance and your own workflow. Most 'the software doesn't fit' complaints are really about the last 15% — the approval step it cannot model, the report it cannot produce, the two systems it will not talk to — and a thin layer over the vendor's API solves that without taking on the whole product. Watch for the tell that the decision has already been made for you: the workaround layer. When the team runs the 'real' process in spreadsheets exported from the product, re-imports corrections by hand, and keeps a shadow tracker for what the product cannot represent, you are already maintaining custom software — the worst kind, with no permissions, no history, and no owner. At that point the build is not an addition to your costs; it is the consolidation of costs you are already paying in labor and errors. The buy side of the ledger deserves honest arithmetic too. Per-seat pricing compounds with headcount forever, tiers gate the features you actually need behind the expensive plan, and the switching cost grows every month as your data and habits accumulate inside the product. Compare three years of subscription plus the workaround labor against a one-time build with maintenance — not one month against one invoice. The arithmetic itself has shifted. The old default was buy, because building meant quarters of developer time and a six-figure quote. With AI in the delivery loop, a focused internal tool ships in days or weeks — roughly ten times faster than the pre-AI norm — which moves the crossover point toward build for any process that is genuinely yours. The honest test is unchanged: if a mature product models your process well, buy it and move on. What changed is how often the answer to 'does anything actually fit?' can now affordably be 'no, so we built exactly what we needed.'