The Business Models of Digital Work in AEC
Which is better, product, service, or a bit of both ?
If you haven’t been following along, about a month ago I announced that I started my own firm, CodedConstructs.
But before leaving a stable job, one of the biggest decisions I had to make was the business model of the whole thing. This is something I think about for everything I do anyway, but I wanted to understand how digital work in the Architecture, Engineering, Construction (AEC) industry actually makes money.
It’s all well and good to build things and solve cool problems, but how do we not only make money but build a sustainable and profitable business by doing so?
That is the question I set out to answer. There are several existing models to learn from, some of which I have experienced personally.
The internal tools and projects model (a team or company that supports internal tools alongside external services)
The product then support model (build a product that someone will use, then charge a service to help/teach them to use it)
Custom coaching and making courses (Teach people, don’t do the work for them)
You can of course mix these too, like Timo Harboe who takes on projects but has created a course. And you also have the pure ones, like pure service (like most consulting firms) or pure product (normal software firm). But they don’t need any new explanation because they tend to lean towards the more conventional firms we already know so well.
What I set out to find out is how I want to operate in this world, that can change but it helps to get the lay of the land first.
Hi, I’m Braden
I help teams be more efficient in the AEC Industry, then share stories about it here. I also have courses, guides and scripts as part of CodedShapes Pro
Check it out if that sounds like you.
If you’re new to CodedShapes, welcome! You might enjoy these:
The internal tools and projects model
This is arguably the most popular model out there. Whether it was intentional or not, it’s the way most consulting firms (the ones that bill by the hour on projects) already operate. So when it came to digital work, they just applied what they knew.
On the surface, it’s perfect. Do projects most of the time, then work on internal tools during the down time. Technically, you’re fully resourced. Fund the internal tools with the extra margin from projects. When executed perfectly, it makes for a great cycle. Make more money on projects -> develop more tools -> you’re more efficient, which leads you to make more on projects and so on.
But there’s a huge flaw, and it’s something I have written about many times. When you put paying billable projects up against non-paying internal tools, billable always wins. We all have a finite amount of time, so the work that makes money directly always wins. So, instead of working on tools during the down time, most people spend it finding more projects. And “doing internal tools only during down time” ignores the maintenance and emergency fixes that come with tools.
“From 1995 through 1998, approximately 87% of the product ventures initiated by software-service companies were unsuccessful. […] Inappropriate transfer of organizational practices and development culture from the service sector to the product sector is a recipe for failure.”
— Satish Nambisan, Why Service Businesses Are Not Product Businesses, MIT Sloan Management Review (2001)
When you have the urgency of projects breathing down your neck all the time, you can’t build great tools.
A common band-aid here is to treat building tools as a “project”. As in, block out 4-6 weeks for development, deploy, then move on. But then the questions of maintenance and ownership come into play after the tool is built. What happens when the tool fails? Who maintains it if it isn’t anyone’s full-time job? If you’re hopping from project to project, how can you make time to support tools?
If you teeter between billable projects and maintaining internal tools, I’ll stress it once more, the billability of projects will always win.
But, I am not saying it’s impossible. I’m saying that it’s a constant uphill battle to convince the always urgent project natured people that you can’t help them because you’re working on an internal tool.
When I worked for a structural consultancy, I found it hard to fight for development time, because it meant pushing away work that directly made money. And this isn’t just my experience. AEC Magazine, writing about firms that build their own tools, pins the friction on exactly this: “the mindset of managers, which strictly adhered to the concept of allocating project billable hours to employees” runs against the craft-based mindset needed to build great tools.
Nate Miller, who runs his own company, Proving Ground, says it more bluntly: “the business model of architecture and engineers… is, in some ways, incompatible with the business model of running a software company.”
The two operating philosophies are diametrically opposed. And if projects make up the majority of the firm, it’s easy and common to be scrutinised, sometimes even punished, for operating against that. As valuable as the internal tools are, the current way to create them goes against the operating norms of most service-based companies.
Which is why the firms that actually produce commercial tools tend to split it out. Thornton Tomasetti, a large structural engineering firm, built an interoperability tool called Konstru that became its own independent company. Decades earlier, Arup did the same by spinning out Oasys as its software arm. Even a smaller firm like IDA Architects noticed this and created IDA Technology for their digital work.
The pattern, then, is that service firms which build successful products tend to wall the product off from the billable work so it can exist on its own. Having a barrier between the two ways of operating seems to be the key here.
The product and support model
The second model is about building a tool and then selling the maintenance and support as the service. It’s the reverse of the previous model, where a product was treated like a project.
The idea is to build a tool that people will pay to use, then sell them a separate service to help them actually use it. People buy the licence to use your product, but if they want updates or expert advice or custom work, they pay extra.
Strand7, the finite element package a lot of structural engineers use, does this. They sell you their program and also offer Strand7 Support and Maintenance as a separate subscription. For that you get a support hotline, a model review service where you can send them your actual model to look over, and every update released while you stay subscribed. They even run paid training on top of that, because the software is complex enough that it takes real expertise to use well.
Oasys, the same Arup software arm from before, does the same thing. You buy a perpetual licence, then pay an annual maintenance contract priced as a percentage of the list price to keep the support and updates coming. It also works well for them because Arup offers structural advice, and Oasys becomes a kind of “locked-in” inbound marketing tool.
Autodesk does a similar thing, offering not just their software but custom training, developer support and certification on top.
And the money on the service side is bigger than you’d think. Or at least it was, for me. Julien Bek of Sequoia put it plainly: “for every dollar spent on software, six are spent on services.” The product gets you in the door; the ongoing help is the larger market. The crude way of saying it is that once people are locked into using the tool, they’ll pay for anyone who helps them use it better.
That’s why this model holds up so well. You get the leverage of a product, build it once and sell it many times, and the stickiness of a service, a relationship that renews every year. It smooths out the lumpiness of pure project work, and it means the software brings in recurring revenue.
The “services-as-software” idea is getting a lot of attention right now, because as products get easier to build, the value shifts to showing people how to best use them. As Foundation Capital describes it, “what you build is no longer your moat. How you integrate, embed, and operate becomes the moat.” The support layer becomes more of the thing you’re actually selling.
What I like about this model is how honest it is about the work. Building a comprehensive tool and helping people use it are two different kinds of value. It’s the do-it-yourself vs do-it-for-you (or with you) approach.
Know the software well? Great. Need some help? Also great, because we offer that too. It also fixes the maintenance problem from the last model. The never-ending tail of features and bugs stops being a drain on your margins and becomes the thing people are paying for. This model makes working on the software and teaching people to use it billable.
But it’s not all glory. The biggest downside is that you need to invest in building a comprehensive tool, because if it’s intuitive and simple, why would anyone pay you extra to help them use it? And you have to make sure what you’re building is legitimately useful.
It means that before you even offer support or maintenance contracts, you need to put a lot of work into building a complex but useful product. Some products organically become this, but if this is the model you’re after, you have to plan for it.
And to bring home a point from the last model, you can’t just decide to do this if you’re a primarily service-based company. When Ramboll turned an internal tool into a commercial product, SiteSolve, Paul Jeffries described the jump as: “selling software commercially requires a whole new level of quality assurance, documentation, training and interface... we’ve gone further than we would have ever gone if we weren’t going to sell it.”
It’s the reason Strand7 and Arup can offer it: their programs are so comprehensive that there might be hundreds of ways to get to the same result, but only a true expert would know how. You end up paying for that expertise twice, once in a useful but complicated product, and again in the help to actually use it.
The coaching and training model
The third model steps away from tools entirely, but you can see it in the same light of services and products. Custom training workshops or coaching would be the service, and the self-paced courses would be the products.
I don’t consider this a “pure” business model, because it’s a relatively new one. With the internet, it’s something a lot of digital people are already doing. It’s also the one I’m already partly doing, with this newsletter and its paid version.
Hopific, run by Thomas Tait who spent years at Snøhetta, sells a self-paced Grasshopper course for a one-time $197 with lifetime access. Learn Grasshopper, arguably the most famous one around, does the same with a whole ladder of self-paced courses, from Grasshopper basics to Grasshopper in Tekla and Python for AEC. Timo Harboe from before, who runs his own practice, set up Python for Structural Engineers the same way, a one-off £398 course built with fellow engineers.
Instead of selling software, you sell courses. Different contents, but still products.
And the same argument applies: it can be either a subscription or a one-off. ThinkParametric runs a subscription with a library of 60-odd courses, the same way Junichiro Horikawa runs a Patreon for his computational design tutorials. Even the paid version of CodedShapes sits somewhere in between: you can subscribe for a month, grab all the resources and leave, or stay subscribed and keep getting the updates.
But again, you can’t escape that initial friction. Like products, there’s a lot of effort in making a course or a YouTube channel. And it’s another kind of bet: you’re wagering that enough people will find it valuable enough to pay.
This is made harder because the scale of our audience is a lot smaller than, say, a cooking YouTube channel.
It’s the economics, not the technicality
Line all three models up and you can see the pattern. Building tools, supporting software, teaching courses, it doesn’t really matter which you pick. They all come down to using your finite hours to either serve people (projects, software support, live training) or build assets (software or courses).
Services require expertise and are linear. You get paid for how valuable you are per hour. The only way to be more profitable is to increase your scope or find a way to be more efficient. But the more efficient you get, the more tempting it is to price lower, because being cheaper is a market advantage.
Assets (software or courses) are different. It’s no longer purely about the hours you put in, it’s about the problem it solves. Solve a problem well and repeatedly, and it almost doesn’t matter how many hours went in. But assets are a gamble on whether the thing is valuable enough for people to pay, and they need an upfront investment of your time and sometimes your money.
It’s trite, but this really is the craft mindset vs the service mindset. One means you work on yourself, and because your work is good, people buy from you. The other means you offer your service to someone else because you have expertise to share.
With an asset, you make the thing once and it works for you whether you’re at your desk or not. That’s the dream, but getting there means being willing to risk that months of development don’t pan out the way you wanted.
So the debate isn’t really about choosing the business model or the mindset. It’s about your appetite for risk. Working on projects gives you control and transparency; you can see how your time is spent and how much you earn from it. Building a product means gambling on a problem, but if it pays off, you have something valuable and repeatable.
How CodedConstructs Operates
I am blessed (or cursed) with insatiable curiosity. I love working on projects because it lets me meet more people and solve more interesting stuff, and it’s usually where the best ideas for products and content come from. But I also love to build, and I love to write. I didn’t come into this industry for the projects alone.
So, I am going to be greedy and pick all three. CodedConstructs will be a balance of services, products and content, but they aren’t all equal.
Right now, since I am just starting out, client projects are the engine. They help me figure out which problems are worth solving, and they help me pay my bills. Products and content are the assets I build alongside them, my long-term bets on where I think I can bring value aside from projects.
Eventually, I am going to have to figure out how to build walls between my services and products but I at least know that going in. Because we know if I put billable work against products, and say it with me, billable always wins.
Thanks for reading
Subscribe to CodedShapes to get more articles like this delivered to your inbox
Work with me: https://codedconstructs.com/contact/
Resources on Computational Design: https://www.codedshapes.com/p/scripository