It’s easy to build systems when investors are pumping millions of dollars into a company for pure growth, and the team’s only fear is “shipping features too slowly.” However, the real school of engineering begins when a startup matures, becomes profitable, and the system processes tens of millions of transactions per month. That’s when concepts like unit economics, deep optimization, and technical debt management hit the table.
I talked with Andrzej Lorenz, VP of Engineering at Zilch, about how an engineer’s perspective changes when a business starts paying for itself.
Bartek: The tech industry has learned a painful lesson – the days of infinite capital are over. Zilch has succeeded and achieved profitability. How did this transition from “hypergrowth” to “profitability” shift priorities within your engineering organization? Is there more room for architecture in the backlog now, or is the pressure for results even greater?
Andrzej: The answer might surprise you: within engineering itself, not all that much has changed. We never really left the growth phase; its nature simply shifted. When the crisis hit in late 2021, bringing inflation and rising interest rates, the cost of money skyrocketed. That’s when the entire market had to flip the switch from a growth first / growth only approach to value first, growth second. Companies that didn’t understand this quickly went under.
We didn’t have a revolution because from the very beginning – since I joined the company – we focused on hiring highly experienced people. In 2021, we grew globally from 20–30 people to two hundred. You can’t achieve that with a gym-bro mentality of “bulking first, cutting later.” We immediately looked for “bodybuilders” – people around whom teams could be built and scaled, not developers who would generate chaos.
As for the backlog: we believe that speed comes from quality. Of course, business pragmatism sometimes requires making compromises and shipping an MVP, but for us, delivering quick value always includes a plan to patch up the debt in the next step.
The biggest change related to profitability and scale is our risk appetite – it’s much lower now. In the past, an incident affected a hundred users; today, it affects thousands. We are a financial company; we give people virtual cards. A customer’s card at the store simply has to work. There is no room for “half-baked” things. We do public rollouts more slowly and cautiously, testing longer on control groups.
Bartek: Speaking of scale and responsibility: it’s in the Krakow hub where you build the Spend domain, which is the commercial heart of Zilch. Tens of millions of transactions pass through you every month. With this kind of volume, every system modification directly impacts the entire company’s P&L. How does the Krakow team approach the development and optimization of this area to squeeze the maximum business value out of it?
Andrzej: All the features we introduce are directly aimed at our most critical business metrics: GMV (Gross Merchandise Volume) and Revenue. In the Spend domain, every project has a massive, measurable impact on the business.
Over the past year, we’ve done a ton of things like this:
We introduced Snooze 3.0 (an installment deferral feature) along with automation for the process.
We launched Memberships and Advance – a short-term loan product against an upcoming paycheck.
We optimized simple yet crucial elements, like handling decline codes, so customers know exactly why a transaction was rejected and can fix it.
In the Krakow team, we also optimize the entire billing run process, including the collection of installments from customers. For example, a year ago we introduced proactive Pay by Bank payments.
Engineers at Zilch aren’t just there to “churn through tickets.” Product and engineering work as strategic partners to shape the right solutions together. Everyone has access to transactional data and can come up with an optimization idea. Our people proactively track technical and business metrics because they know that the processing speed of the transaction system directly determines whether a transaction even goes through.
Bartek: In the world of profitable business, code performance suddenly has a direct impact on the bottom line. Do Seniors at Zilch need to think like “cost architects” today? To what extent are FinOps and watching every pound spent on AWS part of their daily routine?
Andrzej: We don’t really think about engineering as a cost centre, we see it as a revenue centre. The work engineering does directly affects whether transactions go through, how much volume we process and ultimately how much revenue the business generates.
Cost obviously matters, but we have a very healthy approach to it. If a certain cost is justified and generates significantly higher revenue, we incur it. We drive the business forward first, and we deal with cost optimization in the next step.
It’s similar right now with AI and tokens. Today, it’s more important for us to find out what we can actually achieve through AI across the entire SDLC than to count every single dollar. Only when we notice a sudden, anomalous, massive cost do we sit down to analyze it.
We don’t expect every engineer to tremble every day over the cost of a new log line in the cloud. But if a senior engineer comes forward on their own initiative and says, “Look, this solution will generate a higher cost on AWS, is that OK?”, we view that as a huge bonus. Cost awareness exists here, and larger initiatives go through financial modeling before hitting development, but system quality, stability and business impact come first.
Bartek: Zilch is fully regulated by the FCA in the UK. How do you balance rigorous compliance with the need for fast delivery in a mature environment?
Andrzej: Being regulated is something we proactively chose, and a lot of what the FCA asks for aligns with what we’d want to build anyway – products that are responsible, transparent and work in the customer’s best interest.
For engineering, the challenge is to understand the intent behind those requirements and find the simplest, most effective way to meet them without introducing unnecessary complexity or slowing down delivery.
It’s about treating regulation as part of the product and engineering environment, rather than something separate from it and finding the right balance between compliance, customer experience and speed.
Bartek: People in the industry love hearing about mistakes because that’s how we learn the most. At the scale of your current millions of transactions, what stopped working for you? What past decision did you have to brutally re-evaluate?
Andrzej: You have to clearly distinguish a startup from a scale-up. In a startup, anything goes because you just need to prove that your business idea makes sense. We closed that chapter years ago.
However, if we had today’s knowledge and wealth of experience, we would have made a few decisions differently. One of the most fundamental was an early decision around our primary database technology, which didn’t work out as well as we had hoped. At the very beginning, when Zilch was made up of maybe five people, we chose what the team knew best at the time. As the company grew and our transactional scale increased, the limitations of that decision became more apparent. At this stage of the company’s growth, however, migrating away from such a core part of the technology stack is incredibly difficult.
It was a similar story with decomposing the monolith- in hindsight, I believe we should have started specifying the decomposition from the database side much earlier, instead of focusing primarily on the service layer first. Technical debt is born with the very first line of code. The key isn’t its total absence, but constantly maintaining an accurate inventory of that debt and consciously deciding what to invest time into and what we can safely live with.
Bartek: In this mature environment, how is the profile of the ideal employee and candidate changing? Are you still looking for people with that typical startup drive to get things done “by yesterday,” or do you value engineers with a systems-thinking mindset more now?
Andrzej: Those two aren’t mutually exclusive; professionalism only enriches the profile. We still highly value people with an entrepreneurial mindset who want to see the real value of what they are building. The difference is that in a scale-up, an engineer must see the long-term consequences of their decisions.
In a scale-up, the business is already validated – there is a structure and a roadmap to follow. There’s no longer room for “cowboy development” and the “Wild West,” where a developer decides in the morning what they think is the most important thing to do today. For us, team autonomy means that engineering has 100% choice regarding the solution, but the business decides what we actually build.
We sometimes have to remind people that decision-making isn’t always a democracy. We are more than happy to listen to everyone’s opinion-regardless of seniority, anyone can come to me, the CTO, or the CEO and challenge our decision (and that actually happens!). However, at some point, the discussion ends, a decision is made, and the whole team must move forward in the same direction. Otherwise, we lose speed.
I guess we’re doing it right because turnover in the Krakow team is negligible. Just on July 1st, we celebrated more 4-year work anniversaries for engineers who have been with us since the very beginning of the Poland office.
Bartek: Finally, a local angle: what is the relationship between Krakow and London? Often, Polish branches of foreign companies are treated simply as cheaper, satellite software houses.
Andrzej: For us, it was completely different from the very start. We never felt like a satellite office. We are a fully-fledged part of the company, and Polish engineers are treated exactly the same as those in the UK. What’s more, the Spend domain – the absolute financial heart of Zilch – technically belongs in large part to Krakow. Without Krakow, Zilch wouldn’t exist today.
Poland is a real growth story for us at the moment, backed by continued investment in the team. We’ve hired 13 new people here this year, with two more roles still open, which will bring us to around 15 new hires in total. What’s particularly encouraging is that growth is fairly evenly split between London and Poland, so both locations are scaling at a similar pace.
Over the years, the Krakow team has built an enormous amount of trust within the company. The UK leadership sees that Polish engineers bring not only vast knowledge and a unique work ethic, but that they simply deliver massive output. That track record is why Krakow has been given so much responsibility, and why we continue to invest in growing the team here.
Are you building or scaling an engineering team in Poland?
At itMatch, we help international companies build teams that go beyond delivery, with senior engineers who understand business impact, take ownership and can grow with the organisation. From defining the right talent profile to hiring the people who can take responsibility for business-critical areas, we support companies at every stage of building their tech presence in Poland. Let’s talk about your hiring plans in Poland.
