Why two software founders got certified as steel framing installers

In May, my co-founder Pablo and I passed the “Curso Práctico de Instalador de Steel Framing” at CECATEC. One month, hands on. Real materials. Real screw guns, real profiles, real dust.

We’re software developers. We run a company that builds software for AEC firms. Nobody is going to hire us to frame a wall, and nobody should. So why spend a month on a workshop floor learning a trade we’ll never practice professionally?

Because empathy is a technical skill, and this was technical training. If you build software for construction, your understanding of the jobsite is a data source like any other, and most teams collect it badly.

Empathy-driven development, literally

In 2021, Andrea Goulet wrote a piece defining Empathy-Driven Development: “the practice of anchoring decisions on the people impacted by and who interact with what is produced.” Her core claim: empathy is a technical skill you train, with the same deliberate practice you’d apply to learning a new database. Most of the industry still files it under personality.

Her framework lists 12 “efforts.” Two of them stuck with us. Source information responsibly: get your understanding of users first-hand, from the people who’ll live with what you ship. And seek semantic alignment: make sure the words in your software mean what they mean to the people using it.

Here’s the uncomfortable question those two raise for anyone building construction software: where does your understanding of a jobsite actually come from? For most AEC software teams, the answer is a requirements document, a few stakeholder calls, and a site visit where everyone wore clean boots. That’s empathy sourced irresponsibly. It produces software that demos well and fights the user on day one. (We’ve written before about why cheap prototypes don’t survive contact with real users.)

We had noticed a pattern across our own projects: the gap between what our clients needed and what we shipped got smaller every time we understood their actual job more deeply. The physical one, the one with the tools in it. The course was us taking that pattern to its logical conclusion.

What the workshop floor teaches that a requirements doc doesn’t

The hardest part to put into words is how many small aha moments the workshop produced, and how they all had the same shape. Suddenly your mind and your body are working on the same task. It feels like two separate worlds aligning. You can read about steel framing for a week and learn the vocabulary. You learn something else entirely when your hands are on the screw gun and your head is still catching up to them.

That gap, between the part of the work you can read about and the part your body has to learn, is exactly where field software lives or dies.

You learn what your hands are doing all day, and therefore what they aren’t free to do. Nobody on a framing crew is delicately tapping 4 levels deep into a menu with a stylus. If your field app assumes clean, free, patient hands, it was designed by someone who has never had both hands on a profile while checking plumb.

You learn the sequence of the work. Measurement comes before cutting, layout before fastening, checking before closing. Software for the field has to enter that sequence where a pause is already natural. The data model doesn’t get a vote on when that is. Every form that interrupts the wrong moment gets abandoned, and then the office wonders why field data is always incomplete.

You learn that tolerance is a physical negotiation. The model says one thing; the slab the panel lands on says another. The crew resolves that difference in minutes, on the spot, with judgment. Software that treats every deviation from the model as an error to be flagged doesn’t understand construction. As-built and as-designed are different documents for a reason, and the gap between them is where half the interesting tooling problems live.

And you learn the words. What the catalog calls one thing, the instructor calls another, and the crew calls a third. Semantic alignment is the difference between a takeoff the foreman trusts and one they re-count by hand. It’s also why a single source of truth is worth more in this industry than in most.

None of this is exotic knowledge. Everyone who works in steel framing knows it. But almost none of it survives the trip through a requirements document, because the people writing requirements don’t know which of a thousand details matter until they’ve felt them.

Why does domain knowledge matter in construction software?

Because the details that decide whether a field tool gets used are physical, and they don’t show up in a spec. Hand availability, work sequence, tolerance, and vocabulary are all invisible on a requirements document and obvious on a jobsite. A team that has never been on the floor gets all 4 wrong in ways that look perfectly reasonable in a design review and fail in the first week of a pilot.

You can’t write good software for an industry you only know from a screen

This is the sentence we keep coming back to. The AEC software graveyard is full of products built by strong engineering teams who understood the data model and not the work. (It’s the same argument we made about T-shaped knowledge, pointed at an industry instead of a stack.) The BIM pipeline was clean, the viewer was fast, and the tool still died in pilot, because somewhere between the office and the site it made an assumption that anyone with calluses could have corrected in 30 seconds.

Goulet’s framework asks you to pause before decisions and ask who’s on the other side of what you’re producing, what their world looks like, what frustrates them, what they stand to lose. For construction software, that “who” is often someone standing on a slab in the sun, wearing gloves, on a schedule, with a radio signal that just dropped. You can’t simulate that person. You can go meet them, or briefly be them.

That’s the whole argument. Domain empathy in AEC is sourced, like data. And like data, its quality depends entirely on how you collected it.

What we’re building next

Steel framing compresses the schedule hard. Forbes Uruguay puts it at 4 months for a steel structure where concrete takes 12, citing the dry-construction industry association. Run a job 3 times faster and every weak point in your field software surfaces 3 times sooner.

After a month inside the trade we’re convinced the tooling hasn’t caught up. The gap between how the work actually happens and what the available software assumes is wide. We’re already building for it. More on that soon.

There’s a personal payoff I didn’t expect. Over the month I went from being able to hang a frame on a wall to building a wall from the ground up with my own hands, and it honestly feels like a new superpower. I’m going to build a shed in the backyard now, for no reason other than that I can. The calluses are real, and so is the understanding underneath them. That understanding is the part we bring back to the software.

For now: two devs with calluses, anchoring decisions a little closer to the people who’ll live with them.

If you’re building for this industry and want to talk to engineers who’ve been on the floor, we’re here.