Field notes from a company-wide rollout: a conversation with a Koddex Forward Deployed Engineer
Koddex's Forward Deployed Engineers (FDEs) sit inside a client's teams for months, not weeks: modeling data, untangling legacy habits, and making sure a new way of working actually sticks.
In this conversation, Thomas Aubert, Head of Revenue at Koddex, interviews Valentin Houssin, Product & Customer Success Lead, who carries the Forward Deployed Engineer role on client deployments. The project they discuss is still ongoing: rolling out Koddex as the engineering backbone for an industrial hardware company of over a thousand people that designs, builds, and deploys complex physical systems at customer sites. Along the way, the company retired its board tools and a series of point SaaS products, cutting its IT bill by roughly 30 percent.
The client is not named here and identifying details have been changed, but the story is real, and so are the scars.
1. The context and the starting point
Thomas Aubert — Before Koddex, what did the client's day-to-day actually look like?
Valentin Houssin — They had a real stack already: a PLM, an ERP, board tools everywhere, a lot of Excel, and an in-house product they had built themselves to track product and part documentation. The in-house tool was actually a good fit for what it was built for, but it only ever covered product and part documentation. Their internal team kept improving it, but obviously not at the pace a dedicated team like ours can. And it was never meant to be reused for anything outside its original purpose, so the data inside it was basically stuck there.
The board tool, on the other hand, was everywhere. Not just engineering. Sales, marketing, deployment teams, everyone was building boards, because it's fast and easy. The problem is those boards all relied on different, manually maintained data, and the way people edited that data was never consistent from one board to another. These are smart people, and day to day they managed to avoid real issues. But the quality of the outcome depended entirely on people being careful, not on the tool enforcing anything.
And this is a company that deploys physical systems at customer sites: the same site could show a different status depending on which board you looked at, or which systems were recorded as installed. At their current size they were catching it. As they scale, that stops being sustainable.
Thomas Aubert — Was there a specific trigger, or was this more of a strategic call?
Valentin Houssin — From what I could tell, it was strategic rather than one single incident. Three things pushed it: they wanted to stop depending on an in-house tool and trust an external, properly resourced solution; they wanted to extend real data consistency and rigor to every team, not just engineering; and there was a very concrete cost angle. Retiring the board tool and a series of other point SaaS products cut their IT bill by about 30 percent, because Koddex could cover those needs instead.
The CEO and CTO championed it directly, and what they kept coming back to was rigor, consistency, traceability, combined with the flexibility to still model things their own way.
Thomas Aubert — More than a thousand licenses, several disciplines, several sites. Where do you even start?
Valentin Houssin — I was based with the central HQ team, which is where most of the use cases lived, with smaller teams at sites abroad. And it wasn't just engineering: boards were used by everyone, from engineers to sales, marketing, and deployment teams. So the very first step wasn't a big-bang technical migration. It was walking through real use cases with the teams, seeing how Koddex would actually answer them, picking a handful, and implementing those first.
Thomas Aubert — Any early surprise?
Valentin Houssin — The biggest one: nobody could fully align on their own processes. At a high level, sure, everyone would say they were aligned. But the moment you dig into a specific process, you get real disagreement. And it gets worse the second you ask "how should we improve this," because now it's not just describing what exists, it's people defending how they've always done it.
2. The reality of the deployment
Thomas Aubert — How did you sequence the rollout, big bang or wave by wave?
Valentin Houssin — Wave by wave, very deliberately. The order was: first, stand up a handful of use cases in Koddex with a few internal champions. Then set up access rights properly. Then set up the sync with the other tools they were keeping. In parallel, keep identifying gaps or missing features with the champions and build those as we went.
Only after that did we plan the migration of the in-house tool into Koddex, and separately, plan the migration of the existing boards, since the board tool was being shut down entirely by the end of the year.
Thomas Aubert — Which teams came on first, and which were hardest to convince?
Valentin Houssin — Technical teams were faster. They could see the advantages of Koddex more easily, it spoke their language. Business teams, meaning sales, marketing, more operational people, were harder. Some of them got it quickly once they saw it in action, but overall there was real fear: Koddex is a young product, so there's a "new, unproven product" fear layered on top of ordinary fear of change. Change management here is a genuinely big part of the job, not an afterthought.
Thomas Aubert — Give me one concrete resistance story.
Valentin Houssin — The one that stuck with me: someone told me, essentially, "you (the client's IT team) didn't ask us what we needed, you just handed us Koddex and told us it would solve our problems." That's a fair criticism if that's how it lands.
What actually turned it around was doing a live demo on their real data, discussing their needs one by one, and, this part mattered more than the demo itself, asking them why they did things a certain way in the first place, and then working with them to actually evolve the process, not just digitize the old one.
Thomas Aubert — Where does "deploying a tool" stop and "changing how people work" begin?
Valentin Houssin — Honestly, we're still in the middle of that right now. Change management isn't finalized. My honest expectation is that it'll be harder with people out on-site, operational staff who are less comfortable with IT tools in general, compared to people at HQ who are already used to structured software.
Thomas Aubert — Was there a moment you thought "this isn't going to land"?
Valentin Houssin — Yes. There was a stretch where it felt like they would simply never align on a key shared process, and without that alignment we couldn't move forward with integration or modeling at all. Modeling in Koddex requires agreement on what the process actually is. If the client can't agree among themselves, you're stuck before you've even opened the tool.
3. Technical and business requirements
Thomas Aubert — What client requirements actually pushed the product itself to evolve?
Valentin Houssin — Two clear ones. We accelerated our roadmap on dashboards specifically so they could drop their board tool and get more buy-in from users. Dashboards have a genuine "wow" effect that a spreadsheet replacement never gets. And we added notifications to support more collaborative ways of working, which wasn't as much of a priority before this deployment.
Thomas Aubert — How did you handle migrating existing data: requirements, BOMs, modification history?
Valentin Houssin — The hardest part wasn't the data itself, it was understanding their in-house product first. People had misused it, quietly forcing their own process into a tool that wasn't built for it, using informal, human conventions nobody had documented.
We had to sit down with employees, understand why they were misusing it that way, what need that misuse was actually serving, and then figure out how to answer that same need properly in Koddex instead of just replicating the workaround.
Thomas Aubert — How do you guarantee data consistency across teams that don't share vocabulary or priorities?
Valentin Houssin — Koddex's modeling is rigorous and flexible at the same time. Teams can model things exactly the way they need to, nothing is forced on them by default. That's genuinely great, because nothing is set in stone. But it comes with a real cost: people have to actually sit down and align with each other first, and modeling does require a bit of modeling literacy. Which, to be fair, is the easy part for us, we can train that quickly. The harder part is the alignment.
A concrete example: the definitions of "article," "product," and "part" were not fully consistent between manufacturing, sales, and the product teams. Same words, different meanings, depending on who you asked.
4. Where things stand today
Thomas Aubert — What's measurably changed so far?
Valentin Houssin — I'll be straight about this: integration and migration aren't fully finished yet, so I don't have a clean before/after number to give you, and I'd rather not invent one. What I can say concretely: they've already migrated most of their QMS, most of their IT architecture documentation, some cross-referentials, a full tracking system for customer sites, and many other use cases. Those are real, already-live wins, even if the overall rollout isn't complete.
Editor's note: the main migration, moving the in-house tool's data into Koddex, is still ongoing. It is where the largest impact is expected.
Thomas Aubert — What feedback stuck with you the most, good or bad?
Valentin Houssin — On the harder side: the concepts of "model" and "item" aren't always intuitive, and the interface still isn't as smooth as category leaders like Monday or Notion. That's fair feedback and it's the honest tradeoff of a tool built for rigor over a tool built purely for ease of first use.
Thomas Aubert — What can teams do today that they simply couldn't do before?
Valentin Houssin — The clearest example is the deployment project itself. Sales sells a system to be installed and gets the contract signed. The deployment team then defines the actual execution: which systems to install, third-party parts to buy, site preparation work, and so on. Then the maintenance team takes over.
Before, these three teams were effectively looking at three different versions of the truth. Now they can all look at the same project, at whatever stage it's in, and it's always the same underlying data. That's not a speed improvement. That's something that just wasn't possible before.
"Before, these three teams were effectively looking at three different versions of the truth. Now it's always the same underlying data."
5. Lessons and hindsight
Thomas Aubert — If you had to redo this deployment tomorrow, what would you do differently?
Valentin Houssin — I'd define a much clearer step-by-step plan up front: what needs to happen, by when, by whom, exactly what we expect from the client at each stage, and when. I'd schedule learning sessions deliberately instead of fitting them in reactively. And I'd define a clear, staged onboarding plan with the client from day one, instead of building that structure as we went.
Thomas Aubert — What did this teach you about what makes adoption succeed or fail?
Valentin Houssin — Two things, really. First: real success comes from quickly proving that Koddex will improve something specific for them. Once people have seen that proof, they're willing to put in the effort. Second: team alignment is not optional. Koddex implements processes, so if the process itself isn't defined and agreed on, there's nothing solid to model.
Thomas Aubert — What would you tell a VP Engineering at a ~1,000-person company who's hesitating?
Valentin Houssin — It requires real effort, but the payoff comes quickly. Start by identifying an actual pain point and proving, on one small use case, that Koddex solves it. Don't try to sell the whole vision on day one. And avoid the temptation to migrate everything at once. Go step by step. Every team that tried to skip that ended up regretting it.
Key takeaways
The cost case was real. Consolidating board tools and point SaaS products into Koddex cut the client's IT bill by roughly 30 percent.
Sequencing beats scope. The rollout went wave by wave, starting with a handful of real use cases and internal champions rather than a big-bang migration.
The hardest obstacle was not technical. It was getting teams to align on their own processes, because Koddex models processes and cannot model disagreement.
Proof unlocks adoption. Early, concrete proof on one specific pain point is what buys the effort teams need to put in afterwards.
The most durable win is structural. Sales, deployment, and maintenance now work from a single version of the truth instead of three.
