Every advert you run makes the next one easier
Posting is one feature of a database that compounds. Last year’s near-miss is this year’s placement, and the AI finds them.
A posting layer, bolted on
IdibuTwo licences for one workflow, and last year’s near-misses age out of the pool you were building.
The database compounds
Semantic search reads meaning, so a near-miss surfaces against a different brief.
A posting tool is not a talent pool
Every agency ends up treating whatever holds the applications as a database it can come back to. That is the whole value of last year’s advert: the eleven people who were nearly right. A twelve-month default retention policy quietly removes exactly that, and you find out when you go looking.
Recruitly keeps them. Search, AI matching and re-engagement campaigns all run over the whole history, because the history is the point.
One system, and it keeps everything
Idibu is a layer that posts jobs out of the CRM you already pay for. Recruitly is the CRM, and the posting is part of it.
The database is permanent
Candidates, applications and the history against them stay until you delete them. There is no retention policy quietly ageing out last year's applicants, because the database is the product rather than a by-product of posting.
Distribution is included
Posting to 50+ boards is part of creating the job, not a separate licence sitting alongside your CRM. You keep your own board contracts and credits — what disappears is the layer in between.
Export whenever, free
Your data is exportable at any time, at no charge, without a termination clock running. We would rather you could leave easily than have to argue about it later.
AI does the first pass
Multiposting creates volume, and volume needs triage. Applications are deduplicated on arrival, screened and scored against the job, so the shortlist is waiting rather than the inbox.
You are already paying for a CRM
Idibu has no client records, no placements, no fee stages and no invoicing. Their own product page describes managing the posting process from inside your CRM. So the licence is never the whole bill — there is always a Bullhorn, Vincere or Access line beside it, doing the half Idibu does not.
Your CRM licence
Records, placements, invoicing
Idibu licence
Posting and applicant filtering
Job board contracts
Billed by the boards (clause 3.1)
Recruitly
The first two, in one plan
Recruitly vs Idibu
One is a posting layer bolted to a CRM you also pay for. One is the CRM.
| Post to multiple job boards | Included | Yes |
| Applicant tracking system | Included | — |
| Client and contact CRM | Included | — |
| Placements, fee stages and invoicing | Included | — |
| Applicant data retention | Permanent, until you delete it | 12 months by default (clause 7.4) |
| Needs a separate CRM alongside it | No — it is the CRM | Yes |
| Telephony, WhatsApp and e-signature | Included | — |
| AI matching and application review | Included | — |
| Data after you leave | Export any time, free | Removable after 30 days |
| AI meeting assistant in Zoom, Teams, Meet and Webex | Built in. $1.50 an hour, notes on the record | — |
Source: ww2.idibu.com/terms and ww2.idibu.com/pricing, 9 August 2026. Bands above five seats are not published, so none is quoted here.
Questions before you move
Can Recruitly replace Idibu for multiposting?
Yes, and it replaces the CRM the Idibu licence sits next to at the same time. Recruitly posts natively to over 50 job boards including Indeed, Reed, CV-Library, Totaljobs and JobServe, with per-board field mapping and scheduling, and applications arrive directly on the job as candidate records. Because posting is part of the system that holds the job, there is no integration between two vendors to configure or debug.
Is it true that applicant data is deleted after twelve months?
That is what their terms say. Clause 7.4 states a default data retention policy of twelve months on processed data relating to posted jobs and applicants. Whether it is enforced on your account is a question for them, and we would encourage you to ask it directly rather than take our reading of it. The reason we raise it is that agencies routinely treat a posting tool as a talent pool, and a twelve-month default is incompatible with that. In Recruitly the database is permanent.
Do I still need my own job board contracts?
Yes, with either product, and that is normal. Idibu's clause 3.1 puts board fees on the client, and Recruitly works the same way: you keep your own rates, credits and relationships and we post using your credentials. What you stop paying for is the middleware, not the boards.
What happens to the applicants I do not place?
They become the most valuable thing you own. Every applicant stays on your database with the advert, the source and the whole history against them, and semantic search reads meaning rather than keywords — so somebody who applied for a warehouse supervisor role last year surfaces against a logistics team leader brief this year. Re-engagement campaigns, MPC campaigns and AI matching all run over that history. An advert is not one placement; it is a talent pool you keep buying into.
What else do I get that a posting layer cannot give me?
Nineteen modules around the advert: jobs, candidates, applications, contacts, companies, deals, placements, billings, interviews, campaigns, WhatsApp, telephony, e-signature, analytics and an AI hub. Plus a Chrome extension that captures and enriches every LinkedIn, Sales Navigator and Recruiter search result, matches profiles against your live jobs, and tells you which of your colleagues already knows the person you are looking at. A multiposter can post the job. It cannot run the desk.
How do I move without losing anything?
Start the export before you terminate, because clause 7.4a lets Idibu remove client data thirty days after the contract ends. Take delivery of the file while the account is live, then close it. On our side a migration specialist runs a two-stage process with a sample export on day 1, sign-off on day 5, validation of 100 records per module on day 12 and the full load on day 14, followed by a parallel run before go-live.