Audio article narrated by OpenAI
Ben James’s path runs from the lab computer to the other side of the glass. He used SPACE GASS as a student who didn’t yet know what the software was, then as a practising structural engineer at boutique firms and at AECOM, and finally as the founder of his own consultancy during COVID. At some point in that arc, he issued the most literal change order possible: he stopped being the person who used the tool and became the person responsible for it. The publication keeps returning to the gap between seeing what’s broken and being allowed to act on it; Ben’s crossing inverts the usual version of that story, because what he inherited was not a problem to fix but a 40-year-old asset he had to be careful not to spend. What follows is a conversation about stewarding trust you didn’t build, why a battle-tested legacy becomes the real moat once AI turns features into a commodity, and how a structural engineer thinks about keeping the human inside the loop.
About Ben James
Ben is CEO and Managing Director of SPACE GASS, the structural analysis and design software founded in Australia in the early 1980s and used by structural engineers across more than 70 countries. He spent roughly 15 years as a practising structural engineer, moving from boutique firms to AECOM before founding his own consultancy, N Positive, during the pandemic. He was recruited by founder Peter Schulze to lead the company, which is now a subsidiary of Sweden’s StruSoft and which acquired Structural Toolkit in 2024. Ben is unusual among software CEOs in that he ran the product as a customer for his entire career before he ran the company.
—
“If everyone has the same product, what differentiates us? It’s our connection to our existing customers. A fresh competitor with AI doesn’t have that.” Ben James
—
Ben had seen the SPACE GASS role advertised and filed it away as the kind of job one admires from a distance. He didn’t know Peter Schulze. He had never worked with him, had no warm introduction, no prior connection at all beyond being a customer who had used the product at every firm he had ever worked in. Then Peter messaged him directly on LinkedIn asking for a phone call.
“As a structural engineer, SPACE GASS is basically an institution. I was in university and that’s how I first got exposed to structures. I’d had it at every firm, including my own. So I had a really strong connection to the product.”
What made the decision land was less the opportunity than its rarity. Giving up a consultancy he had built during a pandemic, with all the investment, insurance, and personal exposure it involved, was not a small thing, and he says plainly it took him a long time to transition. But he ran it through a long-term lens, and the maths changed.
“When’s the next time SPACE GASS is going to be looking for a CEO? It’s a once-in-a-career opportunity. I love consulting, but I can always go back to that. I might never get a chance to do the SPACE GASS role again.”
His wife fully backed him; others questioned why he would leave a firm he had only just built. That tension is worth sitting with, because it is the quiet cost underneath the clean career narrative. The transition from practitioner to vendor is irreversible in a specific way: you trade the credibility of I do this work for the responsibility of I build what they use to do this work. In structural engineering, where the output determines whether something stands, that is a heavier kind of accountability, not a lighter one. Ben didn’t take the job because he was tired of engineering. He took it because the product was an institution, and institutions don’t come up for stewardship twice in a career.
Don’t break it: the discipline of inherited trust
The constraint Ben identifies is the new leader’s instinct to arrive and replicate what the founders spent decades building. SPACE GASS was written by structural engineers for structural engineers, originally in Fortran; Structural Toolkit, the product SPACE GASS acquired in 2024, was developed the same way by its founder, Tony Furr. That kind of accumulated experience can’t be replaced by someone showing up with strong opinions.
“Step one is, don’t break anything. I don’t need to come in and revolutionise everything from day one and put my standpoint. I need to just listen and learn and not ruin the legacy of the two companies and products.”
So his first goal was not a roadmap. It was to become one of the names customers already knew. Email SPACE GASS and get a familiar name you know. Step one of the job was to earn a place on that list, to take over the trust rather than disturb it, and to learn how things were done internally before changing them.
This reverses the usual startup posture and flips the trust dynamic. A startup builds trust from zero, slowly, one user at a time. Sam Carigliano described that process precisely in an earlier conversation about earning credibility in a cloud-first product: trust as compound interest, building slowly at first and becoming the most valuable asset over time. Ben is sitting on 40 years of that compounding, accrued by those before him. His problem is the opposite of building it. It is not spending it.
“What differentiates us from a new company or a competitor is rooted in how long we’ve been around and the trust customers have in the product. I’m kind of sitting on the trust that’s been built by Peter and the team. So how do I not take away from it at all? I just have such a long-term view.”
The long-term perspective isn’t decoration. It’s load-bearing, and it’s backed by StruSoft, which doesn’t push for quarterly results. Think far enough out and decisions clarify: rushing market strategies stops making sense; trimming essential features for margin looks wrong; a licensing move that reads cleanly on a spreadsheet but feels wrong to the customer who has been there for 15 years doesn’t survive the decade test. Every decision gets run through one question: what does this look like to that customer a decade from now?
Staying close to the people who do the work
The differentiator Ben names isn’t really a strategy. Tony Furr and the Structural Toolkit team would speak to every lead and every customer three, four, five times across their journey. Ben still personally runs the basic in-person day training courses, and users are visibly surprised when the CEO teaches the class.
“Everyone’s kind of surprised when I turn up to do it. I’m a user of this. We’re all very flat, we’re all really close to the customer.”
The reason this proximity is structural rather than deliberate is simple: the team is almost entirely structural engineers, many of them from consulting. They are not gathering user intelligence. They are talking to people who share the same calibration, who remember the same half-intuited workarounds and the same Thursday-afternoon moments when a calculation isn’t quite adding up and you need to know the software is right. They speak the same language, carry the same scar tissue, reach for the same instincts. The closeness isn’t manufactured. It’s where they came from.
“It’s really easy to fall into that trap where everything looks good like a digital funnel and a spreadsheet. When a big international player comes in, you can’t pick up the phone and get the CEO. So not losing that connection, that is really our differentiator.”
That last sentence reads easily as a customer-service proposition. It isn’t. The trust Ben refuses to spend is generated, conversation by conversation, in exactly these interactions. Lose the proximity and the moat erodes from the inside while the spreadsheet still looks fine.
Running a stable product is a different problem from running a startup. There is no frantic iteration to find what people want; people already love it. But every customer has a list of 20 improvements, and the hard part is not implementing features.
“I see now the most complex thing is actually the big picture. We can’t just keep adding buttons and features all through the product. Some are big changes, some are small. That’s a really big challenge.”
The complexity isn’t in adding features; it’s in knowing which features earn their place in an interface where every addition is also a cognitive cost paid by users who never asked for it.
The team being engineers mostly makes that harder, not easier. Strong internal opinions are mostly an asset; the risk Ben names is his own. After four years on the vendor side, he may already be drifting from how the work is actually done in firms today. So they run a rolling three-year roadmap, re-evaluated annually, and they keep talking to people, because the alternative is the classic failure: strong product vision unchecked by the people it’s meant for.
“It’s good as product leaders to have a strong vision and opinion of where it’s got to go. But if you don’t listen to everyone for long enough, you’ll make that mistake, put it out there, and nothing will happen.”
The cleanest illustration surfaced through Structural Toolkit. Some engineers want full transparency, every line of calculation visible, the page dense with the working. Others want none of it.
“Some people just want the answer. They want it all collapsed, green button, green at the top, move on. Software is a means to an end. And for some people, it’s really the journey. It’s how they think.”
That split, Ben notes, runs through everything: software as a means to an answer versus software as the thinking itself. It is also where engineering conviction gets dangerous, because a product leader who is sure he knows which kind of user is right will build for half his market and quietly lose the other half, since the thousand people who love a change rarely write in to say so. The discipline is to hold a strong internal view, run it through a team full of engineers, and still go and check.
When features become a commodity, trust is the moat
Ben freely concedes the arithmetic: a competent person can set up a web-based finite-element program in a short time frame using open-source components and use it day to day. The individual feature is becoming a commodity. If software is becoming buildable on demand, what is left to differentiate a 40-year incumbent?
“In the era where features are a commodity, trust is everything for us. That’s why I put every decision through that lens. If everyone has the same product, what differentiates us? It’s our connection to our existing customers. A fresh competitor with AI doesn’t have that existing connection.”
This is the same conclusion that vertical-software operators have reached watching what LLMs destroy and what they can’t. The defensible moats are not learned interfaces or clever features; those are exactly what a new entrant can now replicate. The moats that survive are proprietary data, regulatory and compliance depth and accumulated relationships. A 40-year product like SPACE GASS already holds all three. This maps onto a broader shift the industry is still processing: when speed becomes a commodity, value stops accruing from what you can generate and starts accruing from what can’t be generated at all. The calculations a structural engineer trusts at signing time aren’t more accurate because they were fast; they’re trusted because of who made them, what stands behind them, and how long that answer has held.
For SPACE GASS, the moat has a second component beyond relationships: the engines themselves.
“Even if I took AI to its ultimate conclusion of generating software on the fly, it’s still going to want to use trusted, verified engines to produce answers. And engineers will want that. We’re just going to hold on to them [our trusted engines] and develop them.”
The weight of a large legacy codebase is a real cost; Ben doesn’t pretend otherwise. But the same legacy that slows you down is also a 30-year-old, battle-tested foundation to verify against. In a world where any agent can generate a plausible answer, having something trusted to check it against is no longer technical debt but an asset. The thing that makes you slow is the thing that makes you safe.
When AI is bolted onto a workflow that’s already broken
The conversation opened where most honest conversations about AI in this industry end up: on the gap between how fast the technology moves and how little the daily work has changed. The complaint isn’t that the tools are bad. It’s that they keep getting added to a process nobody has paused to redesign.
The example is the one everybody recognises. AI now reads drawings to build a model. Other AI reads the same drawings to check that model. The drawing remains the final source of truth, so every clever new layer is really just a faster way to move information through a relay that nobody questions. The consultant builds a Revit model and exports PDF drawings; the builder reads the PDFs and hands them to a steel detailer; the detailer builds a second 3D model and produces a second set of drawings to send back to the engineer to check.
“How is the drawing created? Where did it come from? What’s the data it came from? What’s it connecting to?” ; Ben James
Those are the questions that the new tooling tends to skip. Ben reframes the whole thing as a level error: the industry treats a systems failure as if it were a component failure.
“It’s a systems problem. It’s not one individual component. It’s so hard to make the whole entire industry shift to something that would benefit everyone. There’s so many rigid workflows and vested interests.”
This is the exact distinction Sangeet Paul Choudary draws in Reshuffle between an AI-native firm, designed from the ground up to integrate AI into core workflows, and an incumbent layering AI atop old systems. The danger isn’t the model; it’s the silo, as the sector keeps “optimising the wrong problem” by bolting AI analysis onto each disconnected store of data rather than fixing the fact that the data doesn’t travel between them.
Where Ben lands is pragmatic rather than utopian. The technical data layer will stay hard; that won’t be solved soon. But the volume of RFIs and rework generated purely by people and tools failing to communicate is enormous, and that is where AI can earn its keep first.
“Maybe collaboration is the low-hanging fruit. The amount of work in RFIs and changes generated just by a lack of collaboration, you’re totally right. Maybe just focus on that first.”
The point is not that AI can’t help. It’s that the help worth chasing right now is connective, not computational. The data already exists. It just doesn’t move.
The API built for customers that happened to be ready for agents
SPACE GASS is releasing its API, and Ben is emphatic about why.
“We didn’t release the API for AI. We released it because customers have been long asking for it.”
The historic scripting engine and text files already let people automate a great deal; plenty of customers did exactly that. But as engineers moved into Python, and as Grasshopper and computational design spread, a clean API became necessary rather than nice. It is a substantial job, because the original product wasn’t architected with tidy layers; results are often calculated on the fly rather than stored, so exposing them cleanly is a large piece of work, bundled here with a new solver that is 10 to 100 times faster on certain operations.
The timing is the quietly remarkable part. An API built to solve a stated customer problem turns out, by accident, to be readable by agents exactly when it is also needed.
“If you’ve got a really well documented API and clean modules, the MCP server works really well, and the agents can group together the tools. Engineers say MCP and they don’t know what it means. But show them a demo of Claude grabbing data from a SPACE GASS model to do a pad-footing calculation, and they love it.”
There is a lesson in discipline buried in this. The right move was not to build for AI; it was to solve the problem the customers had actually been naming for some time. AI-readiness came free, as a byproduct of doing the unglamorous, long-requested thing well. Had the team designed for the AI workflows of 18 months ago, Ben suspects they would have built the wrong thing. Solving the real, stated problem is what left them positioned for the one nobody had stated yet.
The human gate and the traceability layer
Ben is, by his own account, firmly in the human-in-the-loop camp, and he is precise about where the line is drawn. An LLM is the wrong tool for calculating a beam’s capacity per AS 4100; that requires deterministic code that returns the same answer every time. What AI is good for is moving data back and forth among the three to five disconnected tools on a project and improving collaboration and translation between them.
“An LLM is not the right tool to calculate the capacity of a beam to AS 4100. Battle-tested deterministic code that gives you the same answer every time is. But how you get the data back and forth from that layer, AI can play a part.”
This is the same dual architecture that serious builders in high-stakes domains keep converging on: a deterministic, compliant, auditable engine paired with a learned contextual layer, and a human able to inspect the trace between them. Francesco Iorio described the equivalent split at Augmenta as a procedural brain that strictly follows the rules, alongside the abstraction of an expert field technician, deliberately built on a bespoke model rather than a general chatbot, because a mistake in an engineering design can cost millions in rework and pose a safety problem.
On the future where an agent spins up hundreds or thousands of model runs, Ben is genuinely enthusiastic. Asynchronous parallel analysis, multi-parameter optimisation for carbon, steel weight, buildability, the kind of exploration no engineer has time to do by hand: that is a great job for computers. But it has to return through a gate, and the gate model comes straight from software engineering.
“If you can’t trace it and you can’t track it, you can’t be accountable, you can’t have verifiability. Maybe you don’t need all thousand model runs stored, but you need the gate of the answer at that point: I engineered this, store it as a point in time.”
Git, work trees, diffs, merges: the value of those tools is not that they run code, but that they make what happened inspectable and accountable. Apply the same logic to structural work and you don’t need the thousand discarded options retained; you need the chosen answer recorded as an accountable, point-in-time record, with the trace intact. Where did this calculation come from? Who checked it? Is this SPACE GASS model up to date with the current BIM model? That traceability through the whole stack is what actually generates engineer trust, and it is what separates a product that does useful work from a chatbot novelty.
“I don’t think the chatbot thing helps anyone speed up their deliverables. We have to have an actual benefit to the end user. They need to do their job at higher quality or faster, otherwise why would they adopt the tools?”
It is a quiet but firm rejection of AI theatre. The bar is not whether the model can talk about the structure. It is whether the engineer’s deliverable is better or faster, and whether the path to that answer can be traced.
Specification gaming and the cognitive monoculture
Two risks surfaced in the back half of the conversation, and Ben affirmed both as real. The first is specification gaming. Tell an agent to minimise the steel cost of a frame and it will minimise the steel cost of a frame, satisfying every mathematical code check while producing something geometrically bizarre, a constructability nightmare, or unstable in a way the model never captured. This is Goodhart’s Law in structural form: when the measure becomes the target, it ceases to be a good measure. The intent and the metric come apart, and only guardrails and engineering judgment keep the optimisation honest.
The second is cognitive monoculture. SPACE GASS is built for Australian and New Zealand codes and conditions. If agents reach for generic global LLMs trained mostly on the largest, mostly US, players, the reasoning will be confidently inaccurate for local realities, a Queensland cyclone category being the obvious example. Ben’s answer goes back to judgment.
“That’s the trap. It doesn’t replace your thinking. Otherwise we’d get to this monoculture solution where everything’s not quite right for the local industry.”
It is no accident, he notes, that structural software has tended to have individual market leaders rather than a single global winner; the way a market’s engineering actually works is too specific to be abstracted away. The flip side is that a genuinely good agentic solution could open new markets, and Ben acknowledges the pull. But the caveat is the same one the whole company is built on.
“You can’t skimp on going into that market and understanding those engineers deeply. That’s what separates us from all the other players, that we have such a deep connection to our users. Maybe that holds us back from expanding to lots of markets. But good products are good products.”
That is a remarkable thing for a CEO to say out loud: the deep local connection that is his moat might also cap how large the company can ever get. He is at peace with the trade-off, because the alternative, a generic global model giving subtly wrong answers across thousands of projects at once, is the failure he is most determined to avoid.
The asset that slows you down is the asset that saves you
Trace the arguments and they close into a single loop. The industry’s core problem is that AI keeps getting bolted onto broken workflows, so the real near-term value is connective rather than computational. Connection, in turn, is precisely what a 40-year incumbent already has and a fresh competitor cannot fabricate; it is the trust Ben inherited and refuses to spend. That trust is generated in the unglamorous proximity of picking up the phone and teaching the day course, and it is verified by deterministic engines that have been correct for 30 years. The same legacy codebase that can be complex to iterate on is the foundation that makes its answers safe to check against, which is why what slows it down and what keeps it safe are the same property viewed from two sides.
The deeper signal is about where defensibility lives once software becomes buildable on demand. When any competent person can generate a finite-element program, the feature stops being the moat and the relationship becomes it; when any agent can generate a plausible answer, the trusted engine to verify against stops being technical debt and becomes the asset. Both shifts point in the same direction: value migrates from what can be generated to what can be trusted. A practitioner who spent his career on the using side of the glass, and then crossed to the building side, turns out to be unusually well placed to see it, because he knows from the inside that what an engineer is really buying is not the calculation but the confidence to sign their name beneath it. The local judgment that caps the company’s size is the same judgment a global model cannot replicate, which means the ceiling and the moat are, once again, the same wall.