Dispatches
rendered) stands in. -->
Log in
Start building free
How we built our own hiring platform (and ate our own dog food in the process)
12 August 2026 · Benji
The first challenge of any company is raising money, whether<br>through funding or sales. Then, if you're ambitious, comes scaling.<br>AI has changed what that looks like forever, but you still normally<br>need to hire a few awesome people, and we're no different.
Hiring takes coordination. You need to post the ad, receive and<br>store applications, screen CVs, record interview notes, and get back<br>to candidates with news. For that you generally need a hiring<br>platform, usually known as an ATS.
We were going to use Greenhouse, who make a good product that I<br>genuinely like, but they wanted thousands of dollars a year. Up<br>until now in history I'd have paid it, on the old logic that you<br>should focus on your core business and not build what you don't<br>sell.&span>
But given what Claude Code can now do and how Pagelove is forever<br>changing product development, I thought I'd be thrifty and eat our<br>own dog food at the same time.
Our pitch to vibe coders like me is that you don't need an engineer<br>to build, deploy and iterate your own products. This is me testing<br>that on myself, warts and all.
May: the MVP
The first version took me less than half an hour, including<br>onboarding onto Pagelove, which I also wanted to test properly as we<br>got ready for opening our doors to beta testers.
I added the Pagelove skill to Claude Code and mounted the WebDAV<br>host, a flow we've since changed. Then I described what we actually<br>needed: post a role, collect applications, move people through<br>stages, keep notes against them. Basic applicant tracking, not<br>sourcing or scheduling or scorecards.
Fifteen minutes later I had something rough round the edges that<br>genuinely worked, with roles listed, candidates added and notes<br>recorded against each one. I also produced a very first version of<br>what a public application page could look like, but didn’t put it<br>live!
May to now: iteration
Like any product, especially one vibe coded in an afternoon, the<br>first version just sets the scene. The fun part, and where Pagelove<br>changes the game, is how easily you can keep changing it afterwards.<br>Once you’ve shared your Pagelove API key with Claude, you can just<br>describe the change to the product and it handles everything else,<br>you just need to refresh the page.
As we’ve matured our own hiring processes, we’ve been able to adapt<br>our ATS to meet our needs, something that simply wouldn’t have been<br>possible with an off the shelf product – instead we would have<br>been adapting our process to their product. When I wanted to add a<br>section on “how we hire” for all roles – easy, takes 3<br>minutes…
When I wanted a kanban view to see where we are at with a role, two<br>minutes, done.
Connect our Postmark account so we could email candidates from<br>inside the tool, ten minutes…
And each time, it’s just a conversation between me and Claude 🙂
None of those changes were big on their own. What matters is<br>that none of them were expensive. Rather than weighing up<br>whether a tweak was worth the effort, we just made the change.<br>Otherwise, every one of them would have been a feature request<br>on someone else's roadmap, and most would never have happened at<br>all.
Three months in and the tool looks nothing like the one I built<br>in May. It has adapted to what we actually do, rather than us<br>drifting towards what the tool allows.
It hasn't all been smooth, though…
Warts and all
I didn't expect it to work perfectly and it didn't, which was<br>half the point, because we want to hit our new platform's own<br>rough edges before our future users do.
The first hurdle I hit was CV upload. The first solution was<br>around using links to candidates’ personal drives, which felt a<br>bit too MVP for me – but fixing it wasn't something I could do<br>on my own, because storing PDF files wasn't something we'd<br>thought properly about yet.
The answer, from Sam, was that anything the document layer<br>doesn't need to understand passes through to object storage<br>underneath, so the capability was already there and just needed<br>surfacing. Applicants now drop a PDF or a Word file straight<br>onto the form and into our storage engine.
That's the difference between using a product and testing one.<br>Testing checks the things you already decided to build. Using it<br>finds the things you never thought of.
And even once it was fixed, sometimes things break (which as we<br>all know is the issue with non-deterministic AI development) –<br>but the big difference is how easy and quick it is to fix…
Dogfooding produced a bunch of other questions we needed to<br>think about for our platform:
Authorisation rules with selectors not being enforced<br>on writes
A missing client ID breaking the login redirect
A 403 that told you nothing about how to log in
A tool that silently truncated files
PDFs coming back with the wrong content type
A module import that killed an entire script...