Should a recruitment agency build its own software?

This question arrives at agencies in a predictable way. Something in the current system does not fit, a developer is available or already on the payroll, and a prototype appears that does the annoying thing beautifully. The prototype is usually genuinely good, which is exactly why the conversation goes wrong from there.

I am an engineer, so my bias should be obvious, and it runs the other way from what you might expect. The part of software that is hard is not the part you would be building. It is everything around it, and that part never finishes.

What are you actually committing to when you build?

You are committing to a permanent obligation rather than a project, because software that people depend on has to be kept alive by someone for as long as it is used. The feature is a few weeks. Keeping it working through browser changes, operating system updates, library security patches, an email provider changing its rules and a supplier retiring an interface is the rest of its life.

Alongside that sit the parts nobody scopes and everybody needs. Sign-in and sessions. Permissions, so a consultant cannot see another desk's records. An audit trail, because a client questionnaire will ask for one. Backups that have actually been restored rather than merely configured. Deliverability, so your email arrives. Something usable on a phone. A way to change things without breaking last month's data. Each of those is ordinary work and all of them together are most of the work.

The visible feature is the small box in the middle. Estimates go wrong because the person estimating is looking only at that box, and they are not being dishonest, they are answering the question that was asked.

The person who built it will leave

Every piece of agency-built software eventually belongs to nobody, because the developer who wrote it moves on and the understanding goes with them. This is the single most common way these projects end, and it does not require anyone to behave badly.

What is left behind is a working system that nobody can safely change. A small request turns into an exploration, then into a risk assessment, then into a decision to leave it alone. The tool carries on running and quietly stops improving, which is fine right up until a supplier changes something and it stops running instead.

If you build anything, plan for this from the first week. Write down how it works in a place that is not a person's head, keep it in version control the agency owns rather than a personal account, and make sure at least two people can deploy it. That is not a large amount of discipline and it is the difference between an asset and an orphan.

When building is the right answer

Building is right when the thing you want is specific to how your agency wins work and no vendor will ever prioritise it. That is a narrow description and it does exist. A pricing model nobody else uses, a client-specific reporting pack you are contractually obliged to produce, a compliance step unique to your sector, or a join between two suppliers that only you have.

The right shape for that work is a thin layer on top of a system you bought, reading and writing through its interface rather than holding its own copy of your data. You get the specific thing you need, the vendor keeps carrying the sign-in, the permissions, the backups and the mobile app, and if your layer breaks on a Tuesday your agency still runs.

Before you start, ask your vendor two questions: is there a documented interface with everything I need in it, and does it change without notice. A good answer makes this a sensible project. No interface, or one that shifts underneath you, makes the same idea a trap.

What building your own CRM outright actually costs

The cost is not the build, it is the years, and the honest way to compare is to put both options over five years. On the build side that means a developer or an agency, at their real cost, for as long as the software lives. Hosting, email sending, telephony, storage and AI usage, which you will now buy directly. The time your own staff spend specifying and testing. And the cost of the things you will not get around to, since a small internal team ships one thing at a time, and while it builds a texting feature it is not building reporting.

Then add the risk of being the only user. A commercial product gets the errors of thousands of agencies found for you. Yours gets found by your consultants, in front of clients, and the fix waits for one person's availability.

Very few agencies would write a cheque for that consciously, and most who end up there did so a step at a time, starting with a prototype that worked.

Approach	Good for	Real cost	How it usually fails
Build the whole system	Almost nobody	A permanent engineering team	Runs out of capacity, then out of people
Build a layer on a bought system	A genuine edge nobody else has	Small, ongoing, contained	Undocumented, owned by one person
Configure what you bought	Most agency-specific needs	An hour a fortnight, one owner	Owner gets busy, config goes stale
Ask the vendor to build it	Anything other customers also want	Free, plus waiting	Never asked in the first place

Before you build anything, exhaust the cheaper routes

Three things sit between you and a build, and each is an order of magnitude less expensive. Configuration comes first, because a surprising share of what agencies try to build turns out to be a setting, a template or a report nobody had set up. Second is asking the vendor, in writing, with the reason and the size of the problem, since vendors build what customers ask for and most customers never ask. Ours ships every week and publishes a dated public changelog, so it is easy to check whether asking leads anywhere.

Third is spending the money on the join rather than the tool. Where two systems you are keeping do not talk, a small amount of work on the join removes the retyping without adding a product to maintain. That is the highest-return engineering an agency buys and it is rarely the one that gets proposed, because it is not exciting to demonstrate.

A rule of thumb

Build what makes you money in a way nobody else does, and buy everything that simply has to work. Authentication, permissions, telephony, email sending, documents, storage and the mobile app are things that have to work, and every hour your developer spends on those is an hour not spent on the thing only your agency needs.

My own view, from the inside of this work, is that the best internal software at an agency is usually about two hundred lines long, does one job that matters to that business, and sits on top of a system somebody else keeps running. Agencies that build that do very well out of it. Agencies that build the platform underneath it end up employing a software company by accident, and it is a harder business than recruitment with worse margins.

---

Siva is an engineer at Recruitly.