Custom software vs off the shelf for small business is usually framed as a question of price. That’s the wrong end to start from. The better question is how far apart the software and your actual process are. Close together, and you buy and adapt. Far apart, and the compromise costs more than the build.
Name the gap first
Write down what you need as plain steps: “customer emails a request, we price it, we book it, we invoice it.” Mark which steps a product handles without bending. What’s left is the gap, and a short list is a good sign.
Five questions, in order
- How much does a product already do? Demo two or three with your real tasks, not their sample data. If most of your steps fit, stop looking for a build.
- Is this how you win work? A custom quoting flow that makes you faster than competitors may justify a build. Payroll almost never does.
- Can the gap be configured or connected? Many products have settings, custom fields and connections to other tools. That’s the cheapest way to close a small gap.
- Who changes it next year? Products update on the vendor’s schedule. A build changes when you ask. Think about which of those you’d prefer.
- Can you leave? For either route, check how your data comes out before you rely on it.
A shortcut
A quick example
A small removals company wants to track jobs. A standard scheduling product handles bookings, crews and invoices. What it can’t do is price a job from a room-by-room inventory, which is how this firm quotes. The gap is one step, so the firm buys the product and connects a small quote builder to it. It doesn’t build a whole system.
When buying wins
- The job is common: accounting, scheduling, email, payroll, e-signature.
- You’d happily change a step to match the product.
- You want updates and support to be somebody else’s problem.
- The product connects to the tools you already use.
When building wins
- Your process is specific and it’s why customers pick you.
- You’re stitching together four tools and a spreadsheet to approximate one workflow.
- People re-enter the same data in several places.
- A product would force a change that costs you more than the software saves.
The third answer: buy, then add
Most of the time, the right answer is neither. You use a product for the common job, then build a thin layer for the part that’s yours: a form that feeds it, a report that reads from it, or an approval step before it acts. That layer is small, which keeps it quick to build and easy to change, and the product handles everything people already know how to use. Our page on custom internal tool development explains how a small build like that goes.
Questions for a vendor, and for a builder
Ask the vendor
- Can I see my own process in the demo, not yours?
- How do I export all my data, and in what format?
- What happens to my setup when you change the product?
Ask the builder
- What’s the smallest version that does something useful?
- Who can change it when I need something different?
- What does it connect to, and what happens if one of those changes?
What we need from you
- A plain list of the steps in the process you’re deciding about.
- The products you’ve already tried or priced.
- An example of the work that goes wrong today.
- Someone who can say what’s essential and what’s habit.
If you can describe the gap in one sentence, you can probably close it cheaply. If you can’t, that’s the first piece of work.