Buy first. Build only when you have tried the off-the-shelf option and can name, in plain words, the specific thing it will not do — and that thing is central to how you make money or serve people.
That sounds obvious, but the decision usually goes sideways in the other direction. A team hears "custom app" and assumes it is out of reach, so they buy three subscriptions, glue them together with spreadsheets, and spend an hour a day retyping the same information. Or they hear "custom app" and picture something magic, and start building before they understand the problem.
What off-the-shelf is genuinely good at
Anyone who sells software to thousands of businesses has already solved problems you will never want to solve yourself. Payroll rules. Sales tax. Credit card handling. Email deliverability. Calendar sync across phones. Accessibility. Someone else keeping the thing patched at 2 a.m.
So if your need is a common one — bookkeeping, payroll, email and files, an online store, scheduling, donor receipts — buy it. Pick the boring, well-supported option, learn it properly, and put the time you saved into your actual work. A tool you use 80 percent of the way is almost always better than a perfect tool that does not exist yet.
The signs a custom tool is now the cheaper answer
The honest signal is not "the software annoys me." It is measurable friction that repeats. Watch for these:
- The same data is typed into two systems by hand, every day, by a person you pay.
- Your real process lives in a spreadsheet that sits beside the software, because the software cannot hold it.
- You are paying for seats on a large platform to use one small corner of it.
- New staff need a verbal explanation of the workarounds before they can do the job.
- The thing that makes you different from competitors is the thing no product supports.
That last one matters most. A custom tool is worth building when it encodes how you work — your intake, your quoting, your inspection form, your grant reporting — not when it re-creates something you could have subscribed to.
What building actually costs a small team
Money is the part people ask about, but time is the part that surprises them. A useful custom tool needs someone inside your business to answer questions, look at early versions, and say "no, that is not how we do it." Usually a few hours a week for the length of the build. If nobody has those hours, the project will drift, and that is worth knowing before you start rather than three months in.
Then there is the part after launch. Custom software is not a purchase, it is a small ongoing responsibility: hosting, updates, a place to report bugs, and someone to call when a browser change breaks a button. Budget for it the way you budget for the furnace, not the way you budget for a printer.
The upside is that it is often smaller than expected. Most of the tools we build for small teams are narrow on purpose — one job, done exactly right, replacing a spreadsheet and a pile of email. A focused internal tool is a very different animal from a product platform.
A middle path worth considering
Before you commit either way, look at connecting what you already run. A good deal of daily retyping disappears when Microsoft 365, Shopify, Stripe, or QuickBooks are wired to talk to each other properly. That is often a fraction of the effort of a build, and it leaves you on tools that other people maintain.
If you are stuck between the two, write down the process on one page — every step, every hand-off, every place a human retypes something. The right answer usually becomes obvious on the page before anyone writes a line of code.
