Custom build or packaged product? How to actually choose.

Almost every expensive software mistake we've been called in to fix started the same way: someone chose build when they should have bought, or chose buy when only a build would ever fit. The technology was rarely the problem. The decision was.

So before we ever quote a custom system, we walk clients through the same set of questions. Here it is, in full — including the parts where we tell people to spend less money than they came in expecting to.

Start with the process, not the software

The first question isn't "what should we build?" It's "what does this process look like when it's working perfectly?" If you can't describe that clearly, no software — custom or packaged — will save you. You'll just digitise the confusion.

Write the workflow down as if you were training a new hire on their first day. Where does work come in? Who touches it? Where does it get stuck today? That document is worth more than any feature list, and it's the thing most vendors skip because it's unglamorous.

When a packaged product is the right answer

Buy off the shelf when your process is genuinely common and the tool already does it well. Accounting, email, calendars, standard CRM — these are solved problems. Paying to rebuild them is paying to be different at something that gives you no advantage.

The honest test: if your competitors do this the same way you do, buy it. You want your custom effort spent on the things that actually make you you — not on reinventing a calendar.

The goal isn't custom software. The goal is the outcome. Custom is just the route you take when no shorter one exists.

When custom is the only honest option

Build custom when the process is the business — when the way you do a thing is the reason clients choose you, and no packaged tool maps to it without forcing you to change how you work. The classic signs:

• You're running the core of your business in a spreadsheet because nothing else fits.
• You're paying for three tools and a person whose whole job is to copy data between them.
• Every packaged demo ends with "we'd just need a workaround for…" — and there are five of those.
• Your compliance or reporting needs are specific to South Africa in ways global tools don't respect.

That last point matters more here than most places. A tool built for a generic global market will treat PAYE, UIF, SDL, ETI, B-BBEE and POPIA as edge cases. For a South African business they're not edge cases — they're Tuesday.

The middle path most people miss

It's rarely all-or-nothing. The strongest setups we build are custom where it counts, packaged where it doesn't — a bespoke core that handles your real workflow, connected cleanly to the standard tools you already trust for accounting, payroll or comms.

This is exactly why our own products — TalentFlow, PeopleCore, FlowChat and LearnHub — exist as products and as foundations we extend. You get the speed of something already built, with room to shape it to how you actually operate.

The questions to ask any builder

If you do go custom, the vendor matters as much as the decision. Ask these before you sign anything:

• Who owns the code? If the answer isn't "you," walk away. You should own what you pay to build.
• What happens if you disappear? Good builders hand over documentation and access as a matter of course, not as a hostage negotiation.
• Who answers the phone in 18 months? The people who built it should be the people who support it.
• What does "done" look like? Scope creep kills projects. Agree the first version's edges before you start.

So — build or buy?

Buy when the problem is common and solved. Build when the process is your edge and nothing fits. Combine the two when you're honest about which parts are which. And whatever you choose, start from the workflow, not the wishlist.

That's the whole framework. It's not complicated — it's just easy to skip when you're excited about software. The companies that get it right are the ones that slow down for one afternoon at the start.