We built Payroc's developer hub from scratch, with several production features shipped in just a few months. Claude wrote much of the code. We estimate that before AI, even one of those features alone could have taken as long to ship. It would not have come out as polished either, because we could not have rewritten pages and re-run pull requests (PRs) anywhere near this fast.
Our developer hub itself is a self-service portal: sign up, get an API key, and start calling our APIs in under a minute. It also includes hosted referrals, embedded components, webhooks, and organization management. That side of the project is worth its own writeup. This one is about how three of us actually built it, and what changed once Claude was doing a real share of the work.
The day-to-day got faster, and more fun
Barney had spent years writing React and CSS by hand, work he describes as slow, painful, and difficult. Tracking down a bug in it was harder still. With Claude handling more of that, he says the job has changed enough to bring the fun back into building software. We still have to understand what's actually going on and why, and steer Claude when it heads the wrong way. But the mechanical part of the work, the part that used to eat a day or days, now takes an afternoon.
That speed showed up as PR feedback we could act on immediately. Instead of getting stuck on an annoying piece of backend code that was blocking a feature we actually wanted to ship, we could tell Claude to build the backend quickly. Then we'd put a UI on it and see whether the idea worked at all before refining anything. If a page wasn't quite right, we'd say so and change it, and that loop, “not quite right, change it,” was fast enough that we stopped treating early versions of a page as precious.
Turning a rough direction into a finished portal
Product gave us a direction to head in rather than a finished spec, and left the details for us to work out. We were comfortable filling that in ourselves, with Claude doing a lot of the legwork, and turning it into a finished, consistent portal. Rachel led design first and turned it into a template, so we could hand pages to Claude and keep them visually consistent as new features landed, rather than reviewing each one for drift after the fact.
The admin screens are a good example of what that let us do. We needed a way to test what happens when an organization breaks, or a new user gets invited. So Barney put together an admin screen for it in a matter of days, built purely so we could test the system ourselves. That screen has since fed into how we're thinking about merchant approvals and agreement changes once a business has signed its legal documents, an idea that started as a quick testing tool rather than a planned piece of infrastructure.
Arguing with Claude is a normal part of the day
None of this is hands off. Rachel says catching and redirecting Claude is a normal part of most days for us. We tell it something isn't right, it says the code works, we check again. When it still doesn't, we point out exactly what's wrong and let it try again. That back and forth, not a one-shot answer, is how most of what we built actually came together. The same applies outside code. When a piece of text or a design choice doesn't land right, we say so directly and Claude reworks it.
We built that skepticism into how we work as a team too. When Claude produced a plan that wasn't quite what we expected, we didn't wait for the next standup to raise it. We'd get on a call immediately, several of us at once, and work out whether there was a better way to do it before too much got built on top of a shaky decision.
What we learned from getting it wrong
Our biggest lesson from this project came from a mistake, not a success. Early on, we gave Claude a set of rules for the database and then largely left it alone, assuming a SQL review step was running as part of that. It wasn't, not to the extent we'd assumed, and Claude reported the database as working when it wasn't doing things correctly. Untangling that meant a large, disruptive set of changes just to get the schema back to where it should have been from the start.
Mark's read on it is that this came down to a standards gap, not a Claude problem. We'd told Claude the rule once and assumed that was enough, when what we actually needed was a check that ran every time, regardless of who or what was writing the SQL.
That's the fix we've made, and the one we'd pass on to anyone building this way. We're now writing the SQL review directly into the repository itself, as an explicit instruction Claude has to follow every time rather than a rule we hoped it was following. That same pattern is being adopted company wide, not just on this project.
Get it working, then make it pretty
If we sat down with ourselves before this project started, the advice would be to just get something working first, because we can clean it up later. We went through several iterations on almost every page in the portal, on both the UI and the API side, and the first version was rarely the right one. What kept the project moving wasn't waiting until something was ready to show. It was proving early that an idea could work at all, even if it looked rough. We trusted that the rest, including things as unglamorous as a wrong stored procedure or a schema that doesn't follow Command Query Responsibility Segregation (CQRS), could be fixed once we knew the idea was sound.
What this changed about our jobs
Asked whether AI changed our role, Barney's answer was that it changed what's possible, not what we do. A change that would once have meant touching 27 pages across the portal, the kind of task that used to sound like a months-long nightmare, now gets described as something we can have done by lunchtime. Mark is more guarded about what that freedom depends on. The tools still need someone who understands the code, who can tell good output from bad and knows what a well-built system is supposed to look like underneath it. Without that, faster output just means faster mistakes.
That's the real shift for us. Three of us built a self-service system essentially from scratch that would have taken a larger team significantly longer to put together a year earlier. The code got faster to write. What hasn't gotten any easier is judging the outcome, not just whether Claude's code runs, but whether what it built actually does the job for whoever is using it. That's the question we're still answering ourselves, every time, no matter how fast the code behind it got.