Straight answers, no sales fog.
Why custom, and why not an off-the-shelf ATS or SaaS?
Rented software makes you bend to it, charges per seat forever, and parks your data on someone else's servers. A custom system is shaped to how your team actually works, runs on the Microsoft 365 or Google Workspace you already have (or your own hosting if you'd rather not touch either), and is yours.
How is this different from a sales CRM like HubSpot or Pipedrive?
They're built to push one lead toward one sale. Recruitment is two-sided: you track clients and a large pool of candidates, and the same candidate gets reused across roles for years. Generic sales CRMs have no real candidate model, so teams bolt one on with custom fields and it gets messy fast once the desk grows. This is built around the candidate side from the start: searchable database, AI matching, pipeline by stage, profiles with documents. If most of your value sits in your candidate database, a sales CRM will always feel like the wrong shape.
Is this an alternative to Zoho Recruit or Bullhorn?
It's a different trade-off, not a feature-for-feature clone. Zoho Recruit and Bullhorn are mature and ready on day one, and rented: you pay per seat forever and your data sits on their servers. A custom build is shaped to exactly how your desk works, runs in your own environment, and is yours with no seat fees. If an off-the-shelf ATS already fits your process and the seat cost doesn't bother you, I'll tell you to stay on it. Custom is for when the process never quite fits and the seat bill keeps climbing. And on cost: for a desk of eight or ten, the monthly here lands close to what those platforms charge in seats. The difference is what you're left with at the end: with them, a subscription; here, a system you own.
What happens when a regulation or my process changes?
With a big vendor, your request waits in a queue behind ten thousand other customers, and most of the time it never ships or it's parked on next year's roadmap. Because your system is built for you, when a law changes (EU AI Act, pay transparency) or your desk changes, I adjust it in days, not quarters. Fast to change, but documented and yours, so fast doesn't mean fragile.
Can you integrate LinkedIn and job boards?
Job boards, yes, usually through a multiposting aggregator (Broadbean, Idibu) so you post once and applicants flow back into the CRM. LinkedIn is more limited and I'll be straight about it: deep candidate-database integration is locked to large ATS partners, so LinkedIn posting and applications route through that same aggregator, or an "Apply with LinkedIn" button on your careers page. I won't build a scraper that gets your LinkedIn accounts banned. Microsoft (Outlook, Teams, Calendar, SharePoint) integrates natively, and so does Google (Gmail, Calendar, Drive, Meet) if that's your stack. Whichever you run, that's the home ground.
Is this an ATS or a CRM?
Both, and that's the point. An ATS tracks candidates, applications and jobs; a CRM tracks clients and business development. Most agencies rent one, bolt the other on, and retype between them. What I build is a single custom system that does both, shaped to your desk and owned by you, on the Microsoft 365 or Google Workspace you already pay for.
Do you work with automotive recruitment agencies specifically?
Yes, it's the niche I know best. The system ships with fields, stages and workflows shaped to an automotive desk (main dealer, OEM, aftermarket, EV, the role types and clients you actually deal with) instead of generic SaaS fields you'd have to bend. If you're outside automotive I still build; the difference is how much comes pre-shaped versus scoped from scratch. More on the automotive build →
What about healthcare and care staffing?
Yes, and it's personal ground: my longest-running client today is in Swiss home care. For healthcare builds I work with a domain advisor who spent fifteen years inside Swiss healthcare, including hiring for a care home, and works in German and Italian. Healthcare staffing is where the compliance side of a system earns its keep: registrations, certificates and permits expiring on their own schedules, tracked automatically instead of in a spreadsheet.
Do I actually own it? Isn't Microsoft 365 just another lock-in?
Yes, you own it. It runs on your own Microsoft 365 (or Google Workspace, or your own hosting), and you get the source code, the schema, the documentation and all your data on day one, in your own repository. If we stop working together tomorrow, the system keeps running and another developer can pick it up cold from the docs.
And M365 itself isn't a trap: you already pay for and run it regardless of me. The CRM rides on infrastructure you'd keep anyway, and your data sits in your own environment, in open, standard formats you can export and rebuild against yourself, at zero cost. No renewal leverage over you. One more thing nobody mentions: most "Microsoft-based" recruitment systems are built on Dynamics 365 or Power Apps premium, which quietly adds £15–50 per user per month in Microsoft licences. Google has the same trap: build it on AppSheet and you're back to a per-user bill. I build on the APIs and licences you already pay for, so there's no per-seat surcharge, not to me and not to Microsoft or Google.
Compare that to Bullhorn / Vincere / a generic ATS: your data lives on their servers, the export format is proprietary, and every seat keeps billing, year after year. Migration off costs €20-50k and 6 months of chaos, which is why almost no firm ever leaves once they're on. Custom on your own environment is the opposite trade-off: more upfront work, zero lock-in afterwards. Honest comparison →
And M365 itself isn't a trap: you already pay for and run it regardless of me. The CRM rides on infrastructure you'd keep anyway, and your data sits in your own environment, in open, standard formats you can export and rebuild against yourself, at zero cost. No renewal leverage over you. One more thing nobody mentions: most "Microsoft-based" recruitment systems are built on Dynamics 365 or Power Apps premium, which quietly adds £15–50 per user per month in Microsoft licences. Google has the same trap: build it on AppSheet and you're back to a per-user bill. I build on the APIs and licences you already pay for, so there's no per-seat surcharge, not to me and not to Microsoft or Google.
Compare that to Bullhorn / Vincere / a generic ATS: your data lives on their servers, the export format is proprietary, and every seat keeps billing, year after year. Migration off costs €20-50k and 6 months of chaos, which is why almost no firm ever leaves once they're on. Custom on your own environment is the opposite trade-off: more upfront work, zero lock-in afterwards. Honest comparison →
Where does the AI run, and is our candidates' data safe?
Everything stays inside your own environment, under the security and compliance you already have; nothing is copied out to a third-party SaaS. The AI runs there too (Azure OpenAI on your Microsoft 365, or an equivalent model endpoint you control on Google Workspace or your own hosting), so candidate CVs and IDs are processed under the GDPR controls you already have, not shipped to a vendor's model. AI does the busywork (reads CVs, drafts summaries and messages); a person makes every decision and nothing is sent automatically. Built GDPR-aware from the start.
How many candidates can the system actually handle?
Three tiers, depending on your size. The record numbers below describe the Microsoft 365 build pattern; on Google Workspace or a standalone box the same tiering logic holds, the database layer just takes over sooner.
Up to ~30,000 records: SharePoint-native, comfortable, fast. The default build pattern (Vorentis runs 25,000+ smoothly).
30,000–100,000 records: Hybrid setup. SharePoint stays for workflow and UX, a Swiss-hosted PostgreSQL layer handles candidate search and document index. Same look-and-feel, more horsepower underneath.
100,000+ records: Full custom platform: Swiss-hosted PostgreSQL as the source of truth, M365 as the workflow + UX layer, semantic search and analytics built in. Different scope (€35k–80k+), different timeline (3–5 months), and an honest "do you actually need custom?" conversation, because at that scale Bullhorn or Vincere might serve you better if you're happy locking into a SaaS.
Up to ~30,000 records: SharePoint-native, comfortable, fast. The default build pattern (Vorentis runs 25,000+ smoothly).
30,000–100,000 records: Hybrid setup. SharePoint stays for workflow and UX, a Swiss-hosted PostgreSQL layer handles candidate search and document index. Same look-and-feel, more horsepower underneath.
100,000+ records: Full custom platform: Swiss-hosted PostgreSQL as the source of truth, M365 as the workflow + UX layer, semantic search and analytics built in. Different scope (€35k–80k+), different timeline (3–5 months), and an honest "do you actually need custom?" conversation, because at that scale Bullhorn or Vincere might serve you better if you're happy locking into a SaaS.
What if you're ever unavailable?
Fair question for any small, independent studio. Three things protect you:
Full documentation, delivered with the system. From day one you get the complete source code, schema, integration notes, deployment guide and runbook, everything another developer needs to take over cold. It lives in your own repository, not mine.
Your system runs in your own environment, not on my server. If we're ever out of the picture, your system keeps running. No vendor lock-in, no service that goes dark.
For 30+ day unavailability your contract includes a clean termination option with no penalty, and I maintain working relationships with peer developers on the same stack who can step in for support continuity if needed.
Continuity risk is real with any small vendor. The answer is code escrow from day one, full documentation that another developer can actually use, and a documented handoff path baked into the contract, not pretending the risk doesn't exist.
Day to day: support comes with a guaranteed response time on working days. And because it's a standard, well-documented stack (Microsoft, Google, or plain web) with full handover documentation from day one, keeping it healthy doesn't have to depend on one person's calendar.
Full documentation, delivered with the system. From day one you get the complete source code, schema, integration notes, deployment guide and runbook, everything another developer needs to take over cold. It lives in your own repository, not mine.
Your system runs in your own environment, not on my server. If we're ever out of the picture, your system keeps running. No vendor lock-in, no service that goes dark.
For 30+ day unavailability your contract includes a clean termination option with no penalty, and I maintain working relationships with peer developers on the same stack who can step in for support continuity if needed.
Continuity risk is real with any small vendor. The answer is code escrow from day one, full documentation that another developer can actually use, and a documented handoff path baked into the contract, not pretending the risk doesn't exist.
Day to day: support comes with a guaranteed response time on working days. And because it's a standard, well-documented stack (Microsoft, Google, or plain web) with full handover documentation from day one, keeping it healthy doesn't have to depend on one person's calendar.
We just have spreadsheets and years of old CVs. Worth changing?
That's the usual starting point, and the usual first project. The first step is deliberately small: a useful first version in weeks, not months, at a number agreed before anything starts, delivered in steps you can see and approve rather than one big reveal. Your team places more and hunts less.
The old CVs come along too. We extract them (PDFs, Word, scans, and ZIP exports from old ATSes) into structured, searchable records inside your CRM. A 20,000-CV archive typically runs in 3 to 5 days, standalone or bundled into the build. And it starts with a feasibility study on your real files: if they can't be brought to the agreed standard, the study is free. See Archive Unlock.
The old CVs come along too. We extract them (PDFs, Word, scans, and ZIP exports from old ATSes) into structured, searchable records inside your CRM. A 20,000-CV archive typically runs in 3 to 5 days, standalone or bundled into the build. And it starts with a feasibility study on your real files: if they can't be brought to the agreed standard, the study is free. See Archive Unlock.