More candidates than ever. No more certainty than before.
Hiring got faster, cheaper and almost completely automated. It did not get any better at telling you who can actually do the job. We think that’s a data problem, and more precisely a problem about who owns the data and what it was trained on.
A market only works if every side wins. Here’s the honest ledger.
Most hiring platforms quietly take from one side to please another. Candidate data sold to please employers, recruiter margins squeezed to please buyers. That works until the side being taken from notices. We’d rather write down what each side gets and be held to it.
Companies
You get the recruiter who has actually placed your role before, not whoever on a bench is free this week, and the hiring data you generate stays your asset rather than a vendor’s.
- →Sourcing within the hour, shortlist in 48, ranked with reasons
- →Your talent graph, owned and exportable
- →90-day guarantee on every placement
Recruiters
The hardest part of recruiting isn’t recruiting. It’s finding clients. Mandates arrive in the workspace you already use, and the track record you build travels with you.
- →Live mandates without business development
- →Payout on every placement
- →Contract work when you perform
Candidates
You are screened once, properly, by someone who knows your field, and what they learn represents you afterwards instead of dying in an inbox.
- →Evidence, not a keyword match
- →You control who ever sees it
- →Never charged, on any line
In markets like ours, the signal is buried, so the data is worth more.
A single engineering role in India can draw two thousand applications in a week. Almost every CV is optimised, many are embellished, and the honest ones are indistinguishable from the rest at a glance. Volume like that doesn’t create clarity. It destroys it.
Then add the part global tools genuinely do not understand. What a title means at a services company versus a product company. Which tier-two colleges quietly produce better engineers than the famous ones. What a ninety-day notice period actually predicts. Which CTC jumps signal a rocket and which signal a flight risk. That knowledge exists in the heads of recruiters who have placed a thousand of these roles, and almost none of it is written down anywhere a system can use.
Which is why the valuable record isn’t the resume. It’s the outcome: who was screened and rejected and why, who reached offer and declined, who joined and was still there at eighteen months. That data is generated every day by every recruiting team in the country, and almost all of it is thrown away, or worse, absorbed into a vendor’s database and sold back as an industry benchmark.
Our position is simple. In a market this noisy, structured outcome data is the only durable advantage in hiring, and it should belong to the people who generated it.
You don’t pay us to build your model. You build it by working.
All of that is theory until you can see where the data comes from. It doesn’t come from a survey, a data-entry project or a migration. It comes from the work your team was doing anyway. Every screen, every rejection, every offer, recorded once and kept in a structure a system can actually use.
The brief's real must-haves, as opposed to what the JD said.
Who was screened, and the honest reason they didn't move forward.
What the hiring manager actually rejected on, in their own words.
Offer accepted or declined, and which competing offer won.
Who joined, from which source, found by which recruiter.
Still there at 90 days. Still there at eighteen months.
Time from brief to shortlist, and where each search stalled.
Which profiles keep failing at the same interview stage.
None of this is extra admin. It is the exhaust of doing the job properly, captured once, structured, and kept. You are not paying us to assemble a dataset for you; you are generating it as a side-effect of hiring, and it stays yours.
The graph already holds people your team has met, screened and formed a view on. The next search opens with candidates instead of a blank query.
Your rejections teach the system more than your hires do. Fit scoring stops reflecting the market's idea of a good engineer and starts reflecting yours.
Enough outcomes to see which profiles are still there at eighteen months in your company, in your market, and to warn you before you repeat a hire that did not work.
At that volume the history is worth training on. A small model, yours alone, running inside your own environment, and you never paid a line item for the data that made it.
Your best recruiter leaves, and ten years of judgment about your market walks out with them. The hiring manager who knew exactly why the last three backend hires didn’t work moves to another team. There’s a reorg, an agency swap, a tooling migration. Hiring doesn’t stop for any of it. It just forgets, and quietly pays for the same lesson again.
That is the real case for owning this data, and it isn’t compliance. It’s continuity. The institution hires continuously; the individuals rotate. The memory has to belong to the company, in a form the next person can actually use on their first week, rather than sitting in a departing recruiter’s head or in a vendor’s database you rent access to.
Hiring that remembers
A new recruiter is productive in days rather than quarters, because the context is in the system rather than in someone’s head.
- →Searches open warm, not empty
- →Scoring tuned to your bar, not the market’s
- →Retention signal, not just placement count
A record that travels
Your placements, screen quality and how long your hires stayed become a track record you own, instead of a story you retell at every new client.
- →Mandates matched to what you’ve placed
- →Contract work won on evidence
- →Reputation that doesn’t reset
Screened once, understood after
The effort you put into one honest screening conversation stops evaporating the moment that role closes.
- →No retelling your story to every agency
- →Considered for roles you’d never have seen
- →Consent travels with the record
A model trained on everyone’s hiring knows nobody’s bar.
The large models are extraordinary generalists. They have read the internet, and they will happily tell you what a good backend engineer looks like, in the aggregate, averaged across every company that ever wrote a job description.
But nobody hires in the aggregate. Your bar is specific, and it is encoded in decisions your team already made: the candidate you rejected who looked perfect on paper, the unconventional one you took a chance on who became your best hire, the profile that keeps failing at the same interview stage. A general model has never seen any of that, and cannot.
A small language model, trained only on your own hiring history, is a different proposition. It is cheap enough to run continuously, small enough to deploy inside your own environment, and, the part that matters most in recruitment, private by construction. Candidate data is sensitive and increasingly regulated. Shipping it to a shared model that also serves your competitors is a problem you eventually have to answer for.
That is the architecture we are building toward, and it is why we made an unusual choice early: your data stays yours, isolated, exportable, never pooled. Not as a privacy feature, but as the precondition for the model to be worth anything.
Four rules we build against.
Every product decision gets tested against these. When a feature would make us money but break one of them, it doesn’t ship.
Evidence before pipeline
A candidate should be understood before they are moved. Screening, consent and scoring happen first, so a name arriving in a pipeline already carries the reasoning that put it there, rather than a stage label and a shrug.
Consent is structural, not a checkbox
Candidate data enters a workspace because someone agreed to it, and that agreement travels with the record. This is harder to build and it slows some things down. It is also the only version of this business we're willing to run.
Software remembers, humans decide
We automate the remembering: the follow-up, the context, the reason someone was rejected in March. We do not automate the judgment. A model that ranks candidates should show its reasoning to a person who can overrule it.
You own what you generate
The graph you build is yours: not pooled with other customers, not resold as market insight, not used to train a model your competitors also get. Exportable in full, whenever you want, including on the way out.
A hiring market that runs on proof instead of claims.
We started with the unglamorous part, actually filling roles, well, for real clients, because a thesis nobody has tested is just an opinion. Here’s the arc.
One network, every way to hire
A live network of specialist recruiters, our own expert team, and the system all of it runs on. Roles reach people who have placed them before.
Portable proof for recruiters
A recruiter's placements, screen quality and retention become a record they own and carry, so reputation stops resetting every time they change clients.
Candidates represented by evidence
A profile that carries real work and screening context instead of keywords, that the person controls, and that gets stronger every time it is used.
Your own model
A small language model trained only on your hiring history, running inside your own environment, encoding your standard for a good hire and no one else’s.
Recruiters and engineers, in the same room.
Proverse is built by people who have run the desk, not only people who have modelled it. Every part of the product exists because a search went wrong somewhere and we wanted it not to happen again.
Sudarshan Singh
FounderBuilds the product and runs the desk. Started Proverse after watching good roles fail for reasons that were entirely fixable, and entirely invisible to the software involved.
Delivery
Expert recruiting teamSpecialist recruiters who run client searches end to end across engineering, product, data and go-to-market.
The network
Independent specialistsVetted independent recruiters and boutique agencies, admitted on placement history, working live mandates inside Proverse OS.
All of that has to run on something. So we built it.
Proverse OS is the recruiting system underneath everything on this page, the one our own team runs on, the one the network works inside, and the one you can run your desk or your hiring function on. We’re opening it in stages.
- Your talent graph. Every screen and outcome, owned and exportable
- Private deployment. Your environment, your region, on Enterprise
- Mandate routing. Reach the network when your own desk can’t
- Your model, next. Trained on your history, for you alone