For the last few months I've been writing about tools, judgement, and AI.
I've made two core arguments:
- Tools are leverage on judgement, not substitutes for it.
- AI makes that leverage sharper, especially for small teams, but it doesn't change the basic equation.
Smaller teams, sharper tools was my attempt to zoom in on what that looks like day-to-day: a small group of people who know a problem well, building the exact tools they need instead of buying generic software and trying to bend it to fit.
The Hatchery is one of those tools.
It's a talent explorer for the games industry that I've been building as co-founder and technical partner at Wounded Bird Games. It maps developers, skills, studios and shipped titles into a single interactive view, and it lets recruiters and teams explore that network instead of paging through yet another stack of CVs.
It also happens to be a good example of the pattern I've been talking about: a small team with deep domain knowledge, a clear sense of why this needs to exist, and a willingness to use modern tools (including AI) to move faster without giving up judgement.
This is what we learned building it.
Why we needed something different
If you've worked in games for any length of time, you know how messy talent discovery can be.
CVs and LinkedIn profiles tell part of the story, but not the whole thing. They're linear, text-heavy and often optimised for keyword scans or ATS systems, not for understanding how someone actually fits into a team or a project.
From the studio side, you have questions like:
- Who has shipped open-world games with live-ops?
- Who has done both systems design and production?
- Which studios have grown teams with strong accessibility or UX practices?
- Who is open to remote or freelance right now?
Most existing tools answer those questions indirectly, if at all. You search by job title, location, maybe one or two tagged skills. You end up with generic lists and a lot of manual work to figure out who might actually be a fit.
From the developer side, it's not much better. You are flattened into "Senior X at Y", your shipped titles are a bulleted list somewhere in the middle of a page, and you have very little control over how your skills and experience are actually seen.
The people I'm working with at Wounded Bird Games are very close to this pain. They're talking to developers every week, building community, and watching people struggle to be visible in a crowded, noisy market.
The "why" for The Hatchery wasn't "we should have a cool graph of dots". It was much simpler:
- Make it easier for developers to be seen as more than their job title.
- Make it easier for studios and recruiters to find people in a way that reflects how teams and projects actually work.
- Do it in a way that doesn't treat people's data as fuel for someone else's advertising.
Once that was clear, the shape of the tool almost fell out naturally.
What we actually built
The Hatchery is, at its core, a structured profile system and a visual explorer on top of it.
Developers submit a profile through a simple web form. They add:
- a short bio
- a video, if they want to introduce themselves in their own words
- skills and tools, from a curated list
- shipped titles, linked to studios
- work history, with start/end dates
- preferences around remote work and relocation
- whether they are open to work or open to freelance
On the front end, that data appears in two main ways:
- as rich developer profiles you can search and filter
- as a graph-based visualisation that lets you explore the network of skills, people, companies, games and locations
You can switch between views (Skills, People, Companies, Locations), filter by availability and experience, and click through to individual profiles. There's no login wall for viewing, no tracking cookies, no third-party scripts. If you want to edit your own profile, you sign in with a magic link to your email and get an hour-long session to make changes.
None of this is revolutionary in a technical sense. It's a well-structured database with a visual layer on top, wrapped in a simple product.
What makes it interesting to me is how much of it flows directly from the "why":
- If you care about people being seen as more than job titles, you give them space for a bio and a video, and you make shipped titles first-class data, not an afterthought.
- If you care about recruiters finding people in a way that matches how they think ("I need someone who's done AI design on open-world titles, is in Europe, and is open to remote"), you build search and filters around skills, games and availability, not just job titles.
- If you care about trust and community, you don't build an advertising business. You keep the data model tight, you don't sprinkle in trackers, and you make removal and edits straightforward.
That is the smaller teams, sharper tools idea in practice: opinionated choices, shaped by people who live the problem.
Where AI helped — and where it didn't
Given how much I write about AI, it's worth being specific about where it showed up in this project.
AI absolutely made some parts faster:
- drafting and iterating on copy: help text, onboarding, error messages, and parts of the privacy policy all went through an AI pass, then were edited heavily by us
- exploring data structures: talking through how to model skills, tools, shipped titles and companies as a graph was made easier by being able to sanity-check options quickly
- thinking through flows: walking step-by-step through "add profile", "edit profile", "sign in", and "search" with an assistant helped shake out edge cases earlier than we might have done on our own
- writing and refactoring code: from small utility functions to sketching out components and queries that I then reshaped, reviewed, and wired into the rest of the system
It was not a smooth "type in a prompt, get the perfect answer" experience.
Left to its own devices, AI will happily go off on tangents: inventing features we never asked for, redesigning flows that had already been decided on, or confidently proposing structures that don't quite fit the people we're building for. If you're not paying attention, it will quietly steer you back towards the sort of generic product it has seen thousands of times in its training data.
What AI didn't do was decide what we were building.
It didn't come up with the idea of The Hatchery. It didn't choose the trade-offs between flexibility and structure in the profile form. It didn't decide that we would avoid tracking scripts and advertising, or that magic-link sign-in was a better fit than passwords for this audience.
Those are judgement calls. They sit in human heads, shaped by experience and values.
This is exactly the pattern I keep coming back to in my writing:
AI can accelerate the building, and in some cases the thinking around the edges. It can also accelerate you in the wrong direction if you're not clear about why something needs to exist. It cannot give you the "why" for free. It cannot tell you which problems are worth solving, or which trade-offs line up with the kind of product and community you want.
The hard part wasn't the tech stack
From a purely technical perspective, The Hatchery is built on fairly standard pieces: a hosted Postgres database, a web front end, a visualisation library, an auth flow, all running on a modern cloud platform.
For a team with some engineering experience, none of that is exotic. Ten years ago, building something like this would have taken more time, effort, and money. Today, the infrastructure cost and effort are low enough that a small team can do it alongside other work.
Which brings me to the point I'm trying to make with all of this writing:
For many small teams, the hard part is no longer "can we build a tool like this?" It's "do we know ourselves and our problems well enough to design the right tool in the first place?"
If you don't, you end up buying a generic product built for the median customer and then spending months trying to bend it into shape.
If you do, you can often get further, faster, by building something small and sharp that fits you exactly — especially now that AI can take some of the friction out of design, copy, and glue-code.
What this means for small teams
Building The Hatchery hasn't made me anti-SaaS or anti-off-the-shelf. There are plenty of tools I'm happy to rent rather than build.
It has reinforced a few beliefs, though:
- The more specific your understanding of the problem, the more likely it is that existing tools will feel wrong-shaped.
- AI makes it cheaper, in time and effort, to explore custom tools — not just prototypes, but things you actually use and maintain.
- The risk isn't that small teams lack the ability to build. It's that they don't give themselves permission to, because they assume "real tools" must come from big vendors.
The Hatchery is one answer to a very specific set of questions in the games industry. Your questions will be different. Your why will be different. Your tools should be different too.
The thing I keep coming back to is this:
The most important decision is not which stack you use, or which AI model you plug in. It's whether you care enough about your own way of working to design tools that fit it, instead of reshaping yourselves around someone else's defaults.
That's what I mean by smaller teams, sharper tools.
You can explore The Hatchery at hatchery.woundedbirdgames.com.