Every engineering org has a list of problems it knows it should build out of and never does. Ours had two on it for many years, and we recently rolled out two internal solutions to address them.

The first is a data migration system allowing our teams to more easily facilitate importing customer data from whatever system they’re leaving into ours. The second lets our staff build and edit customers’ Pinpoint-hosted careers sites by talking to AI powered coding assistants, e.g Claude.

Between them they’ve taken a recurring interruption away from software developers entirely and another team has shaved hours off individual tasks in one of its largest ticket queues.

This isn’t so much a story about AI writing code, and instead is more of a rallying cry for teams to reassess and check old assumptions against the new cost of building stuff today.

Why these never got built

Nobody ever actually argued against them. Internal tooling projects competed with the customer-facing roadmap though, and obviously lost… a migration tool doesn’t close a deal! Couple this with the fact we’re a really lean engineering org and I think the “why” is pretty clear.

So for the longest time the work happened anyway, “by hand”, done by whoever was closest to the pain. For us that’s historically been software developers, but today it’s Technical Success, a team inside R&D who absorb technical complexity on behalf of all our customer facing teams.

We made very little progress on this front really until frontier models very recently took over the world.

Nobody has written a migration script since June

Massive result. Since we rolled these tools out no software developer has written a single custom data migration script.

They used to be unavoidable, and I wrote plenty of them myself! A recently onboarded customer arrives with an export from a previous system, with their own gaps and nuances, and it has to become jobs, applications, candidates, workflows, and a bunch of other things in our schema. Every single one was bespoke, and basically took a developer multiple days to write, test and run (dry and then for real).

I should add as well that those are days not spent building and improving the product!

Today though it’s a Technical Success process, with its own intake, Slack channel, and pipeline, meaning that these requests are completely owned end to end by those embedded into the customer relationship. Since June our new migration tool has handled 241 imports and a little over 1.2 million rows.

Nobody clicks through a page builder any more

Comparably, careers site edits are certainly smaller pieces of work — on average they used to take between one and four hours each. Lots of clicking, configuring, coding, branding and reviewing. They constituted about 40% of the Technical Success team’s queue.

We now consider time to completion for these tasks in terms of minutes rather than hours. A request comes in, an agent picks it up and then makes the changes through an MCP server, working against the site draft. A human then reviews it, prompts away (or manually adds some finishing touches), before then publishing it live.

On top of it sit skills and routines that let an incoming task be picked up and worked on without anyone shepherding it, wired into the tools the team already lives in. Chef’s kiss.

Full site builds are a different shape. This tends to be a consultative process of meaningful back and forth with our customers. What has changed though is the cost of those round trips: we’re able to (quite literally) say out loud what we want to see and watch it appear, review and refine those outputs with clients, and iterate until we’re where we want to be. Now we can hit milestones way quicker and the sites end up coming out better.

Someone in our Sales team recently called one of them out as the “best careers site they’d seen in two years of demo’ing Pinpoint”.

Go and look at your list again

If you run an engineering team, I would imagine there’s a good chance you’ve got a list like ours, describing organisational friction that you’ve never found the time to address. My advice, today, would be to dig it out!

Both of the tools I’ve described above went from nothing to running in production in a matter of weeks. This basically wouldn’t have been possible for us in the not too distant past. The MCP server in fact wasn’t even conceivable a few years ago.

What has come out the other end is actually, I think, better than what we’d have built the old way, too. Data migrations now go through well designed, robust, tested, automated validation phases with guard rails and dry runs built in by default. Likewise, careers site changes go back to customers the same day, and they come back better because trying a second idea basically costs nothing.

Our list still has plenty on it, and I’m sure it always will. What is different now though is how I read it. A lot of the reasons things ended up there in the first place just don’t hold any more.

If you’ve built something like this, I’d love to hear about it. Especially the unglamorous internal stuff nobody usually writes up, because I suspect that’s where a lot of quiet gains are happening right now.