How a 20-engineer team delivers enterprise AI systems at Fortune 500 scale

When I took over responsibility for technical function at akirolabs more than three years ago, I inherited a procurement SaaS platform that was still at a very early stage, with development fully outsourced outside Europe. However, the company had already reached early product-market fit, and first customers demonstrated their interest, which made product ownership and scalable delivery increasingly critical.

After evaluating several approaches, I decided to fully insource development from South Asia to Europe and rebuild the entire technology function in-house, including engineering, product ownership, infrastructure and delivery processes. It was clearly the highest-risk option but also the one with the biggest long-term potential.

Preparing to the implementation of this decision, I kept hearing advice which was quite consistent: if we wanted to build and operate an enterprise-grade procurement SaaS platform for global corporations, we needed to hire aggressively. Most estimates I received started at around 50 engineers. At the time, the recommendation sounded logical. Expectations around reliability, security and delivery speed were extremely high. But I also believed the standard enterprise scaling model had a flaw that many companies underestimate: larger engineering organizations often become slower precisely because they are larger. Instead of scaling through headcount, I decided to scale through organizational design.

Our first fully production-ready in-house platform release was delivered in less than 12 months from the day when I hired the first engineer in-house. I delivered the full-scope release with a team of roughly a dozen engineers and without any AI co-pilots – the tooling simply was not mature enough yet in 2023 and early 2024. Later, I added a dedicated data science team and evolved the platform into an AI-augmented system with a fully redesigned UI/UX.

Today, three years into this transformation, akirolabs has evolved into a recognized category leader. Over the next few years our current customer base has extended to power the strategic procurement operations of enterprises such as Bertelsmann, Raiffeisen Bank International, IFF, UCB Pharma, Axpo and others.

This proven scale demonstrates that in enterprise AI, operating model matters more than team size.

Why large engineering organizations slow down

One thing I’ve repeatedly seen in enterprise technology is that communication complexity grows faster than headcount. Fred Brooks described this decades ago in Brooks’s Law, arguing that adding manpower to a late software project often makes it later. The reason is not simply onboarding overhead. It is the explosion of coordination paths inside the organization itself. The communication channel formula is straightforward – with 12 engineers, there are 66 possible communication paths. At 50 engineers, there are 1,225.

In practice, that complexity becomes operational drag. Teams spend more time aligning than building. Meetings multiply. Ownership becomes blurred. Delivery slows down even though payroll grows. As CTO at akirolabs, I wanted to avoid that trap from the beginning. We intentionally kept the organization lean and structured it around small, highly autonomous functional groups. Instead of creating rigid specialization silos, we hired engineers who were comfortable operating across adjacent disciplines. This mirrors a broader industry shift toward cross-functional platform and engineering teams.

That cross-functional flexibility became one of the biggest advantages for the company. Backend engineers supported infrastructure automation. QAs worked closely with Security engineers. Frontend developers handled portions of UX implementation directly. Our data science team owned significant parts of the MLOps lifecycle. As CTO, I also absorbed part of the product management layer myself to reduce decision latency and preserve execution speed. This model only works with senior engineers, high trust and strong ownership culture.

In our case, insourcing development also fundamentally changed our delivery velocity. Compared to the outsourced structure we previously operated under, product delivery accelerated by more than 2x. We gained direct control over infrastructure, intellectual property, architectural decisions and security processes. It also enabled long-term planning because our engineers were building systems with full awareness of platform requirements. That visibility allowed us to reduce cloud infrastructure costs by more than 30%. Keeping the engineering organization intentionally compact helped us also avoid the architectural sprawl early on, a dynamic which is often described through Conway’s Law.

Once the people designing the architecture are also accountable for long-term scalability, infrastructure decisions become dramatically more intentional, enabling the platform to scale and secure akirolabs recognition as an IDC Innovator in Procurement in 2023, named amongst the Top 27 AI Startups in Germany in 2024 and Sifted’s 100 Fastest-Growing Startups in DACH & CEE 2025.

Replacing Scrum with continuous delivery

Another major decision we made was abandoning Scrum. That statement usually generates strong reactions because Scrum has become very popular across enterprise IT. But in our experience, traditional sprint-based delivery models created too much operational overhead for the type of work we were doing. Enterprise AI systems evolve continuously: data pipelines change or models require retraining. Trying to force that environment into rigid sprint cycles often created artificial planning friction instead of predictability.

We moved fully to Kanban and continuous delivery. The difference was noticeable almost immediately.

Our roadmap became directional rather than fixed. Features shipped when they were production-ready, validated and needed by customers – not because a quarterly milestone required a release. We focused heavily on limiting work in progress, shortening feedback loops and reducing context switching. Removing process overhead had a measurable impact on productivity. Internally, we estimated that eliminating Scrum rituals alone recovered roughly 10% of engineering capacity. Lead time for medium-sized changes dropped from days or sometimes weeks to hours. Release cadence stabilized around monthly production deployments instead of quarterly while urgent fixes and improvements could move significantly faster. That mattered more than any sprint ritual.

Communication discipline was equally important.

We consolidated nearly all meetings into mornings and invited only people directly involved in the decision being discussed. If information was declarative or preparatory, it was documented asynchronously through structured chat channels or internal wiki pages instead of calls. We also minimized email usage almost completely.

Because the company operated remote-first, we complemented this lightweight communication model with intensive in-person workshops three or four times per year across different European cities. Those workshops helped maintain strategic alignment while day-to-day execution remained highly asynchronous. Combined, these changes improved overall team productivity by an estimated 20% to 30%.

AI-assisted development later became another major productivity lever for the team. Today, we use AI copilots extensively across coding, code reviews, task analysis and debugging. Based on our internal observations, these tools contribute an additional 20% to 25% productivity improvement when used within mature engineering processes. But I do not believe AI tooling alone solves enterprise delivery problems. Without clear ownership structures and discipline, AI often amplifies organizational chaos rather than reducing it.

Lean teams can still satisfy enterprise governance

One of the most common assumptions I hear from enterprise leaders is that lean engineering organizations eventually break down under compliance pressure. Our experience was the opposite. With essentially the same compact organizational structure, we achieved ISO 27001 certification under 9 months without any external help. Also, we aligned our governance processes with the requirements of the EU AI Act, which supported our one-million public government grant from Investitionsbank Berlin in 2024 for breakthrough AI innovations.

None of that required building large governance departments or adding layers of bureaucracy. What mattered far more was clear ownership and direct accountability between the people building systems and the people operating them.

We also embedded prioritization deeply into our culture. Across the organization, teams actively use principles like the Eisenhower Matrix to distinguish urgent work from strategically important work. That may sound simple but in high-growth technology environments, prioritization discipline often becomes the difference between scalable execution and constant operational overload.

Perhaps one of the clearest validations of our operational model has been retention.

Over a three-year period of my leadership at akirolabs, only one engineer voluntarily left the organization. To me, that says something important about how experienced engineers want to work today. Engineers generally do not want to spend their time navigating endless approval chains or low-value meetings. They want ownership, autonomy and the ability to see direct impact from their work. That is especially true in enterprise AI where iteration speed and adaptability increasingly determine competitive advantage.

For years, the enterprise technology sector has operated on the assumption that scale requires organizational expansion. My experience building enterprise AI systems suggests the opposite may often be true.

Sometimes the fastest way to scale is to stay intentionally small.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?