I build custom software for a living, so you might expect this note to end with "build it." Usually it does not. Most of the time, for most of a business, an off-the-shelf product is the better buy. This note is about the times it is not, drawn from three things I know firsthand: the software that runs a youth league I operate, a Bible reading app I built because I wanted to use it, and a grant platform we built for an adoption nonprofit.
When is SaaS the right answer?
When the work you need done looks like everyone else's, and a product already does it the way you work. Buy it, and spend your time on the part of the business that is actually yours.
Email, accounting, payroll, scheduling a meeting, a basic website: thousands of businesses do these the same way, and the products for them are mature, supported, and improved every month by people who do nothing else. You will not out-build that, and you should not try. The same goes when you are still finding out how your process should work. Software you own sets a process in place; if the process is going to change every month, rent something flexible until it settles.
I say the same about my own stack. When I moved this site off a managed hosting platform onto infrastructure I own, I wrote that the managed platform is the right answer for most people, and that if your time is worth more than the difference, you should stay. That holds for business software too.
What are the signs you have outgrown it?
The product is still running, but your team is doing the real work around it: in spreadsheets, by hand, or by re-typing what it should have read for you.
The Advantage Flag League ran on Sports Connect, and nothing off the shelf fit how the league actually works. Most of our families pay by paper check, and those checks were keyed in one at a time, about thirty seconds each, in batches of fifty to seventy. Sorting players into fair teams took 20 to 30 hours of spreadsheet work. The work that made the league ours happened outside the software, by hand.
A few signs, from that and from building for clients:
- The same data is typed twice: once into the product, once into the spreadsheet where the real decisions happen.
- The way you get paid, approve things, or keep records is not one the product supports, so it happens outside it.
- The workaround has an owner, and the business would stall if that person left.
- The product is changing under you, or going away. Sports Connect has reached end of life, so the league had to move to something either way.
One of those is a reason to look around. Several at once is a reason to consider building.
What does operator-built mean?
Software written by, or right beside, the person who does the work, so it fits how the work is actually done instead of how a product team imagined it.
I run the Advantage Flag League, and I built Advantage Sports, the software that runs it, about 1,500 families a season. Every feature came out of a real problem with a real parent on the phone. Because the league takes no cards, checks, bank transfers, cash, and money orders all land in one ledger. An admin scans a batch of checks into one PDF, the software reads each check and matches it to a registration. Strong matches confirm themselves, an admin reviews the rest, and nothing posts until an admin says so. Team formation is a solver that puts friend requests and schoolmates first, then balances by grade and quarterbacks, and nothing goes live until an admin accepts it. No product was going to be built around paper checks for one league. Someone inside the league had to.
Biblical Battle Plans started the same way, smaller. I read a physical Bible and wanted to keep a reading streak without moving my reading into an app. Nothing like it existed, so I built it.
Operator-built does not have to mean the owner writes the code. No More Fatherless is an adoption nonprofit whose small team reads every grant application. What they needed was specific: an application a family can finish without making an account, a review the team can keep up with, receipts kept off the public web with every read logged, and a record of what each family was asked that still holds up years later, even after a question is reworded. We built it close to the people doing that work, so those details were in it from the start rather than worked around after.
What does owning it cost you, in time and in running costs?
More attention than a subscription, and someone has to be responsible for it. The hosting bill can be small. The bigger cost is keeping the software working.
Running costs depend on what the software does. This site, a low-traffic marketing site on infrastructure I own, runs for under $10 a month, most of it a fixed DNS cost rather than traffic. A platform that reads check images or sends texts to families costs more, because it does more. Ask whoever builds it what yours will cost to run before you start, and expect a straight answer.
The time cost is the one people underestimate:
- Someone owns it. When a SaaS product breaks, you open a ticket. When your software breaks, someone you know fixes it. That is either you, your builder, or nobody.
- It needs upkeep. Dependencies age, providers change their terms, and new needs show up mid-season.
- It can outgrow its first version. Biblical Battle Plans hit its limits around a hundred users: no test environment, and the rules of the game buried in database queries. I rebuilt it as version two, with the rules in one shared package covered by tests, and that rebuild is what let a native iOS app run on the same server. It was worth it, and it was real work.
What you get for that is software that does exactly what your operation needs, data you own, and no surprise when a vendor reprices, changes direction, or shuts the product down.
How should you decide?
Write down where the hours go. If they go into work any business in your field would recognize, buy a product. If they go into work that is specific to how you operate, and no product touches it, that is where custom software earns its keep.
A short test I use:
- Is the painful part generic or yours? Generic: buy. Yours: keep going.
- Have you tried the products seriously? Ask each one to run a real week of your work. If one fits, use it.
- Is the process settled? If it still changes every month, wait. Build once you know what you are building.
- Who will own it? If nobody will, do not build it.
- Can you start with the one painful part? You rarely need to replace everything. Build where the hours go, and keep buying the rest.
Most businesses should run mostly on products and build only the piece that is truly theirs. I wrote more about that piece, and why I keep choosing the specific and unglamorous ones, in why I build for niches.
If you have a workflow no product fits and a spreadsheet holding it together, tell us about it on the contact sheet. If a product would serve you better, we will say so.