{"slug": "we-built-our-own-hiring-platform-and-ate-our-own-dog-food-in-the-process", "title": "We built our own hiring platform (and ate our own dog food in the process)", "summary": "Pagelove founder built a custom applicant tracking system (ATS) using Claude Code and Pagelove, replacing a planned Greenhouse subscription that would have cost thousands of dollars annually. The MVP was created in under 30 minutes in May, and iterative changes—such as adding a kanban view and integrating Postmark for email—took minutes each, allowing the tool to adapt to their hiring process over three months. The founder documented the process, including challenges like CV uploads, to test Pagelove's own platform before its beta release.", "body_md": "# How we built our own hiring platform (and ate our own dog food in the process)\n\nThe first challenge of any company is raising money, whether through funding or sales. Then, if you're ambitious, comes scaling. AI has changed what that looks like forever, but you still normally need to hire a few awesome people, and we're no different.\n\nHiring takes coordination. You need to post the ad, receive and store applications, screen CVs, record interview notes, and get back to candidates with news. For that you generally need a hiring platform, usually known as an ATS.\n\nWe were going to use Greenhouse, who make a good product that I genuinely like, but they wanted thousands of dollars a year. Up until now in history I'd have paid it, on the old logic that you should focus on your core business and not build what you don't sell.&span>\n\nBut given what Claude Code can now do and how Pagelove is forever changing product development, I thought I'd be thrifty and eat our own dog food at the same time.\n\nOur pitch to vibe coders like me is that you don't need an engineer to build, deploy and iterate your own products. This is me testing that on myself, warts and all.\n\n## May: the MVP\n\nThe first version took me less than half an hour, including onboarding onto Pagelove, which I also wanted to test properly as we got ready for opening our doors to beta testers.\n\nI added the Pagelove skill to Claude Code and mounted the WebDAV host, a flow we've since changed. Then I described what we actually needed: post a role, collect applications, move people through stages, keep notes against them. Basic applicant tracking, not sourcing or scheduling or scorecards.\n\nFifteen minutes later I had something rough round the edges that genuinely worked, with roles listed, candidates added and notes recorded against each one. I also produced a very first version of what a public application page could look like, but didn’t put it live!\n\n## May to now: iteration\n\nLike any product, especially one vibe coded in an afternoon, the first version just sets the scene. The fun part, and where Pagelove changes the game, is how easily you can keep changing it afterwards. Once you’ve shared your Pagelove API key with Claude, you can just describe the change to the product and it handles everything else, you just need to refresh the page.\n\nAs we’ve matured our own hiring processes, we’ve been able to adapt our ATS to meet our needs, something that simply wouldn’t have been possible with an off the shelf product – instead we would have been adapting our process to their product. When I wanted to add a section on “how we hire” for all roles – easy, takes 3 minutes…\n\nWhen I wanted a kanban view to see where we are at with a role, two minutes, done.\n\nConnect our Postmark account so we could email candidates from inside the tool, ten minutes…\n\nAnd each time, it’s just a conversation between me and Claude 🙂\n\nNone of those changes were big on their own. What matters is that none of them were expensive. Rather than weighing up whether a tweak was worth the effort, we just made the change. Otherwise, every one of them would have been a feature request on someone else's roadmap, and most would never have happened at all.\n\nThree months in and the tool looks nothing like the one I built in May. It has adapted to what we actually do, rather than us drifting towards what the tool allows.\n\nIt hasn't all been smooth, though…\n\n## Warts and all\n\nI didn't expect it to work perfectly and it didn't, which was half the point, because we want to hit our new platform's own rough edges before our future users do.\n\nThe first hurdle I hit was CV upload. The first solution was around using links to candidates’ personal drives, which felt a bit too MVP for me – but fixing it wasn't something I could do on my own, because storing PDF files wasn't something we'd thought properly about yet.\n\nThe answer, from Sam, was that anything the document layer doesn't need to understand passes through to object storage underneath, so the capability was already there and just needed surfacing. Applicants now drop a PDF or a Word file straight onto the form and into our storage engine.\n\nThat's the difference between using a product and testing one. Testing checks the things you already decided to build. Using it finds the things you never thought of.\n\nAnd even once it was fixed, sometimes things break (which as we all know is the issue with non-deterministic AI development) – but the big difference is how easy and quick it is to fix…\n\nDogfooding produced a bunch of other questions we needed to think about for our platform:\n\n-\nAuthorisation rules with selectors not being enforced on writes\n\n-\nA missing client ID breaking the login redirect\n\n-\nA 403 that told you nothing about how to log in\n\n-\nA tool that silently truncated files\n\n-\nPDFs coming back with the wrong content type\n\n-\nA module import that killed an entire script without saying so\n\nI sent that bundle to James and Sam two days after the first build, and James came back the next day with a theory on the content-type one, that the file was being sent as a form upload rather than a PUT. None of those were in the ATS. They were in the platform underneath it, which we're still building.\n\nI also hadn't yet added authentication to the internal parts of the product, which was an important step. Getting it in created a proper security layer and stopped data leaking. It also lets us test our own customer OIDC integration in anger, which is exactly the sort of thing you want to do on your own hiring rather than someone else's production system.\n\nThe big win through all of it is readability. The codebase is small enough that changes take minutes instead of days, and when something does go wrong and you need an engineer, they can see what the product is doing immediately, because it's HTML. There's no reconstructing the application in your head from five services before you can start looking for the problem. The thing you read is the thing that's running.\n\nAnd even though we’re developing at pace, there will be more use cases and edges to bump into as we, or others build – that’s why our free tier is so generous :)\n\n### The death of SaaS\n\nHalf an hour for the first version, minutes per change since, and more than $10,000 a year saved. That quote was for three seats, so it would have grown as we hire, while ours costs close to nothing and gets better as more people use it, because anyone joining can improve it themselves.\n\nThere's a whole category of software companies buy because building it used to be expensive rather than because building it was hard. An ATS is a list, some states and some emails, and so is most internal tooling: the tracker, the dashboard, the approval flow, the thing someone in ops maintains in a spreadsheet because IT said no. When building costs less than a year of licensing, the maths that justified that category stops working, and every company is about to run that sum on tools it has bought without thinking for a decade.\n\nNone of which means firing your engineers. You'd still want a couple of people overseeing how these things get built, because internal tools make or break companies and nobody wants twelve unmanaged apps quietly holding the business together. But that cost sits against a SaaS bill that is almost certainly larger, and you get something a licence never gives you: the tool you actually want, rather than the one built for the average of ten thousand other companies. Every SaaS product is a compromise between everyone who uses it, which is why you end up bending your process to fit the software. Our hiring process changed as we ran it, and the ATS changed with it the same week.\n\nThere are genuine exceptions. Anything that needs to work across organisations, Slack being the obvious one, is harder to replace because the value is in everyone else already being there. But that's a fraction of what most companies pay for, and it says nothing about the hundred internal tools that only ever talk to you.\n\nIf you're hiring at volume today, buy the tool. But notice the \"today.\" Ours already does the half of Greenhouse we'd actually use, and it got there in three months.\n\nAnd an ATS is a small example. The same reasoning applies to the CRM, the project tracker, the approval workflow, the internal dashboard nobody likes. All of them are lists, states and notifications, and all of them were bought because building was out of reach. It isn't any more.\n\nWe're hiring, through the thing [this post is about](https://ats.pagelove.com/roles/founding-software-engineer/).", "url": "https://wpnews.pro/news/we-built-our-own-hiring-platform-and-ate-our-own-dog-food-in-the-process", "canonical_source": "https://blog.pagelove.com/posts/building-our-own-hiring-platform.html", "published_at": "2026-08-19 14:34:13+00:00", "updated_at": "2026-08-19 14:44:20.979240+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents"], "entities": ["Pagelove", "Claude Code", "Greenhouse", "Postmark", "Sam"], "alternates": {"html": "https://wpnews.pro/news/we-built-our-own-hiring-platform-and-ate-our-own-dog-food-in-the-process", "markdown": "https://wpnews.pro/news/we-built-our-own-hiring-platform-and-ate-our-own-dog-food-in-the-process.md", "text": "https://wpnews.pro/news/we-built-our-own-hiring-platform-and-ate-our-own-dog-food-in-the-process.txt", "jsonld": "https://wpnews.pro/news/we-built-our-own-hiring-platform-and-ate-our-own-dog-food-in-the-process.jsonld"}}