We also did something that made a few people in the audience nervous. We showed live software. No slides with promises, no polished product video. We showed an application that two companies had built together in nine days, and that we are about to use for the most sensitive process we have: sending out our invoices.

This post explains what we built, why we did it, and what we learned. Most of what we learned has very little to do with code.

The experiment: 9 years vs. 9 days

Kapernikov and TAG run similar businesses: consultants, projects, customers, timesheets, invoices. For years, TAG ran those processes on an internal tool that had grown over nine years. It worked well. It was also showing its age.

So we set ourselves a challenge for this year’s bootcamp: rebuild it from scratch, as one shared platform for both companies, in two weeks. About 30 people, split into five tracks (sales, delivery, recruitment and more), with nine days of actual building.

We gave ourselves three goals:

1. Learn. Find out what AI-driven software development really means when you take it seriously.
2. Bond. Get two companies working as one team.
3. Deliver. Not a prototype, not a demo. Something we would actually use.

The result is Phoenix: a cloud-hosted ERP with enterprise authentication. It covers sales opportunities, resource planning, timesheets, invoicing, one-on-ones with consultants and training programs. It is not vibe-coded, and it is not an HTML mock-up on a SharePoint somewhere. To prove that, we’re starting to invoice with it this month.

That’s what we often hear from customers who are tired of proofs of concept that never go anywhere. We wanted to eat our own dog food.

What changed: the developer is no longer the bottleneck

Before the bootcamp, we liked to say we could build anything that could be specified well. That became a running joke during the nine days, because we did. We built everything that was specified, and then some.

That is exactly where things got interesting.

For decades, software projects were organised around one constraint: writing code takes time. A rule of thumb was that one analyst could keep three developers busy. Everyone else (analysts, testers, product owners) had the comfort of time. While development was running, there was room to figure out what the customer wanted, and then what they actually needed.

During Phoenix, that ratio flipped. One developer could keep three or four analysts busy.

As Rein Lemmens, CEO of Kapernikov, put it:

Lesson 1: If you can build anything, you need to know what not to build

Our favourite example is the planner.

We needed a calendar view for resource planning. Every stakeholder had their own wishes. Since building features no longer took weeks, we built all of them.

The result was a planner that nobody wanted to use.

When someone asked what the biggest hurdle of the nine days was, Maarten De Munck, Partner at Kapernikov, didn’t hesitate:

Listening to users, turning their wishes into one clear way of working, checking that with the key users and repeating until you find the solution: that is still human work, and it takes its time. In fact, it now matters more than ever.

Lesson 2: Roles shift, and they don’t disappear

Here is how the roles changed in practice:

• Analysts help people make decisions instead of just writing them down. AI drafts the requirements; the analyst checks them, sharpens them and aligns the stakeholders.
• Testers only test what can’t be automated: is this intuitive, are the buttons in the right place, would anyone want to use this? Regression testing is done by agents, so a new feature doesn’t break an old one.
• Architecture is adapted to what agents do well. Repetitive code is no longer a problem. Respecting module boundaries suddenly matters a lot again.
• Developers take a step back and look wider. Effectively, they all need to think like architects and UX designers.

Coding isn’t really a human job anymore. Building applications still is.

Or, in Rein’s words: by exploiting the strengths of AI and filling in its weaknesses very explicitly with people, we could go both fast and far.

Lesson 3: Technology moves fast, people need time

This one surprised us more than any technical lesson.

The speed was exhilarating, and for some people it was simply too much. You can build something in an afternoon that people need a week to understand and absorb. As leaders, we found out that you cannot over-communicate in a project like this. Time spent aligning is not lost time. Building the same thing twice is.

Synchronising people is the one part of a project you can’t compress, however smart and fast the AI is.

Lesson 4: Start small, and start with your data

Ask the team what they would do differently and you get the same answers:

• Pick a few core processes on day one and build from there. We were so eager to start that by the end of the second night we had a lot of everything and nothing finished.
• Set up the master data first. We waited a few days, and then had to lock three or four people in a room for eight hours straight (with messages still coming in at 2 a.m.) to get the data model right.

From experiment to client work: what we’re taking into Asset360

Phoenix was an experiment, but the lessons aren’t staying in the lab. We’re already bringing two of them into Asset360, the asset management platform we’re building with Infrabel:

• A data seeder from day one. In Phoenix we used a simple Python script that fills the application with realistic data. It sounds trivial, but it changes everything: developers, testers and agents all work with something that looks like the real world, and you can benchmark performance long before real users show up.
• Massively parallel testing. In Phoenix we ran our unit tests and end-to-end tests on up to 16 threads at once. That breaks an application in all kinds of funny ways: race conditions, locking issues, hidden dependencies between tests. Fix all of those breakages and you end up with an application that is both faster and more robust.

Both are good examples of the shift we described earlier: when agents write the code, the human effort goes into making sure the code can be trusted.

What an AI-native application looks like

Phoenix wasn’t only built differently; it also works differently. A few things we showed live at Aurora:

• Bring your own assistant. A sales manager walks out of a hallway conversation, dictates a summary into ChatGPT on her phone, and Phoenix logs the opportunity, finds existing contacts at the customer and proposes available consultants. As a sales coach pointed out after the event: AI can write the proposal in minutes, but someone still has to have that hallway conversation and ask the right question. That’s exactly where the demo started.
• An agent inside the app that knows the context and tools of the application and can act on your behalf.
• Skills instead of code. Business rules written in plain language, like a recipe, that the agent follows the same way every time. At Aurora, the audience came up with rules for putting together a project team, and we turned them into a working skill during the next presentation, without writing a line of code.

The questions we can’t answer yet

We want to be honest about what nine days can and can’t prove.

How does it hold up in production? The real test starts this month, when Phoenix sends out its first invoices. We’ll report back.

How about security implications? As AI models become better, they do their own security checks, and output more so called finished code. But what is the risk of security leaks passing unnoticed?

What does a project like this cost in real life? Phoenix was built by 30 people working long, intense days in what we called “the pressure cooker”. Afterwards, Rein summed up how the team felt: “proud, amazed and very tired.” We would not recommend running a company that way for many weeks a year. The real question is what a project like this looks like at a sustainable pace, with a normal team and a normal budget. We’re working that out now.

Will companies still buy software? If everyone can be a plumber, why hire one? We don’t have a crystal ball. Our bet: just as more efficient steam engines didn’t lower the demand for coal, cheaper software will make a lot of applications worthwhile that never had a business case before. Expertise in turning user needs into a working application will matter more, not less.