When a bridge engineer opens OpenBridge Designer, they see a finished capability in bridge design and structural analysis software. A workflow feels sequential, a command behaves the way you’d expect, a new analytical feature solves a calculation problem you’ve wrestled with for years. What you don’t see is the rigorous, multidiscipline validation that happens before that capability ever reaches a release.
I recently spent several days with Bentley’s bridge development team, led by Burak Boyaci, in Iași, Romania. I went as a product marketer, not a software engineer, curious to see how infrastructure software for bridge design actually gets built. What I found wasn’t programmers quietly working through a list of requirements. It was a room full of people debating about how physical-world engineering should translate into digital logic.
Every OpenBridge Designer feature starts with a debate, not code
For most of the week, product managers, structural bridge experts, software architects, and developers sat around whiteboards and screens, and they weren’t talking about interface details. They were testing engineering assumptions. Would this sequencing feel logical to a bridge designer managing design and construction phases? Does this modeling approach match how prestressed concrete behaves under load? How should the structural analysis model connect to downstream geotechnical data?
Every proposal got tested against the judgment of engineers who will eventually have to sign off on the structural integrity of a physical asset, sometimes with their own license on the line. In infrastructure, you don’t build a feature because it’s novel. You build something engineers can trust with people’s lives, and that trust has to be earned in the room before it ever reaches code.
Translating bridge engineering knowledge into software logic
What struck me was the friction between the different disciplines at the table, and how useful that friction actually was. The bridge experts held the line on design intent, physical constraints, and regulatory standards. The product managers kept dragging the conversation back to what transportation agencies and engineering firms actually deal with day to day. The architects and developers pushed back on scalability, algorithmic efficiency, and whether the data would still hold up structurally five years from now.
Watching this made something clear to me: building engineering software is fundamentally a translation exercise. You take decades of empirical engineering knowledge, rigid design standards, and hard-earned field experience, and you turn it into algorithms and workflows that thousands of engineers around the world can run consistently, on high-liability calculations, with no room for error.
From whiteboard validation to working code
The best moment of the week was watching the arguments from the whiteboard show up as actual code the next day. The developers weren’t off working alone somewhere. They kept checking their prototype builds against the domain experts in real time, adjusting as soon as something didn’t hold up.
Within about a day, debates about software workflow that had existed only as sketches and arguments were running in a prototype environment for bridge design workflows, so everyone could see how the idea actually behaved instead of just how it sounded on paper. It reminded me that building software for critical infrastructure isn’t linear. It’s validation against physical reality, digital experimentation, checking the math, and doing it again.
Why in-person engineering collaboration still matters
Bentley builds software across teams scattered around the world, like most companies its size. But spending a week actually in the room showed me what gets lost when engineering decisions happen only through email. Questions that would normally take a week of back-and-forth got resolved in minutes with a hand-drawn structural diagram, doing more than three separate spec documents could have. Developers could check an analytical assumption with a bridge engineering specialist on the spot, while product managers kept the conversation anchored to what engineers actually need. The real benefit wasn’t speed. It was that the decisions coming out of that room were simply better.
Designing software for how bridge engineering actually works
One thing came up again and again that week: a bridge design never exists on its own. Real infrastructure delivery means roads, geotechnical profiles, structural analysis, and digital twin delivery all must work together across the asset’s entire lifecycle.
Building software for that means looking past individual features and understanding how engineering data actually moves through the whole project, not just one phase of it. That’s exactly why the team cares so much about open, interoperable workflows that fit how multidiscipline engineering already works instead of asking engineers to bend their process to fit the tool.
It takes more than programmers to build trusted engineering tools
Leaving Iași, I wasn’t thinking about the code so much as the mix of people behind it. It takes real structural engineering depth, serious software architecture, and a genuine understanding of what goes wrong on real projects to build tools like this. Together, that group turns hard physical problems into software that lets engineers design, analyze, and deliver infrastructure with confidence earned through validation.
Engineers will eventually just see this as a software update. They won’t see the marked-up whiteboards, the arguments over structural assumptions, the fast prototype cycles, or the hundreds of small validation checks that got it there. But having sat in that room, I know that’s exactly why the software still holds up once the concrete actually gets poured.
