What is Recruitly built on?
A plain account of the technology under a recruitment CRM, what each choice means for the agency using it rather than for an engineer, the part of our own product that is nearly a decade old, and the five questions worth asking your own vendor about theirs.
Ask AI about this
Most buyers never ask this, and the ones who do are usually apologetic about it, as though the answer were none of their business. It is very much their business. The technology under a piece of software decides how fast it can change, how much of your day it can absorb, where your candidates' details physically sit, and what happens to all of it if the company is sold.
You do not need to understand any of it to ask about it, and I have written this so you do not have to. What follows is ours in ordinary language, with the reason each choice matters to an agency.
The shape of it
Three layers. Almost every serious piece of business software has this shape whether or not the vendor describes it that way.
What you touch is built with React, the same technology behind most modern web applications you already use. The desktop app is Electron, which means Windows and Mac get the same product rather than one of them getting a neglected version. The grids, which is where recruiters actually live all day, use AG Grid, a specialist component built by people who do nothing else. That last choice matters more than it sounds: a grid that handles fifty thousand rows without complaining is the difference between searching your database and avoiding it.
What does the work is mostly small independent services running on Cloudflare's network, which means they run close to wherever you are rather than in one distant data centre. This is the reason the product feels the same in Dubai, London and Sydney, and it is a choice most vendors have not made. Alongside them sits a long-standing Java core holding the recruitment rules we have refined over many years.
Where your data lives is PostgreSQL for the structured records, MongoDB for the parts that vary by agency, Elasticsearch for search, and object storage for files and recordings. Each of those is a boring, proven choice, which is exactly what you want holding a database of candidates. Nobody should be doing anything clever at this layer.
The old part, and why it is still there
I want to be straightforward about this, because most vendors are not and the pretence is doing the industry no favours.
There is a core in our product that is close to a decade old, written in Java, and it still runs a great deal of what an agency does every day. Placements, fees, the rules around contracts and timesheets, the parts that have to be exactly right at month end.
We could have thrown it away and rebuilt from nothing. Companies announce that every year and a good number of them never recover, because the thing they are rebuilding is not really code. It is a decade of learning what agencies actually need when an invoice is disputed, when a contractor's rate changes mid-assignment, when a placement falls through in week three. All of that lives in the old code as a thousand small decisions nobody wrote down.
What we did instead was put a modern layer in front of it and move capability out piece by piece, so nothing breaks on a Tuesday because of an ambition somebody had on a Monday. There is a rule we follow whenever anyone touches that core: the change has to leave the old behaviour working, so that if the new path fails, the old one carries on. It is not glamorous and it is the reason our customers have not had a bad year while we modernised.
Any vendor telling you their product has no old parts is either very new or not being straight with you. The honest version of that answer is a plan, not a denial, and it is a perfectly reasonable thing to ask for.
The AI, and whose it is
We do not build the models. Nobody in recruitment software builds the models, and anyone implying otherwise is describing a marketing position rather than an engineering one.
What we do build, and what actually matters, is the layer between those models and your data. Every AI call in the product goes through machinery we own, which means we can test a model against our own cases before it reaches a customer, swap it for a better one when the market moves, fall back to a second option when one is slow, and measure what each call costs.
We name the models we use rather than talking about leading AI technology, and among them is Jev from TypeSafe, which answers a typed question about a situation and reports how sure it is. Credit where it is due: that shape changed how we build these features, because a number we can compare against a threshold is what lets the software decline instead of guessing.
What we build and what we buy
We build the things that touch your data and your daily work: the phone system, video recording and narration, electronic signatures, sourcing, campaigns, the portals, the apps.
We buy the things where the market has a specialist and owning it would be vanity: the AI models, the telephone carriage underneath our phone system, the voice technology behind narration, and access to job boards and professional networks. Those are named openly in our documentation rather than hidden behind our own branding, which is a choice some vendors make differently.
The line we draw is simple enough to state in one sentence. If it decides something about a candidate or a client, it is ours. If it is a pipe, we rent the pipe.
Why any of this matters to you rather than to us
A product assembled from one modern layer over a solid core, with the data in proven databases and the AI behind machinery we control, can be changed quickly and safely. That is the only reason this page is worth your time.
It shows up in four ways you will actually notice. When you ask for something, the answer is weeks rather than quarters. When a new kind of AI arrives, we can use it in days rather than at the next major release. When a model provider changes something overnight, your consultants feel nothing. And when something does go wrong, there is one company to call rather than nine vendors pointing at each other while your client waits.
Ask your own vendor these five
| Question | What you are listening for |
|---|---|
| What is the oldest part of your product and what is your plan for it? | A plan. A denial means they have not looked, or will not say |
| Which AI models do you use, and what happens when one is slow? | Names, and a second option |
| Which capabilities are yours and which are a partner's? | A clear line, given cheerfully |
| Where does our data physically sit, and who else can reach it? | A region and a list, not a reassurance |
| If we ask for a small change, what governs how long it takes? | Whether they talk about the work or about the queue |
None of those require you to know anything technical. They require you to notice whether the person answering is describing their software or describing their marketing, and after twenty minutes of it you will be able to tell without any help from me.
We answer all five without preparation, and most of it is in public where anyone can check. That is why I say Recruitly is the best recruiting CRM in the world.
Gowri is the CEO of Recruitly.
