Process should not impede progress

ABRI's been trying to replace an early-2000s registry product for most of two decades. The 2021 rebuild was the third attempt. By late 2025 it was years behind and millions over budget.

In November the board mandated $2.5 million a year in cuts. Their initial plan was to keep the twelve-person offshore contract team and cut the local developers. I argued for the opposite and asked to keep six onshore. They cut two of those and left me with four, no QA, and a substantial loss of decades of industry-specific knowledge.

So I had four developers. A principal dev and a lead systems architect, both full stack. Two backend guys, Delphi and C#, who'd never written a line of React or front end code.

Data validation is the backbone of our registry services. It's what enforces accuracy and compliance at the point of data entry. The rules driving it lived in a Delphi rule engine written twenty years ago and they all had to move to JSON. The two backend guys were converting them by hand, one at a time, testing each permutation, and quoted me six months. We didn't have six months.

For the way they were doing it, six months made sense to them. They're careful engineers and nobody at ABRI had ever shown them another way to do it. They were used to Delphi systems, one mistake brings down the entire stack. No "failing gracefully" here.

I facilitated a meeting with the team, including the senior devs. We showed them how to leverage AI tooling to expedite the work, and within an hour we had not only migrated all the rules slated for the six months, but also defined a process to carry forward for future rules.

I ran it as a group session on purpose. Everyone stays in their own lane day to day. With a team this small and no monorepo, if we're all working the same area we just run into each other. But separate lanes shouldn't mean nobody knows what anyone else is doing. I wanted them looking out for each other. Getting them in a room on something concrete did more for that than anything I could have put in a process document. Build the camaraderie and improve the communication. Get them used to collaborating and depending on each other.

Both of them ship production Next.js and React now. They built the UI for managing, creating and testing validation rules. They built the migration path off the legacy Delphi apps for our customers to leverage our new platform. They built a .dat and .csv import tool with a slick front end.

The rules UI is ongoing work. But clearing that block opened up a lot behind it. There are thousands of rules, each specific to a customer. Things like:

IF   <DNA condition> is present
THEN append <ID> and <Name> of the record

Our principal dev had spent months putting real design patterns through the codebase. Consistent structure, clear conventions, a component library. When I got there the architecture was the strongest thing we had. We wrote Cursor rules that enforced those patterns, so the model wasn't generating React, it was generating our React, against conventions that already existed with components it was told to use.

If you drop two Delphi engineers into a greenfield repo with Cursor and no patterns, you'll get a lot of code and none of it will hold. We got speed because there was something there to be fast against.

The other two developers, the principal dev and lead architect, had a completely different problem.

Our principal dev is a one-man dev team, the most capable engineer I've worked with, and he was spending his weeks babysitting the offshore team, fixing their mistakes and chasing them to correct their own work. No scrum master, no product owner. On the other hand, the lead systems architect was in more than thirty-five hours of meetings a week. Both of them knew exactly what to build. Neither had the time.

Cutting the offshore contract gave the principal dev his week back. Pulling the meeting load off the architect gave him his. The removal of unnecessary meetings, agile ceremonies. This introduced tradeoffs, key person risk, no QA, but given the circumstances and the budgeting constraints, these risks are acceptable.

AI tooling made them fast. So did taking the blockers out. The two together are the force multiplier, and you don't get much from either one on its own. Meetings, offshore coordination, process that had stopped earning its place. Clear all that out, hand the team good tooling, and it compounds, because my devs are also my SMEs. They hold the domain. Nobody has to explain the business to them before they can start. The tooling has essentially turned each dev into their own delivery team. This also freed me up. As long as the team has clear business and functional requirements, they can all run with the rest and hit the ground running.

Process should keep you on track and support you. When it stops doing that it's just overhead, and most of what I did early on was delete the overhead. I've seen this kill momentum, in big companies like Auto & General, Nasdaq, their processes are a hindrance to avoid all risk. Those are very risk averse companies. Having a healthy appetite for risk is essential, and must be done strategically.

We cut most of the agile ceremonies. What's left is sprint planning and standups. If we need a retro we'll run it inside a standup, and that works because the team is small and flexible enough to raise a blocker, unstick it, and give feedback in the same conversation. The ceremony existed to make sure those things happened. Once they were happening anyway, the ceremony was just a meeting.

Internal expectation was that we'd fail. The previous board thought so too. Here we are, months ahead of schedule, less than a year from full completion, and 5 different features in flight, landing before the end of this year.