The best engineering teams have proven methods for shipping fast without chaos.
Just ask Pavlo Terpak, a senior solutions architect at Allwyn, a lottery operator, supplier and business partner, who said his team focuses on minimizing friction, shipping in small batches and leaning on automation wherever they can.
“We work with our partners to keep pull requests small and we merge them often,” Terpak said. “It’s never perfect in reality, but keeping those code chunks small cuts down risks and makes reviews a lot easier.
At fintech company Avant, Chief Information Officer Paul Zhang said their rule for releasing fast is a commitment to testing across the full stack paired with peer reviews.
“Testing is a required part of every change, not a best-effort add-on,” Zhang said. “We've invested in the infrastructure to run large test suites fast enough that they don't create the bottleneck engineers learn to route around.”
Built In spoke with Zhang and Terpak about how they ship fast without chaos, maintain a high-quality stack and adopt new tech where it actually moves the needle.
Avant utilizes data and technology to connect Americans to financial solutions.
What’s your rule for releasing fast — and what KPI proves it works?
Our rule is simple: Green tests mean it's merge-ready and anything on main is production-ready. Every PR requires passing automated tests across the full stack plus a peer review — no manual gate beyond that. If the pipeline is green and a reviewer has signed off, it ships. That keeps the path to production short, predictable and free of the risk that accumulates when changes sit unreleased.
We validate this with DORA metrics. Deployment frequency tells us we're not hoarding changes into risky big-bang releases. Change failure rate shows whether our automated coverage is actually catching regressions — not just running. Mean time to recovery keeps us honest about our ability to respond quickly when something does go wrong. Together, they give us a real-time feedback loop on the health of our delivery system, not just a feeling of velocity.
Which standard or metric defines “quality” in your stack?
Honestly, our stack isn't exotic — the tools are largely the same ones good engineering teams use everywhere. What defines quality for us is the institutional commitment behind them.
Testing is a required part of every change, not a best-effort add-on. We've invested in the infrastructure to run large test suites fast enough that they don't create the bottleneck engineers learn to route around. A slow or unreliable pipeline doesn't raise quality, it just adds friction while people find workarounds. Keeping that pipeline trustworthy at scale takes ongoing investment and organizational will and we treat it as a first-class concern.
Code review reinforces the same culture. It's a craft conversation, not a compliance checkbox. At the system level, DORA metrics tell us whether all of it is actually producing stable, fast delivery. But the metrics are downstream of the culture. You can't DORA your way to quality if the underlying commitment isn't there.
Name one recent AI/automation shipped and its impact on the team or business.
We've been deploying generative AI to automate workflows that span multiple systems and require contextual judgment — work that previously needed a person to manually pull information from several places and make a call.
One example: We automated a customer-facing workflow that previously required human intervention at multiple points to read, interpret and act on incoming requests — the kind of task that doesn't follow a script and can't be handled with rules-based logic alone.
What made this tractable with AI is the judgment involved. It requires understanding context, inferring intent and making decisions that depend on synthesizing information across systems. We solved it with a combination of an AI agent and a workflow tool and the result was a meaningful reduction in the manual effort and lag that comes from humans acting as the connective tissue between systems.
That success has changed our internal calculus on what's automatable. We're now actively identifying other complex, multi-system workflows that are on the table in a way they weren't before.
Allwyn is a full-service lottery operator, supplier and business partner to North American lotteries.
What’s your rule for releasing fast — and what KPI proves it works?
To me, moving fast doesn't mean being reckless. Since we work with external development partners, my approach really boils down to three things: minimizing friction, shipping in small batches, leaning on automation wherever we can.
We work with our partners to keep pull requests small and we merge them often. It’s never perfect in reality, but keeping those code chunks small cuts down risks and makes reviews a lot easier. I also believe that if a deployment step needs human intervention, it’s a bottleneck. Some releases will always need a quick manual check, but the goal is to automate the grunt work with solid CI/CD pipelines.
Finally, I'm a big fan of decoupling deployment from the actual release by using feature flags. It lets us push code more frequently, but we keep the control to turn features on only when they're actually ready. To know if we're hitting the mark, the main KPIs we look at are deployment frequency of unplanned releases and lead time for changes. In addition, I also suggest looking at manual quality assurance hours per release. A drop in those hours is a great indicator that our automation is actually working and speeding things up.
Which standard or metric defines “quality” in your stack?
Quality can mean a hundred different things, but for me, it’s all about tying engineering metrics straight back to the business requests and the user experience. Because we manage external suppliers, quality isn’t just looking at the final code; it’s about making sure the whole lifecycle is solid — starting right from how we define business requirements, write functional docs and set up test cases.
On the technical side, a high-quality system is simply one that bounces back fast. We keep a close eye on our change failure rate and mean time to recovery per our strict service level agreements when things go a bit off track. We try to bake quality in before code ever ships by working with our partners to hit strict test coverage and keep our defect escape rate low.
But at the end of the day, the true test of quality is the player experience. If our system latency is low, vendor service level agreements are green and our players are happy, that’s when I know our stack is doing its job.
Name one recent AI/automation shipped and its impact on the team or business.
I see AI as a game-changer, but at Allwyn, we try to be really pragmatic about it. There’s no magic AI tool that’s going to solve every problem across the board. Instead, our strategy is to set up targeted AI agents for very specific tasks to actually make automation work for us.
A great recent example is a customer-facing chatbot we rolled out. We used AI to build an agent specifically to handle the highly predictable, repetitive questions we get from our players. It’s doing a fantastic job. By letting the AI handle the routine stuff, players get answers instantly and it frees up our human support team to dive into the more complex, nuanced requests.
We do the exact same thing internally. Since our day-to-day operations and management live in Google Workspace, we lean on tools like Gemini as supportive assistants to automate the tedious daily admin tasks. Ultimately, it’s not about slapping AI on everything; it’s about putting the right agent on the right job so our team can focus on actual problem-solving.
