Build or buy is the wrong question

There is nothing more frustrating than pouring effort into building a solution that no-one seems to want to use.

I’ve been hearing a lot of talk lately about whether HR should be building their own employee-facing products with AI instead of purchasing something off the shelf. As someone who used to design digital products for a living I’d love to weigh in on this.

Early in my UX career, a big part of my role involved digitising manual processes. Turning spreadsheets and PDFs into a digital product that would create more efficiency or save time.

The hardest part of that activity wasn’t building the solution or even designing it, it was getting people to use what we built.

The same was true when I worked in-house in People Experience and tried to drive adoption of an off-the-shelf engagement platform.

The problem isn’t whether to build or buy, it’s how to put a solution in place that people will use and that will generate value.

So let me show you the trap most teams fall into, the options in front of you, and how to pick a performance management or engagement product you won’t be ripping out again in three years.

PREVIOUS NEWSLETTERS

In case you’re a new reader (or just missed them), here are the past few newsletters:

Reviewed by someone who never saw my work. Why the org chart shouldn’t dictate how performance reviews work.
Engagement scores tell you what people think, not what changed. Vanity metrics versus actionable metrics.
Start with the decision, not the data. Dashboards are only as useful as the questions they answer.

Great features that nobody wanted

In every company I’ve worked for, they’ve each used a different employee engagement or performance management product. But they all looked very much the same:

💬 a one-to-one feature with an agenda linked to your goals
🎯 goals split into a target and a checklist, marked on track, off track or done
📊 a capability matrix telling you what your work should look like given your level
📈 an engagement survey firing on a six-monthly cycle with pulse surveys in-between

As a people-nerd, I always loved all of these features, but it was always a struggle to get most people to use them. In one role, I did some research into why. The feedback was that these products felt rigid, like something additional to do on top of their day job, and like HR just enforcing policy through them.

No matter how good the product was, people always felt like this process was being done to them instead of with them or for them.

Most of the time it was because the product had been chosen before we had taken the time to design the experience we wanted it to create, so we were stuck with the process the product had chosen for us. In my UX work: even when we understood our users and designed the right experience, a lack of engineering capacity stopped us building it.

So should you just build your own?

This is where the “build it with AI” conversation usually lands, and I understand the appeal. If the off-the-shelf product is too rigid and it’s complex to involve software engineers to build it for you, why not spin up exactly what you need yourself?

For a small team, it can work — I shared an example from the VP of Juro previously.

The catch is that building the thing is the easy bit now. Keeping it alive and continuously improving it is another job entirely.

In my UX days, digital products were shaped by what engineering could afford to build and maintain. Now with AI in the hands of HR folks, it can be shaped by what one person can build, run and continuously improve.

The issue is, when that one person moves on, so does the thing they built.

So the cost doesn’t disappear when you build instead of buy, it just moves.

You’re also left with the original problem: people won’t use what you’ve built if it’s designed around a ‘best-practice’ template rather than an outcome for your people and business.

Which points at something bigger. Whether you buy or build, what decides if it works is the same, and it has nothing to do with which one you pick.

How to identify the right solution

It’s tempting to jump straight to “build or buy?”, but that’s the wrong question to lead with. Ask it first and you’re choosing a tool before you know what your people actually need.

The better starting question is how much flexibility your situation calls for. For a lot of teams the honest answer sits somewhere in between: not a rigid product you buy, not a tool you build from scratch, but a bit of both.

Most teams need something that provides the consistency and support of buying, with the flexibility that building would.

Here are a few questions that can help you decide:

🧩 How adaptable is your workforce? Are people able and willing to change the way they work to fit a predefined process, or does the process need to fit around them?
⏳ How much will it change? If you’re scaling, or still shaping your operating model, you’ll outgrow a fixed process quickly.
👥 How varied is it across teams? A call-centre team and a project team can need very different things when it comes to progression and performance. One template rarely fits everyone.
🧰 Have you got the capacity to build and maintain it? Not just to stand it up, but to keep improving it, and to hold onto the knowledge when the person who built it moves on.

So start with the need, not the options. Get clear on the outcome you’re actually after and how your teams already work, what’s worth protecting and what’s just friction. It’s the same instinct as choosing on the business problem rather than the tactic.

Choose a solution that will enable flexibility

If you land on buying, but you want something you can customise as you go, here are three questions worth asking before you commit:

🔀 Can the underlying workflow actually change, or only the settings? Renaming fields and flicking toggles isn’t flexible. Ask the vendor to explain how they would reshape a real process of yours.
👀 How far into the weeds will they go with you? The support matters as much as the software. A flexible tool with a vendor who won’t help you shape it just hands you a blank canvas and a problem.
🤦🏻‍♀️ What happens when your process changes next year? If the answer is that your only option is to buy a new product or request features that will likely never get built, the solution isn’t going to allow you the flexibility you might need.

This is exactly the gap Crewmojo set out to fill. Instead of handing you a template and asking you to bend your process to fit it, you design the workflow around how your team actually works: the triggers, the steps, the conversations that matter to you.

You’re not left with a blank canvas to work it out alone, either. Crewmojo’s onboarding is a guided, customised setup, with someone building your workflows alongside you if you need it, so the flexibility becomes something your people use.

What to leave with

Before you build anything, or sit through one more demo, start where we began: with the need, not the product. Do that work up front and the build-or-buy question mostly answers itself.

I’d love to know what you find. What’s the one process in your organisation that people work around rather than through? That’s usually where the real need is hiding.