If you’re a finance director or a CEO choosing who builds your next system, you’re at a disadvantage, and everyone in the room knows it. The vendors speak a language you don’t, the proposals all look competent, and the easiest thing to compare is price. So price wins — and a year later you’re explaining to the board why the system is half-finished.

You don’t need to become technical to choose well. You need to ask a few questions that are hard to fake, and to know which reassurances are worthless. Here’s what we’d want a client to ask us.

Ask who will actually write your code

A lot of firms sell with their seniors and deliver with their juniors. The experienced people you met in the pitch move on to the next sale, and your project quietly lands with whoever is free. The work suffers, but you don’t find out until it’s late.

So ask directly: Who, by name, will be on my project, and what else are they working on? A serious partner can answer that and won’t flinch. Be wary of any firm whose answer is essentially “our team” — that usually means a rotating cast and no single person accountable for whether your system works.

Understand that the day rate is not the price

The cheapest quote is rarely the cheapest project. Cheap usually means junior developers, thin testing, and no real plan for after launch — and you pay the difference later in delays, defects, and a system that needs rescuing. We’ve been called in to fix “finished” projects that ended up costing more than building them properly once.

What you actually want to know is the total cost of getting to a working, maintained system — build, plus data migration, plus training, plus support through the first months when things break. A partner who only talks about the build cost is quietly leaving the expensive parts off the invoice so the number looks good today.

Check references for one specific thing

Anyone can show a polished portfolio. When you call a reference, don’t ask whether they were “happy.” Ask the question that separates real delivery from theatre: Did it go live, is it still running, and what happened when something broke?

That’s the whole game. Plenty of projects look great in a demo and never make it into daily use. The firms worth hiring have clients whose systems have been quietly working for years — and who’ll tell you the vendor stuck around when there was a problem instead of going quiet.

The red flags

A few signals reliably predict trouble:

  • Vague scope, confident price. If they can quote a firm number before understanding your problem, the number is fiction and the change requests are coming.
  • No questions about your business. Good partners spend the first conversations trying to understand how you actually work. If they’re only talking about technology, they’ll build the wrong thing efficiently.
  • No mention of what happens after go-live. Silence here means they consider launch the finish line. You’ll be on your own at the worst moment.
  • No straight answer on data protection. Under the Kenya Data Protection Act, how they handle personal data is your liability too. A shrug is disqualifying.
  • They never say no. A partner who agrees to every request, including the bad ones, is selling you, not advising you.

When you shouldn’t hire a firm like ours

Honesty cuts both ways, so: if your need is genuinely common — standard accounting, a simple website, basic email — you don’t need a custom partner. Buy the off-the-shelf product and save your money. We’ve told prospects exactly that, and we’d rather lose the deal than sell you something you don’t need. Buy versus build is its own decision, and the right answer is often “buy.”

A custom or ERP partner earns their fee when the system is central to how you operate, when off-the-shelf can’t fit without painful compromise, or when getting it wrong is genuinely costly. That’s the work where delivery certainty is worth paying for.

If that sounds like your situation, tell us about it. And ask us the hard questions above — we’d think less of you if you didn’t.