Factry builds software that runs on factory floors, real-time data collection from industrial machines. Their previous client implementation had taken 18 months and nearly broke the team. A new client was coming. They couldn't afford to repeat that.
The problem wasn't the technology. The team was capable. The problem was how decisions were made and how work moved through the team.
I didn't rewrite the product strategy. I didn't redesign the architecture. I didn't run a two-day offsite with sticky notes.
I went to the factory floor. I sat with the machine operators who would actually use the system. I built rough prototypes, walked them back through those same operators, and refined the designs before a single line of production code was written. That alone eliminated weeks of rework that had plagued the previous implementation.
On the team side, I found a daily meeting that had turned into an hour-long conversation between one developer and the founder. Seven people sat and waited. The fix: we kicked the founder out. Five one-hour meetings became fifteen minutes each. The harder part: developers had to go ask their questions instead of saving them up. That took a week to stick.
I made sure critical knowledge wasn't locked in one person's head. Got developers answers to blocking questions in hours instead of days. Cleared the small obstacles that were invisible from the outside but were eating the team's time every single day.
The next comparable client implementation took 6 months. Three times faster.
Not because of a new framework or a better tool. Because decisions happened faster, the right people were involved at the right time, and the team stopped waiting.
"He took the time to understand our complex environment and our constraints to propose the best solution for us."
CIB, the federation of Belgian real estate agents, had tried to build this platform before. It hadn't worked. They brought in external developers and the team was shipping code, but there was no structured way to check whether any of it matched what users actually needed.
Decisions were based on whoever had the strongest opinion. Features got built because someone important asked for them, not because users needed them. There was no feedback loop between what shipped and what worked.
I added one thing that was missing: regular contact with the people actually using the product. Conversations, surveys, data. Whatever it took to replace opinions with evidence.
External developers were emailing questions and waiting days for answers from the business side. The fix was simple: the product manager joined their Slack. Response times went from days to minutes. Less stuck work, better flow.
Decisions stopped being about who had the strongest opinion and started being about what users actually needed. The team built fewer things, but the right things. Features that people actually used. Pages that people could actually find.
The platform grew from 10,000 to over 100,000 monthly visitors over two years.
Not because we moved faster. Because we stopped building the wrong things. That focus, shipping fewer, better features, contributed to sustainable growth over time.
"I can't write a single line of code and I don't understand a word the development team says. But thanks to Bart, everyone knows what's being built, why, and when it's ready."
"He sees the unique strengths of his colleagues, helps them grow, and brings them together around shared goals in a way that feels natural."