I was watching TV after dinner when I heard my phone buzz on the table.

So, like clockwork, I picked it up to check. I had a new email.

It was from Daniel (not his real name), a potential client I’d spoken to the week before. I’d just wrapped up some discovery work for his firm and sent him a proposal.

I was actually surprised at how quickly he responded. I had been planning to follow up too. Anyway, I was proud of this proposal. I had done my research, explored what was possible and believed the tool we were about to build would be good for both of us. It would improve his workflow, and I sure could use the money. Him replying this quickly sounds like good news.

So, I opened the email.

Daniel thanked me for all the work, but they had decided not to proceed.

I’d like to tell you my heart sank, but really, I just locked my phone and continued watching TV.

The TV kept playing, I think I went through two or even three episodes and I couldn’t tell you what was on them. My mind was elsewhere. I was trying to figure out what had gone wrong.

The discovery went really well

After a few back-and-forth emails, we’d finally made it to a call.

Only five minutes in, we were already riffing on ideas for automating his current preliminary design process. We were on the same wavelength too. I was finishing his sentences, or so it felt. He’d even been using Claude to help him out. But he just couldn’t get Claude to talk to the engineering program. So, I didn’t need to convince him about automation. He was already a strong proponent of it.

The biggest problem we identified was that his team was spending too long cleaning and redrawing the architect’s input before they could begin designing. When they finally produced some structural advice, the plans would change and they would have to start all over again. The loop from architect to structural advise was too manual and too long.

So, to help, Daniel wanted to take a floor plan from an architect, pass it through some kind of staging area for the engineering inputs, then produce a preliminary analysis model. We’re talking about dragging a file, filling in a form and getting an analysis model out of it.

I could already picture the workflow, and as we riffed on ideas, he seemed ready to start. So, the call ended with me requesting sample files to iron out all the details of this workflow. To put pen to paper.

Two out of five

I spent the next couple of days researching Daniel’s engineering program, working out what its API would let me do and prototyping the workflow.

It turned out that two of the five things he wanted to automate weren’t supported. Maybe there was some hacked way around it, but the API didn’t support them. So, I sent Daniel a quick email with an update, a few images of the prototype and how I envisioned the tool working. I also explained that I would continue with the proposal because we could still solve three of the five things.

He didn’t reply, so I treated that as permission to continue. No news is good news, I told myself. Plus, the call and emails had gone so well that I assumed Daniel just wanted to start.

I spent the day writing up the proposal. I worked through the costing, finalised the workflow, documented the tool requirements and defined how we would test it. By the end, I had written a proposal for something I could build and truly believed would be useful.

So, I sent it off, believing we were about to change how his firm worked. Well, then I got that email.

Asking for feedback

The morning after the rejection, I read the email a couple ten more times, hoping it would tell me what I had done wrong. Maybe there was a hint, a line, something I missed while being too excited to deliver.

The call had gone so well and the proposal seemed so clear. What in the world happened?

After staring at the same email for far too long, I still had no explanation. No hint of what had gone wrong. I could almost cite you the email from memory.

So, I decided to ask Daniel.

The worst thing that could happen was that he wouldn’t reply. So, I drafted something and sent it.

To my surprise, Daniel replied.

He was generous enough to give me some honest feedback. Which was when I found out that those two things the API didn’t support were actually the critical features for the automation. The remaining three would have improved his workflow, but his existing process handled them well enough. He couldn’t justify paying for something that he already did decently. It just wasn’t painful enough.

I’ve written before about how to know whether a workflow is actually worth automating. I failed to ask the question again after the scope changed. I had been comparing my proposal with the friction in his workflow. Daniel was comparing it with an existing process that already worked and cost him nothing new. Why would he pay for something only slightly more refined?

I should have pushed for clarity

The feedback helped, but I still felt blindsided. In the moment, it felt like I’d done nothing wrong. The call felt aligned, and the tool felt valuable.

The problem was that I didn’t stop to think when we got new information. I overlooked the fact that a change in scope meant less value for Daniel.

I had already argued that it takes two people to build the right thing, yet I kept pushing through on my own after getting new information. Yes, Daniel didn’t reply to my first email, but I should have followed up or insisted on another call. I should have asked:

Given those limitations, is the remaining workflow still valuable enough for you to pursue?

That would have saved me the time I spent writing a proposal for a scope Daniel no longer valued. It might also have led us to another way around the limitations, or a different workflow we could have explored together. I can’t know. What I do know is that I should have waited until the workflow was clear and agreed on.

Technically, everything went well. I understood the problem, the workflow and its limitations. I didn’t understand which parts mattered enough for Daniel to pay to change them.

I’ve learnt my lesson. Next time the scope changes in any meaningful way, I’ll get back on a call before I open the proposal document. If we can’t agree that what remains is still worth pursuing, there is no proposal to write yet.

Work with me: https://codedconstructs.com/contact/

Guides, Courses and Scripts : https://www.codedshapes.com/p/scripository

Alright, week 7.

Mostly business as usual. Some product work, meetings with potential clients and still creating content. I am also happy to report that the time blocking method from l week 3 is still going strong.

The more interesting news is that last week’s in-person meeting turned into a real proposal this week. Writing the reply made me realise how much trust my usual pricing model asks from a new client.

A smaller first bet

Until now, I have generally offered fixed-fee development followed by a retainer for any updates or new features.

My theory, and one that has worked with previous clients, was that a fixed fee made the cost predictable. If the work took more time or effort than expected, I ate the cost on my end. The client knew what they would pay, with no hidden costs.

But the last few weeks have taught me that a fixed fee can still feel risky from the client’s perspective, especially if it is our first time working together.

Let’s say you were the client.

You’ve reached out to me, we’ve gone back and forth over email and agreed to a call or even an in-person meeting. The meeting goes well. I understand what you need and we both come away with a good feeling.

Then, a week after sending me some sample models and files, you receive a proposal that says the automation will cost $10,000.

Now you have to decide whether the value is worth that cost. You also have to trust that I can deliver the tool you want, even though we’ve never worked together before. And how sure are you that this tool is what you need in the first place?

Even after a good meeting, that is a big first bet.

In the past few weeks, I tried to close that gap by doing deeper unpaid discovery. I spent more time clarifying the problem and working out the likely solution before sending a proposal.

That makes the scope clearer, but the final jump is still there. The client still has to decide whether the $10,000 is worth it, while I might spend days working through a proposal that gets rejected.

Writing this week’s proposal made that gap hard to ignore.

So, I am trying capped hourly work, something I was against from the beginning.

I estimate how many hours the work should take and agree on a maximum with the client. If it takes less time, they only pay for the hours I used. If it looks like I will exceed the cap, we stop and talk first.

I have written before that the hourly rate model is a poor proxy for value. I still think that is true. But it is a useful proxy for effort, and everyone understands it.

Fixed pricing still has a place. For a first engagement, though, capped hourly work gives the client a ceiling without asking them to pay for the whole ceiling if the work takes less time. It also means I can take on smaller scripts and automations that do not need to become full-blown applications.

It feels more like becoming a client’s automation partner. We can start with one piece of work, learn how we work together and decide where to go next.

I don’t know if this will work long term, or even short term. But I won’t know until I try.

Alright, thanks for reading.

Onward to week 8.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

On the bottom right corner of any engineering or architectural drawing, you can find the initials of the people who drew, checked and approved it. Somewhere nearby, you can usually see a history of how the drawing has changed and who worked on it.

Yes, it gives people credit but more importantly, it shows front and center who is responsible for it. It’s not “who’s the amazing genius that drew this”, it’s more “if this went horribly, who do we blame”.

And yeah, it makes sense. A drawing depicts something real and if it goes wrong, people can get hurt. It’s why the approval process can be so rigorous. Only a qualified person can sign off on drawings and there’s usually a round or two of review before someone on site sees it. Heck, even with all of this, companies still pay a lot in insurance because the risk doesn’t go away.

Now, imagine me. Coming along and pushing digital work in the AEC to these people. But there’s no title block for a script or a tool. Sure, my name is on the tools that I make, but it doesn’t carry the same weight. If the tool goes badly, I might lose a client or damage my reputation. The professional responsibility still lies with the person who signs off on the drawing, not the tool or how we got there.

Their name is on the drawing, their registration sits behind that name and the company has insurance in case something goes wrong. It’s also why we don’t yet let AI design buildings on its own.

“AI cannot be held accountable, nor can it replace the training, experience, and judgement of a professional engineer.” - ASCE, Policy Statement 573 (2024)

I still have a responsibility as the person who made it. I should be responsible for how the tool behaves, what its limits are and what happens when it stops working. That is a different kind of responsibility from the one carried by the engineer, but there’s just no formal bearing for it.

The lack of accountability on with tools and AI is why human judgement has to stay in the loop, but it only answers one side of the problem. Because if the engineer still carries the professional responsibility, what would make them put their name behind a custom tool built by someone else?

The answer is trust

When someone looks into automating something, we don’t have to jump straight to custom tools. Think about using Excel instead of pen and paper.

When you work out 1 + 1 by hand, you use your judgement at every step before writing down “2” as the answer. When you do the same thing in Excel, you exercise that judgement earlier. You decide that Excel can be trusted, then allow it to perform those steps for you.

You haven’t given up responsibility for the answer, because if it spits out “1654”, you as the human need to know that’s wrong. But you have given up some direct control over how it was produced. Part of the judgement moves into the tool while the accountability stays with the person approving the result.

That decision is easy with something like Excel. It has been around for years, its limits are familiar and there are established ways of checking its output. Thousands of other people use it every day. It has earned enough trust that most of us don’t stop to question every calculation.

A custom-made tool like a plugin or standalone application doesn’t have any of that.

Not only would it have been made recently (time hasn’t had a chance to test it), every tool is arguably one of a kind. Because it’s unique to each client’s workflow. It’s kind of the point. Industry-standard tools are made to work for everyone, while a custom tool is developed around the way one team works and the exact problem they need to solve.

It’s like the difference between buying a suit from a shop and having one made for you. The one from the shop is familiar and predictable, but it probably won’t fit perfectly. The custom suit should fit the way you need it to, but you have to trust that it won’t rip apart the minute you move too much.

The benefit of a custom tool is that bespoke fit. The cost is that it has no history, broad adoption or familiar process to fall back on. You can’t just ask someone next to you why your custom tool isn’t working, the same way you can with Excel. Without the custom tool, the work might be slower and painful, but at least you can see and control every step.

So what gives a custom tool enough credibility for an engineer to put their name behind its output? It can’t borrow trust from years of use. Someone has to take responsibility for earning that trust.

Building trust with digital ownership

It’s not enough to say “trust me bro, the tool I build will solve all your problems”.

Ownership is how we make a custom-built tool less of a leap of faith. It’s about reducing the risk and clarifying what the tool does, what it needs and what happens after it has been built. It’s really a two-way thing.

I don’t want to come in, tell you how to do your job and then leave when things “get real”. When I say ownership, I mean having a real stake in what happens after the decision to build. You should be able to trust what I’ve built, know that I can explain what happened when it fails and have a plan for what happens next. The engineer still owns their judgement and the final call on the output. The part I can own is how the tool behaves and what it produces when it’s used appropriately.

That responsibility doesn’t have to stay with me forever, but it can’t disappear when the build ends either. It needs a known place to go.

For a tool that has never existed before, there are three questions that define ownership to me. They follow the life of the tool: what it needs to achieve before we build, how people can understand it while they use it, and who looks after it afterwards.

Then, when we can answer these questions, we have to write them down, so that they hold whoever built the tool accountable to the people relying on it. It turns the abstractness of digital work into something with a clear input, steps and outputs.

How do we ensure the tool does what you need?

The first risk is that it doesn’t do what you need. It’s not broken, it just doesn’t solve the problem the way you thought it would. It’s like making a wish with an evil genie, wish to be the smartest in the world and the genie does it by making everyone around you stupid. You got the result but just not what you actually wanted.

So, the first step before building anything is to get clear on what it is we are actually solving. It’s not just a “let’s automate this” and we just do it. That’s why the scoping conversation, prototyping and research are a big part of the work. They are often treated as the necessary evil before building the actual tool, but it’s really the most important part.

The whole point of a custom tool is to build something that solves your problem the way you need it to. If we don’t agree on the problem and what a useful result looks like, we can’t build a tool that is actually valuable for you.

The suit analogy matters here too. A tailor can’t make something fit by guessing. You have to get fitted, choose the material and decide on the style. The tailor should make recommendations, but ultimately you have to decide if it’s something you want. Scoping a custom tool works the same way.

How do we know what the tool is doing?

Once we’ve ironed out the specifics of what the custom tool will solve, how does it go about doing that?

In Excel terms, what happens when I put in 1 + 1 * 10? Excel gives me 11 because it performs the multiplication first. It has the same rules that we use in our heads, so that the steps it performs is correct.

Understanding a custom tool works the same way. We need to clarify the steps it takes and the assumptions it makes. For a complex tool, this happens at a high level so that everyone involved can understand it. You don’t need to understand the code, just the intention and the main steps it takes. It’s my job to communicate that to everyone involved and ensure that we all agree on how the tool works and what’s needed to make it work reliably.

For my engagements, this normally means testing the tool against sample models and files, then agreeing on whether the result is correct. Trying as best to simulate real world working conditions and ensuring that the tool produces the ideal output.

A tool you can’t understand is a tool you have to take on blind faith. And because it’s a “one of a kind” tool, there are no YouTube videos to help you. The person building it has to make its behavior clear enough for the people putting their names behind its output.

Who looks after it when something changes or goes wrong?

The first two questions can be answered during the build. The third needs an answer for as long as the tool remains in use. Once the tool is made, somebody still needs the time and authority to maintain it.

A tool might work perfectly for the first five projects, then stop because the software was updated, the input format changed or the team started working differently. Software isn’t a “set and forget” thing. The tool has to be revisited when the environment around it changes.

There is also a difference between a defect and a changed requirement. If the tool stops working against the requirements we agreed on, that is a defect. If the software, inputs or workflow have changed, that is new work.

The point here is that there should be a clear path forward to keeping the tool usable and maintained. If a client stopped working with me tomorrow, they should still be able to understand the tool, use it and find someone else to maintain it.

I think of that person as the named tool owner. They aren’t responsible for every way somebody uses it. The engineer still owns that judgement. The tool owner understands how it behaves, keeps the documentation together, coordinates changes and makes sure problems have somewhere to go.

This responsibility could stay with the original developer, perhaps through a retainer if it’s an external person like me, or it could move to someone inside the company. Either way, it’s about making the responsibility explicit before everyone moves on. Just because the tool works now doesn’t mean the work is done.

The responsibility for the tool needs a home, and whoever takes it needs the knowledge, time and authority to act.

Why most tools never get an owner

A lot of internal tools don’t start as tools. They start as an answer to an immediate project problem. Someone opens Grasshopper, Dynamo, Excel or whatever else they have and builds a way through the work in front of them.

At that point, success means getting the project delivered. If the script works, it has done its job. Nobody stops to decide who owns it, how it should be tested outside that project or what happens if another team starts relying on it.

But useful tools spread. Someone shares the file, another project picks it up and eventually the person who built it becomes the default contact whenever something goes wrong. They are treated like the owner because they know the most about it, even though nobody gave them the time or authority to actually own it.

The work that would make ownership real sits between roles. Scoping the problem properly, making sure people understand what the tool does, testing it, writing things down and planning who looks after it are all part of the tool’s life. But they aren’t the visible act of building it, and inside a company they aren’t always billable.

So when project work takes over, those are the first things to lose time. The tool can still have a builder and plenty of people using it, but no one has formally taken responsibility for what happens next.

The builder might care about it. They might work nights or weekends to keep it alive. But without an owner, the tool eventually fades away or becomes so brittle that everyone’s afraid to modify it.

This is why ownership has to be more than a name attached to the file. It has to be assigned. Somebody needs the knowledge, time and authority to look after the tool from the first conversation through to the day the workflow changes.

What this looks like in practice

I’m not trying to change who carries professional liability in the industry. We made the tools, so we should be responsible for how they behave. Not for how they’re used.

In practice, the answers to those three questions need three places to live.

The problem, agreed outcome, acceptance criteria and support boundaries belong in the proposal or contract. It doesn’t have to capture every detail, but it should make the commitment clear before the building starts.

The inputs, assumptions, main steps, limits and test results belong in documentation that stays with the tool. That gives the people using it something concrete to check rather than asking them to rely on memory or blind faith.

Before the build ends, the tool needs a named owner and an agreed path for maintenance or handover. That is how the responsibility survives after the original builder moves on.

That is what I mean by digital ownership. It is the responsibility around the tool that the title block gives to the drawing. When that responsibility is clear, people have a reason to trust the tool rather than taking it on blind faith.

Thanks for reading.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

You know how in TV shows, when one major problem gets solved, another one just as big (sometimes bigger) shows up?

Well, that about sums up my week.

Within a few days, I went from wondering whether my outreach was working, to getting a client meeting, to feeling dejected about my product, to finding a reason to keep building it.

Safe to say, it was not boring.

Product building whiplash

So, before I decided to build this product, I did all my research. I asked around, looked on the internet and got AI to do some searching for me. Maybe it was just the excitement, but I was convinced there was a real gap.

I mean, even as I started building it and looked for role models on how to price, structure and sell it, I still could not find a direct competitor.

It wasn’t like I was trying to revolutionize the industry. This was a small market gap. Still, it took some effort to make. I’m about six weeks in with about 10 hours per week and it’s not quite ready for deployment yet.

But then, I found a competitor.

All that research and asking AI didn’t even bring this up. On the surface, it did exactly what I wanted my product to do.

I started laughing. I wasn’t sure if I was relieved or angry. On one hand, I was sick of working on it. Ten hours a week for six weeks and nothing to show for it yet? Damn. I wanted it off my plate, and a direct competitor gave me an excuse to stop. On the other hand, it was something I believed in, and stopping meant throwing all that work down the drain.

So, I did what I thought was the best thing, I took a break. I went to the gym, had some lunch, talked vented to a few friends and complained to Claude. I worked on some other stuff before finally coming back to look at it again.

What do I do now? Have I really lost the advantage?

I took a breath and gave the competitor a spin.

About two hours of serious testing later, I realised it was a different product. It looked the same, but functioned differently and served a different market. It’s not entirely different but it was different enough that mine could still exist.

Slowly, as I realised this, I felt annoyed but excited that it wasn’t over. I wasn’t out of the fight yet.

And instead of trying to build this from my head, I had a pretty close role model. I had something to reference and learn from.

So, within a single day, I killed and revived my product.

First in-person client meeting

I’ve had plenty of client meetings before, so I am pretty used to them. But for better or worse, they have all been online.

This week I had my first in-person meeting. I walked into someone else’s office and sat in their meeting room. Even when I had a corporate job, I’d only done this maybe twice in my life. And that was pre-Covid, before video calls were the norm.

It felt......strange, to say the least.

I wasn’t that nervous, but it felt like a job interview. Taking the lift up, asking to meet the person and saying the words:

“Hi, I’m here for a meeting.”

It’s a bit like being in someone’s home. You are welcome there, but you are still very aware that it isn’t your space. Which I think made me more self-conscious than I expected. I had to walk in, sit down and represent the business in front of actual people.

Which made the business feel oddly real.

Alright, that was week 6.

Plenty of lessons from it all, gotta keep going.

Onward to week 7.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

There are hints when your project is about to get expensive.

“It’s not quite right.” Or “that’s confusing.” Or my personal favourite, “it’s not really what I had in mind.”

They are all sentences I have heard after spending weeks, sometimes months, building something.

You’d think after all those meetings and documents, we’d be on the same page. Heck, you’d think after every development update, we’d be on the same page.

But no, we never actually agreed on anything. Everyone just thought we did.

There are so many assumptions swirling around in our heads that the same sentence can mean completely different things depending on who hears it. Someone says “yes, the tool will handle changes”. To the engineer, that means the tool updates as the design changes. To the manager, it means the tool tells the engineer when she needs to update the model.

Exact same sentence, different interpretation.

Hidden misalignment

You can come away from every meeting and call satisfied, with everyone apparently on the same page, and still get it wrong.

It’s only when you build the thing and put it in front of them that anyone can disagree. Because for better or worse, building something and showing it will confirm or deny their assumptions.

The cost is that it might take you weeks or months to find out nobody ever agreed in the first place. That time to build has definitely shrunk thanks to AI. But even then, you still have to clean up or fix something that should have been accounted from the beginning. It’s still the cost of building the wrong thing first.

Regardless of how quickly you made it, code is an expensive place to discover disagreement.

Once something is implemented it’s rework, not design. Maybe it turns out you never agreed on the core workflow. Maybe the philosophy was wrong from the beginning. What are you going to do with the 5,000 lines of code you the LLM wrote?

It’s like a tax. The longer you put off coordinating with everyone, the worse the bill gets, and everyone “agreeing” in every meeting feels great until you’re dumping two months of work down the drain.

Unfortunately, human communication is messy and it takes real effort to get everyone on the same page. So, you don’t get to skip this kind of work, you only get to choose when you pay for it. It might feel like a waste of time, but it’s always cheaper to pay it earlier, because the bill grows the longer you put it off.

In fact, my three biggest failures in computational design, had nothing to do with the technical stuff and everything got to do with a lack of clarity and alignment.

Three things I want agreed before I build

Now that I run my own consultancy, I’ve put things in place from experience to keep everyone aligned before and during development. It’s not foolproof, but it at least gives us a fighting chance.

It comes down to three things that need agreeing. How someone will actually use the tool, what it needs from them, and how we’ll both know it worked.

I call them agreements rather than requirements or a spec because a spec is something that can be perfectly written and still be a document only one side agrees with. An agreement requires both parties to sign off.

Yes, none of this is new and most of us already know it. You might even have discussed all three in some shape or form. But the key here is to write them down.

It becomes a shared space that everyone can point at and discuss. Instead of assumptions and thoughts floating around in people’s heads, it’s written down concisely and clearly.

I do all of this in my proposals to clients. On a complex tool it might take a few meetings to get there. On simpler things it might be a single meeting. It’s really about having something concrete to work off.

No. 1, How someone will actually use it

I had a previous client who wanted a Revit plugin to help them model steel framing. They knew the problem inside out. What we couldn’t agree on was how the tool worked.

Every meeting went the same way. The conversation felt good, like we all knew what the tool would do. And then someone would break that dream and ask “okay, so that means the tool automatically rotates the members, right?” and the illusion shattered, because we had never discussed rotation before.

We were each describing a workflow that looked completely different in our own heads.

After the third meeting, I got sick of going round and round. So instead of coming in with notes, I spent an afternoon sketching the workflow and how I thought the tool should behave. Taking a page out of the UI/UX playbook, I showed a markup of the tool rather than describing it.

The next meeting was completely different. Everyone suddenly had something to point to instead of just describing things. Every step and assumption was laid bare for them to see. That diagram became the source of truth.

That’s the first agreement: How someone will actually use the tool.

This is the step that most people skip. I have skipped it too. I pride myself as a “people person”, which to me meant that clients should say “fix my problem”, give me a wink, and I’ll solve their dreams. But as we’re all finding out with LLMs, we have to get better at telling people and AI exactly what we want. That’s what the diagram did.

Vague and unclear requirements lead to vague and unclear tools.

So now, for every project I take on, I put in the upfront effort of clarifying exactly what the tool will do.

No. 2, What the tool needs to do its work

That same diagram helped out from another angle. It made the starting point and the assumptions visible.

In the earlier meetings, the client and I talked about the tool starting from a blank model, or maybe the user fills in a form, or maybe a floor plan.

When I drew the diagram based on how I thought the tool would work, I unconsciously gave it a starting point. Which told the client exactly what the tool needed to work.

That’s the second agreement. What the tool needs from you. and what it’s allowed to assume.

Every automation is a stack of promises about the state of the world. It takes an assumption, encodes it, and works from there. In this case, we agreed the tool would start from a floor plan with walls already modeled in, and that those walls were floor to floor and never half height. How they got into the model was outside the tool’s scope. We also agreed it would only use a list of verified steel members in its functions.

These are the rules of engagement. A list of exactly what the tool needs, and what it doesn’t support to execute the agreed workflow.

The tricky part here though, is that you can’t capture all of it without making the tool. The number of things that could be true about someone’s Revit model is effectively endless.

So the goal isn’t to be exhaustive. It’s to catch the critical ones before you invest time in development. Unfortunately, that comes down to experience. Because I have made countless Revit plugins before, I can make a guess on what the rules might be.

The half height walls are a good example. It’s a rule because I know that Revit won’t allow us to execute the workflow that we want. That’s just from past experience. So, I brought it up in a meeting, wrote it down, and everyone agreed it was a rule for the tool to work.

Identifying those exceptions takes experience, and I still miss things. But at least we capture what we can at the time, instead of arguing later.

No. 3, How we’ll know the tool works

Switching gears for a bit. A few years ago I worked on the façade movement analysis for a high rise tower. It was a complicated façade and we knew we had to analyse it, but we didn’t know why. All the client told us was to make sure it was all okay.

That forced us to understand what we were even doing. Analysis and “work” can mean a thousand different things, so we set about exploring. What can we analyse, what results can we get, and what do they ultimately mean for the façade.

We ran rigid body experiments to work out what to measure. We built Excel sheets to check the maths independently. We even 3D printed a small joint to check our simulations. All of it was us trying to understand what “make sure it’s all okay” meant.

The result was a series of metrics that told us whether the joints would open or close under the building load. If we could understand how much the building moved, we could understand whether the façade panels would clash into each other.

That’s the third agreement. How everyone will know if the tool works.

It’s easy to skip, because by the time you’ve agreed on the workflow and the inputs it feels like the work is done. Which is the same trap as before, everyone assuming they’re already on the same page.

And to be fair, “done” is hard to define, but it has to be defined, because it’s the last part of making the tool concrete.

For a custom tool it means agreeing to a set of representative files, the output each one should produce, and what happens when we run them. I do this as test cases and a checklist. I’ll ask a client for five to ten files that represent their typical working situation, and together we write the checklist the output of the has to meet.

This is what we call User Acceptance Testing. And it’s all about agreeing on what the tool should produce and under what circumstance.

It’s here that a tool stops being “it should work like this” and becomes a list of tests that it passes/fails against. A list that has been agreed on by both sides.

It’s not formality for its own sake, it’s clarity

It probably sounds like a lot of effort and paperwork before the tool gets built.

It can be, but the goal isn’t formality for its own sake. It’s clarity. A small script might need one meeting and a couple of pages. A complex tool might need a few meetings and a denser proposal. Either ways, it’s the same three agreements.

The size of the build changes the amount of effort and paperwork you have to do but it doesn’t change whether you need to agree.

Meetings are good and I have a lot of them, but a conversation doesn’t produce anything solid that everyone can poke at. It also can’t hold the details of a complex tool. A diagram or a few paragraphs can.

For every project I have done, the biggest problem has always been believing you’re aligned when you’ve never tested whether you actually are. Again, it isn’t foolproof. It just gives you a much better chance.

Alignment and clarity

The goal is alignment and clarity. If everyone agrees and understands exactly what will be built, the problem it solves and how it solves it, everybody wins.

Unlike physical things we can touch and hold, a digital tool lives in the ether. Its abstractness is hard to visualise, and even when you can, everyone visualises it differently. Digital tools have real value, but we have to do the work to define them better for everyone involved.

Things will still change midway and sometimes the scope blows out. But there’s a real difference between finding out you disagreed and finding out you never agreed at all.

So whenever you’re about to build something, think about these three and write them down. Bring as much clarity and alignment as you can before anyone starts.

Thanks for reading.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

Alright, week 5.

Last week I published an article about the business models of digital work, and I ended it saying I wanted CodedConstructs to be a service firm that also builds products. I also said I knew from experience that balancing those two is hard, and that I’d eventually have to build better boundaries between them.

Well this week, I got a preview of just how annoyingly difficult that is.

The product I built did the wrong thing

I have been working on a product alongside trying to get clients and creating content.

But the tempting thing with LLMs is that you let them do more and more as you get busier and busier with other things. And as I got busy creating content or doing client work, there were a few times I just let it run.

This week though, it “finished” and it’s time to test. I have automated tests but this was the end to end one. The one where I put myself in the shoes of my users and go through the product itself.

In the first 20 minutes, I listed maybe 15+ things that were wrong with it. Which was to be expected, but 1/15 needed significant rework. It was part of the core design of the product and the LLM had gotten it so so wrong.

So, I went to look back at all the notes and plans it worked off. I saw that I actually approved the wrong design. Probably because I was busy with something else and it kept asking me questions, so I just approved everything. The LLM, not knowing any better, just kept piling on top of that.

When the foundation is already wrong, building more on top of it makes it worse and that’s where I am at now. I have the cost of building the wrong thing and also now the added cost of fixing the thing because I said yes without knowing the consequences.

Focus more is not the answer

The easy answer here is “focus more”. In fact, I can almost hear my ex-managers giving me this same advice. To do less.

And I think it’s partly true but it’s not the whole story. It’s not to give up any of my current endeavors, I think it’s to focus on a few things at a time, not everything at once.

I was being too greedy.

If you’re a software developer, you would understand this. When we made stuff pre-AI, every time we made a change, we would have to wait for the computer to recompile. It would take 2 maybe 5 minutes before you can type a line of code again.

What do you do in this time ? You can scroll your phone, read something, stare at the screen, etc.

Now, in the AI world, it’s waiting for agents to finish.

So, what do I do now? Well, I start another agent to do something else.

Then, what do I do while waiting for that ? I start another

So, I end up having 2-3 agents at the same time. There was one time, I had up to 6.

It sounds awesome, like I am this grand puppet master with an army of agents working for me. But this actually means my attention and judgement (which arguably is my most valuable asset) is split across multiple equally important tasks.

It’s just plain greedy. Instead of 1 amazing result, I now have 6 mediocre ones.

So, my lesson for week 5 is to resist the urge to squeeze as much as I can. Because the harder I try to be efficient, the less I actually am.

Thanks for reading,

Onward to week six.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

You know, they say when you start a company, you truly feel alone.

I never really understood that. Instead, it was just so freeing. I felt the pressure to make money and deliver, sure, but that’s different from feeling alone.

But I recently wrote my first proposal to a client since going full time and the “alone-ness” finally caught up to me. Well, I wasn’t truly alone, I had self-doubt to keep me company.

While I was writing the proposal, I was trying to come up with a scope which in turn leads to how I price the actual work. Costs aside, I had trouble nailing down what to actually deliver because there was just so many options. Simply put, it’s a tool that helps transfer documentation into an analysis model.

I could have done only a base build, you know get the foundation and skeleton up first, then if it’s useful add on more features later. A good analogy here is think of it like I am building you a car. Instead of giving you all the passenger seats and a trunk. Let me just give you a car with a driver’s seat only. And if you need the rest, we’ll slowly add it in.

But what happens if passengers are important to you ? Maybe that’s the whole reason you’re buying from me. Maybe you need a trunk, maybe having a fully featured car is what you’re actually after.

With all those questions in mind, I wrote up a proposal that gave this potential client several choices. I offered a “base build + modules” scope.

• Base build

• Feature A

• Feature B

• Feature C

• Feature D

As in, take a base build + 2 or 3 modules and there’ll be a bundling discount too.

What’s wrong with it ?

On the surface, nothing. I mean more choices is good right ?

When’s the last time you hated not having a choice ?

Well, I think some choice is good, too many and it’s just overwhelming. And I have definitely given the client too many.

Imagine you don’t know anything about cars, and your mechanic presents you with say 10 choices all for you to decide. I would be so overwhelmed that I would just leave to find another mechanic that understands my problem and recommends the exact path that solves it for me.

I didn’t catch any of this on the day, though. I read it back the next morning, before I’d had any coffee, and it was immediately obvious. Same document, same words, and a completely different reaction to it. That was the closest thing I had to a second opinion, and it was still only me, twelve hours later.

So I did what I’d have wanted that mechanic to do. I gutted the whole thing and rewrote it with one option in mind. The one that I thought was best for him.

And it was a good thing I did too because that proposal was actually tailored to him rather than me just giving him a menu of things to decide. I showed my expertise in what I think is best for him, rather than staying stuck in fear and offloading the decision to him.

Being alone

It made me think why haven’t I come across this before ? I have written plenty of proposals for myself and when I worked at companies. Why was this one so hard ? Why did I keep second guessing myself ?

The answer, that came to me after a night of sleep, is that I had no one else pushing against me.

In a company, there are so many review processes and casual conversations that help you think but when you’re alone, the rabbit hole is deep and oh so tempting. No one tells me what to do, but no one tells me when I’m wrong either.

And that, I think, is the biggest contributing factor to the loneliness.

At least in a company, you can turn to someone sitting next to you and ask them something. You can bounce ideas around because you’re in the same boat. But here, even though I have friends and family to talk to, it’s different.

They’ll listen, and they’ll be supportive, but they can’t tell me my scope is wrong. They don’t know what a good proposal looks like in this industry. So, what I miss isn’t the companionship. It’s someone with enough context to push me towards a better answer than the one already in my head.

The part that actually unsettles me is that I can’t tell, in the moment, whether I’m being thorough or just going in circles. Both feel exactly the same and “trusting yourself more” doesn’t really help if I am deep in the wrong rabbit hole.

And the cost of being wrong has changed too. In a company, a bad scope meant a rework and an awkward conversation with someone down the hall. Out here it means a client who quietly decides I don’t know what I’m doing.

I think that’s just the discomfort I have to get used to. I don’t regret re-writing that proposal, that time bought me real clarity on the problem and it was worth it. But I only know that in hindsight, and hindsight isn’t much of a system.

So when people say you feel alone doing this, I think this is what they actually mean. Not that there’s nobody around. Just that there’s nobody in the “trenches” with you, and you tend to find out you were wrong long after you could have done anything about it.

But I am slowly getting used to it.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

Alright, week 4. A full month in now.

Better than last week, which I wasn’t expecting given how it started.

That proposal I sent out from last week came back rejected. But funnily enough it didn’t really affect my confidence. I mean I was disappointed but the rejection didn’t mean my work was bad.

It was just that what I could build for them didn’t fit what they needed.

I was also proud that I asked for feedback. I wanted to understand if I could have done any better or maybe there were some confusing parts.

The lesson I took away is that I have to get better at alignment from the beginning. Instead of me sinking a few days into coming up with a proposal, I should have asked more questions instead of assuming things. It’s to be courageous and ask for more information instead of assuming I am disturbing them.

What it did do though was make me wonder whether there’s a clearer more cohesive way to tell people what I do. So, I spent a couple of days on strategy.

When I first started CodedShapes and posting on LinkedIn , the goal was just to see if I could be consistent. Not only have I proven to myself that I can, I also enjoy it. But, I did it in a pretty unstructured way. I posted or wrote whatever was on my mind. Which I think is great but it meant my ideas and thoughts were all over the place sometimes.

Now that I completely control the narrative and don’t have to worry about office politics and all that, I can make it more cohesive. So I am trying a content pillar approach. Simply put, it’s about defining some pretty wide buckets, and then every idea I come up with needs to be reframed into a bucket.

It’s something I sort of do already but this just formalizes it and helps me focus on what I am actually trying to say.

Hopefully it makes things clearer and less like rambling. But I do like writing whatever comes to mind though, so don’t expect that to change anytime soon. I am just trying to be more focused with my messaging is all.

Other than that, the time blocking method is helping me properly triage my tasks now, which is good.

Alright, that’s it.

Thanks for reading,
Onward to week five.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

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.

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.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

If you’ve ever had to pull data together from more than one source in Grasshopper, you know it’s rarely as clean as it should be. A prime example of this is when you’re working with structural analysis models. Because most programs store their geometry and results separately. And it always means you have to do some form of list matching to get them to line up.

A few weeks ago, I had a list of nodes from a model that I needed results for. Like most structural analysis programs, ETABS hands you one list of nodes and a separate list of results, expecting you to use the node IDs to cross-check between them.

So how do you join two lists by an ID in Grasshopper?

If you’re comfortable with code, there are many ways to do this. You can use a dictionary in C# or Pandas in Python. Even in Excel, Vlookup by the ID of one list will help you line up the two different lists.

And, well, you can actually do the same in Grasshopper. The component you’re after is called Key Value Search. It works very similarly to a dictionary in C#.

And the best part is that you can pass in anything, not just numbers. Geometry, custom data, whatever you have. So, instead of using a script component or doing Vlookups in Excel before Grasshopper, this component let’s you keep everything in a script.

Okay, if you’re a paid member of CodedShapes, you get to see how I use this component in action as well as a sample script at the bottom.

Read more

Alright, week 3.

It’s what I am now calling the self-doubt week because that is the strongest feeling here.

But on paper it’s a strong week, two discovery calls, some solid time spent working on products, spent time on building a community, and I even implemented the new time boxing method from last week.

That really helped. Simply put, instead of only working on things that are top of mind, I treat each day as 3-4 blocks, about two hours each, then I assign tasks to all of them for the upcoming week.

I am not strict on adhering to it though because I know there are meetings and other random life things that get in the way. But the biggest benefit has been the clarity of everything. I can see now all laid out on my calendar things that I should be working on. Thinking about my time in blocks has also helped me focus, when you only have limited work blocks, you can’t pretend everything fits. So, it has forced me to decide where to put things and which should remain in the backlog.

Last week, just felt like all the tasks were due at the same time and I was task switching like a headless chicken.

The midnight discovery call

Sydney is a great place but the timezone difference with the ET (Eastern US Time) sucks. That discovery call I had was at midnight and I felt fine during the call, but the days after sucked. Mostly from the disrupted sleep and it could be why I feel so much self-doubt this week.

But that call was worth it though.

Because it gave me a new perspective on the way other people work. Even though I have worked with many structural engineers, I still get caught by surprise on how many assumptions I make that are wrong. So, it felt like that call brought me closer to reality.

Building a community

It’s still hush-hush for now but I promise I’ll release more information soon when we have something solid.

But the first half of my week was working on creating a community for digital people in the AEC. I know there are a few out there now but I am hoping that this one will help support people in other ways that are rarely talked about.

Moving into next week

Well, the self doubt is strong right now but I have to remind myself that I can only control the inputs. So, as sucky as this week felt, I still believe in what I am doing and I should hold the faith that it will turn out okay.

So, I think next week is about keep on doing the thing and trusting myself.

Thanks for reading,
Onward to week four.

A couple of weeks have passed, and I still can’t quite explain how I feel.

If you didn’t know, I recently started my own firm, and I’ve been documenting the thoughts, the work, and the feelings in this journal section here.

The central theme of these early days has been the strange, fleeting feeling of time. Okay, sounds very abstract but please bear with me.

I thought that once I was on my own, I’d be able to squeeze out way more work, because I’d finally be in full control. No meetings, no random support calls, no need to perform acts of productivity just for the boss.

Instead, what I’ve actually found is a constant influx of things to do. Not work exactly, not things that make money directly, just things to do. Like writing this newsletter, talking to people, admin stuff, etc.

I have enough savings to afford my current life for a while, so money shouldn’t be the thing I worry about. Yet I can’t help but feel things ticking down. Like a really drawn out time bomb. And I’m sitting in brace position waiting for it. Which, if I’m honest, does me more harm than good I think. Being safe is good but worrying about it just wastes my energy and time.

Some days I wake up ready to take on the world. Other days, I tend to worry about if I made the wrong decision. I’ve spent a lot of my time teetering between feeling like crap and feeling on top of the world. So, I wanted to take a moment today to answer the question.

Why put myself through this? Why leave the stability of a job, in this economy, to feel the extremes of every emotion alone?

Like most decisions, it was made of many small ones, and it took me a few months to understand why it was the right one. As I pondered the decision, some people who know me well said that starting my own firm was inevitable. Others tell me it’s the worst decision because of the bad economy, there’s a war, market is bad, there’s endless worry....... Even my own thoughts whirled with endless possibility and doubt.

With so much conflicting advice, I had to take the time to work out what I actually believed and if this was actually something I wanted to do.

How I made the decision (after months of thinking)

The clearest part of the answer came from my last big project.

It was the biggest job for the Melbourne team, and it ran for two years. It’s actually still going. It was complex, high-profile, and very delayed. Everyone involved was so stressed that if you dunked their head underwater you’d get enough steam to power the office. That project was all-consuming. Some of the lead engineers even worked through holidays.

Which meant every internal tool I looked after got de-prioritized, even the ones the whole office used. Drafters and engineers would come to me with something broken or a critical improvement they needed, and I couldn’t work on it. The project was my life and nothing else mattered.

Okay, but saying no once, or as much as three times, is fine. That’s just a backlog. Saying no for over two years is not good. I let the same people down over and over, and I inevitably lost their trust. It was also the same time that AI got really good, so people stopped waiting on me and started building what they needed themselves.

Part of me is glad they got that independence. The other part knows what it really meant: on the tool side, I’d become unreliable. Then, here I was seeing everyone else build cool shit while I was stuck putting out fires on this Melbourne project.

I am stubborn, with all that project work, I still didn’t want to give up the tools. I am responsible for them and for everyone that relies on them to deliver a project. So, for two years I lived pulled in two directions.

I’d rush to patch a tool, then rush back to the project, then when I was stuck waiting on someone, rush back to the tool because the band-aid I’d put earlier failed. And because project is king, I had to spend some nights, some weekend, even the days when I was sick to support the tools. Terrible boundaries, but it was the only way to truly support the teams using it.

And at its core, I get it. A company has to protect its flagship project. There were a lot of eyes on this one, and it had already been delayed twice. In the director’s point of view and with the project on fire like that, I’d have made the same call. Force everyone to drop their stuff and work on it. Essentially, all hands on deck.

I also love project work. Some of my best tool ideas came from it, and there’s nothing quite like solving a real problem with a team pulling toward the same thing. So this was never project work versus tools.

The problem was that projects were the only thing that ever counted. With projects vs internal tools, projects always win, no matter how critical the tools were. My effort could be overridden at any moment by whatever was loudest and most billable that week.

So, yes putting out fires constantly for two years was exhausting but what made it worse was that I couldn’t be there for the people relying on what I’d built.

It took me a long time to find the word for it. Ownership. The part I cared about most was being able to manage and handle a problem from end to end. That means maintenance and being responsible to the people relying on them. I want to build useful things that last and solve real problems. And always being pulled onto a project on fire meant that I couldn’t do that.

So I left.

Trading safety for more control

The truth is, I couldn’t have fixed any of that. And as much as I complain here, most companies work the same way. They’re not evil, they just have other priorities. Failing the people who relied on my tools was the worst outcome I could picture. But to the company, failing to deliver that project was worse. If the whole team had quit but the project succeeded, that would still have counted as a good result.

So more ownership of the tools was not possible, at least not while I worked for a company that only cared about direct billable hours (which in the AEC, is most of them). No company running on billable hours can protect the time and effort needed to build tools. I am not saying that companies should ignore the cost of tools, but they should better weigh them against the projects, to figure which is a better use of resources.

Out on my own, I finally get to decide where the effort goes. I can actually support the things I’ve built and the people using them. But that’s always easier said than done. I now need to worry about the business case of everything I do.

There’s nowhere to hide. For all the harm office politics causes, they double as a shield, it’s so easy for me to just blame them. Now, if I stop delivering value, I don’t get paid. But ownership and exposure are the same coin. I don’t get to own more without also being the one responsible when it breaks.

None of this means project work is the enemy. It’s that the tools a team leans on need an owner who won’t get pulled away, someone who owns the problem end to end, maintenance and all. Out here, that’s the whole job.

Which brings me back to where I started. The teetering, the brace position, not knowing if this was the smartest or the dumbest thing I’ve done. I used to think that feeling meant I’d made a mistake. Now I think it just means the work is finally mine to answer for. Some days that terrifies me. I’ll still take it over drifting.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

If week 1 was fast, week 2 was a blink.

Holy shit, it went quick.

I think it’s because I’m juggling too much now. Right now that’s:

• Daily outreach

• Meeting new people

• Writing a new newsletter issue

• Editing next week’s newsletter issue

• Creating and editing 5x LinkedIn posts

• Making the paid newsletter issue

• Building a few software products

• Building a new community (more on this soon)

• Writing and assessing proposals

And there’s actually no client work in there yet, which is crazy to even think about right now. But what actually ate my time was meeting people and prepping a proposal. Which I guess always take longer than I think.

I know it looks like too much, and it feels like it too. But it’s all work I care about, so the skill I need is triaging, instead of cutting things out. I know that everything isn’t urgent and not everything needs my best energy. So, I have to get better at protecting specific times for specific things.

This week, I moved outreach to the afternoons. The quality holds up fine at moderate energy, and it frees my mornings for the harder stuff. I also made a rule not to take meetings in the morning, unless there’s really no choice, like people in the EST timezone.

So, really, this week has been a big lesson in figuring out how to best plan and use my time effectively.

My first proposal since going full-time

Some of the outreach is bearing fruit, and it left me writing my first proposal since going full-time.

Compared to when I did this part-time, the stakes here feel higher. Like I don’t want to mess things up. I didn’t have to re-write a new one but I did take some time to compile and cherry pick the best bits from my old proposals into this new one.

That part was fine, the part that actually took more time was the classic problem of scoping the work and pricing it.

My first instinct was to give this new potential client choices. Because who doesn’t love choices? It was going to be a base build, then modules on top of that, each priced separately: base + A, B, C. Where the more modules he took, the bigger the bundled discount.

I was ready to hit send when I realized it was way too many choices. We are talking like 9 choices to make.

I think it was because I was scared. I wanted to hand the decision to the client instead of asserting what I thought was best. I mean who am I to assume what is best for him right ?

But I reminded myself that I know what I am doing and I should offer my opinion. Even if it’s wrong at least, I am providing some direction instead of pilling on more uncertainty.

So, I gutted the whole thing and started again. This time, no modules, just offering what I thought was the best for his situation.

I hope I’m right and but we’ll see.

Making that call felt like maturing, and it gave me more confidence to act on what I think instead of trying to please people by giving them options.

Co-working

The other thing I did a lot more of this week was co-working with a friend. We jumped on a call, chat a bit and got straight to work.

We did two 50-minute pomodoros each time. Did this for 3 days.

It’s been great because one thing about starting out on my own is that I don’t get to talk about the work I do as much. I mean I meet people but those are potential clients and that’s different from just working with someone.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

Okay, so what’s the first thing someone does when they start a new company?

You know, the one thing that’s easy to do and makes you feel productive and in control.

.
.
.

Did you guess it?

.
.
.

They build a website.

And that’s exactly what I did, a few weeks after going solo.

But I have an advantage here. I’ve built plenty of websites before, so my problem now is not the design or the tech stack. It’s the messaging. Basically, I’m trying to answer:

How do I communicate what I do to others?

Which is a problem I’ve been circling for years. I’ve written before about what happens when no one understands what you do, except back then it was a problem inside a company. Now there’s no company to hide behind.

At first, I thought the job was to prove myself

I’d just left a big-ish structural firm with a pile of projects and tools under my belt. I wanted to show every complex thing I’d built. Surely, that’s my value, right? I’d even done something like it before, so I had a template to copy.

So I spent two days doing exactly that for CodedConstructs. But the more I worked on it, the more I hated it. It got to the point where I just gutted the whole thing and started again.

I just wasn’t sure what I was saying anymore.

Round 2, cutting the flash

I didn’t hate the portfolio because I wasn’t proud of those projects. I hated it because I didn’t want to be that person. You know the type. The super-techy, know-it-all who’s always screaming “look how much value I’d bring if you’d just pay me.”

That’s the opposite of what I want CodedConstructs to feel like. I want to be your partner in solving problems. I want to show that I understand the problem and can build something that fixes it. I want the site to do what I’d do in-person, ask questions, dig into the problem, before offering anything.

A flashy portfolio is the opposite of that. All it does is alienate people. What’s worse, it says nothing about whether I can build you a tool that saves your team time and effort. It’s the same mistake as building for the demo instead of the job, just in a different medium.

In a field this abstract and confusing, I’m aiming for clarity. Not flash.

After some thinking, the way I got there was to lead with the problem, then show what it’s like to work on it.

Of course, since the problem can be broad, I show the three ways I can help.

This is actually more reflective of me in real life too. I always start by trying to understand the problem first.

Showing the process

As part bringing more clarity, I wanted to show people what it’s like to work with me.

There aren’t many examples of digital work in the AEC industry, so I laid out what has worked for me in the past. Again, the goal is to take some of the blurriness out of all this digital stuff and replace it with a clearer picture of what building an effective tool actually involves. None of it is magic, it just looks that way from the outside.

As simple as it looks on the website, most of that work was me iterating on how to articulate my own process.

Examples, not a portfolio

Cutting the traditional “portfolio” meant cutting my examples too. Which was a real loss, because examples are proof of work and they sometimes spark ideas people hadn’t considered.

What I didn’t want was the show-ey part. The big beautiful images that almost never represented the value of a digital tool.

So, I’ve gone against the grain and kept the examples light and text only. Along with a way to filter them by pattern and discipline.

But even with text only, I kept falling back into deep technical dives about the solution. Flashy is a hard habit to break.

So, each example followed a strict format that should be skimmable by anyone.

The idea here is for anyone to read and hopefully identify with an example. Then, be motivated to reach out.

I want my examples to show the value and type of work I do not to overwhelm people with “awe”.

I had to choose who not to help

This was the hardest part of the site.

Deciding who I can’t help means focusing on areas I bring the most value to. This was particularly challenging because I love solving all types of problems.

But specificity opens more doors than being broad. Saying “I build custom tools” is vague and not helpful at all, which is roughly the reason I got fussy about what I actually deliver in the first place. So, I got more specific about the firms I can best help.

To me, it’s the small-to-medium, busy firms without the in-house capability to build tools for themselves. Big firms can afford a digital person. It’s the small-but-slammed shops that need the automation most and are least able to make it. That’s where I’ve delivered the most value.

The uncomfortable bit is that I could say yes to more. I’ve spent most of my career inside structural firms. I could offer structural advice, or drafting help. But that’s not the value I want to bring. The whole point is helping teams get more out of their computers, and I can’t do that while trying to be everything to everyone.

This is all a working theory

As certain as I sound about all this, it’s still a bet.

I’ve just started my own firm, so how I position CodedConstructs is bound to change, and hopefully the site changes with it. I’m writing all of it down as I go, messaging included.

I know a website won’t be some overnight client magnet, and most people won’t even know it exists. But it’s the one place I fully control the narrative. It’s where I get to define what CodedConstructs stands for and how I want to talk about digital work in AEC. And knowing me, I’ll keep tinkering with it forever.

Whether leading with the problem actually pulls the right people in, I honestly don’t know yet. But it’s the stance I’m taking.

Hopefully this gave you a glimpse of what CodedConstructs is about. And maybe a nudge to ask yourself the same question. How would you explain your work if you had to?

The site is live, so have a look: www.codedconstructs.com.

Work with me: https://codedconstructs.com/contact/

Resources on Computational Design: https://www.codedshapes.com/p/scripository

What is this

I’m going to try to write, and film, one of these every week. It’s a short log of what it’s like to leave a job and build something on my own. I am treating this as a “documenting” style but will try to make it as coherent as possible.

I think this journey of mine is going to be interesting, so I want to share it with everyone but I also didn’t want to disrupt my current newsletter. So, I create a new “section” on Substack.

And if you don’t want to follow along or read this, no problems, you can always unsubscribe to this section at the bottom while still getting the normal CodedShapes issues every week.

Rules

I adding this to my already pretty long things to do weekly, so I made some rules to prevent this from sucking up too much of my time.

• Writing and editing, can only take 1 hour

• Filming and editing, can only take 1 hour

  • During filming, no more than 5 re-takes.

• Publishing (in all it’s nitty gritty), can only take 30 minutes

I am going to set a time for each and when the time is up, I’ll wrap up and publish. The whole point is for this to be rough and it’s a log, not “content”.

Week 1

It’s the end of week 1 of going independent for me.

And if I could sum it up in two words, it would be: freeing and exhausting.

Like the start of most journeys, I’m find myself wanting to do many things. Filled with excitement and busier than ever.

I got more done than I had in weeks.

Just as a summary,

• I got the company setup and all its accounting logistics and tax implications

• I got the CodedConstructs site up and running

• I have been doing some outreach every day

• I had some meetings with new people (Just meeting interesting people)

• I had some discussions about new projects to collaborate

• I have been doing some product development too

Every evening, I am exhausted. But there’s a strong sense of accomplishment each day. There’s just something about being able to own the end-to-end process that makes working on it, so great. Maybe it’s the control and also the fact that I am able to execute on my “vision” for what digital work looks like.

It’s also the small things too. Like being able to go to the gym before lunch instead of “slumming” it with the after work crowd. Or meeting people and not worrying about my lunch break ending and having to rush the end of a great conversation. Since, I just started being able to work from my “office” at home is way better than the pressure of needing to go to the an office (although I imagine, this will get lonely soon).

All of this in the first week has made imagine going back to a full time job unimaginable.

As Naval once said:

But it’s not all glorious.

The elephant in the room here is that at some point, all of this has to make money.

Freedom is great and all but so is being able to pay the bills.

And it’s a sneaky one. Because now that I am alone and every decision is on me. Which leaves room for a lot of doubt and questions. No more manager or “management” to blame. Everything is on me.

Which when I am tired, can feel overwhelming.

It’s a strange to feel so free and also feel that time is running out at the same time.

It’s led me to understand burnout better now than I ever did on a salary. Because there is just an infinite things to work on at a given time. There’s just always more to do.

Actually, the hardest part might even be to trust myself more. Because well I making decisions that need to have a positive and monetary impact and a lot of that is trusting my own instincts and processes.

In a few moments of weakness I have thought of reaching out to the less savoury kind of people ~asking~ begging for a project just because it seemed easier than to stand my ground. But I’m hoping I never go through with that.

That’s week one in a nutshell.

I am going to try and keep these up each week because I find it interesting to see how this unfolds.

Thanks for reading.

I’ve spent months deliberating this and everyone tells you how scary it is to “take the leap”. But no one warns you how weird the time leading up to the jump actually is. I have pivoted between being grateful and then wanting to be rid of the job. And the best of all, teetering between full of self-doubt and full of confidence.

It’s really was a strange time to be in.

I’m allowing myself to feel all of it because I think that’s the best way forward.

The weirdness of being a digital person in the AEC

CodedShapes has been my way of trying to make sense of this weird field. Working through story on what it actually means to be a technology person inside an industry that doesn’t need technology to deliver its work.

AI and Grasshopper are great, but at the end of the day, a building just needs a drawing printed on paper. As long as getting there isn’t too expensive, most companies actually don’t care.

Through these articles, I kept circling the same question from different angles. Finding the right things to build. Debating billable vs internal tools. Hammering on the point of understanding first, before building.

All of it has been me trying to answer: how does digital work actually fit inside AEC?

When I say “digital” I mean everything : Building plugins, Excel macros, Grasshopper scripts, standalone applications, web applications, … everything

Proving Ground put it well in 2017 when they wrote that computational design was largely misunderstood. That it should be treated like a problem solving methodology instead of an actual role. The article even goes on to suggest ways of working with digitally forward people at a time where “computational design” was just a new thing.

But here we are, almost a decade later and no one has a good answer. People still don’t know if the computational designer is a BIM person or an engineer or just a software developer. And even operation wise, is the role project focused? Is it just R&D? Is it both? How do we budget it?

And now with AI, we’ve arguably moved even further from understanding what these roles are. Since it’s made tool-building more accessible, a lot more “normal” people are making tools now, which blurs this line even more.

Is a senior structural engineer that uses AI to build tools the same as computational design? I don’t think so, but some companies might.

I still believe in the vision of “describe a computational vision that can help lead your business to the best possible solution” but I just don’t think doing it from a company works anymore.

What working inside taught me

I’ve spent most of my career working inside structural engineering consultancies. Building tools, scripts, workflows, and digital systems around the company and it’s projects. And it’s been a bumpy ride. I’ve built tools that entire projects depended on. And I’ve built tools that never saw the light of day, months of work just sitting in a folder somewhere because it wasn’t thought out properly. Or because someone thought it was a good idea to automate the small 1% of their work.

And what I have found is that even though it’s a deeply technical area, the things that actually dictate the value of computational design are communication and understanding, which are both very human problems.

As I “climbed the ranks”, I kept pushing to understand the entire delivery chain for digital work in this industry. Not just the tool building but the scoping, the selling, the maintaining, the finances, basically, everything.

But as I pushed for more ownership while working for companies, I met an equally increasing resistance that stemmed from all the classic “corporate” reasons. Politics, budgets and status games.

It was reaching a point where the role didn’t fit the work I wanted to do anymore.

Walking the walk

It’s easy to complain about companies not giving me what I want. It’s much harder to do something about it. So, this is me walking the walk.

I’ve spent years writing about how computational design works (and should work) in our industry. And now I want to put that to the test on my own terms. Going independent forces me to stress-test my own philosophy, which has always been to understand first, then build.

In a world where building new tools is fast, focusing on the human elements like communication and understanding seems counter-intuitive but it’s the right instinct to act on now.

The industry still doesn’t know how to position this work. And just building things quicker with AI is not going to solve that.

But the other hard truth is that I also don’t know what the answer here is either.

Starting my own consultancy forces me to find that answer because you can’t sell something you can’t explain. I can’t hide behind budgets or politics anymore, I am forced to confront the market with my ideas. I have to find the fit between what I believe and what people actually need.

Which is why it’s taken a lot of deep soul searching and incredibly difficult work to arrive at this decision. But ultimately it became clear that this was the only way forward.

What is CodedConstructs

To me, CodedConstructs is not a completely new thing. It doesn’t change the work or who I am. It’s a clearer container for the work I’ve already been doing and want to do more of. Well, this container needs to pay my bills at some point.

I want to build tools and workflows that teams can actually adopt, maintain, and use to be more efficient. Not built for marketing or because some director decided the company “needs to do more AI.”

The work I care about sits between design, delivery, and software. And it’s always been about ensuring the tool fits the way the team actually works.

What’s next

Nothing changes on the CodedShapes (this newsletter) front. But it does mean I am fully open for business.

If your team has a design, modelling, documentation, or reporting workflow that feels too manual, too fragile, or too dependent on one person, I’d be happy to chat. Even if it’s just to think through what makes sense, that conversation is free.

If it doesn’t work, I’ll tell you and I’ll never take payment from you before the next steps are clear.

For the first few years after graduating, this single question kept me up at night the most.

I was lucky (and maybe not so lucky) because early in my career, I got a job at a structural engineering company that just started a digital team, and I was their first computational design graduate.

The concept was a team that knew engineering and code, helping create tools and workflows that made everyone else in the company more efficient. Grasshopper was all the rage back then and this company wanted to use that as an advantage. Well, and normal programming to build proprietary tools.

But really, no one knew what that actually meant. Like what progressing in the role looked like. What the team structure was going to be. How to discuss salary. Or even how to budget the team. It was all so new to everyone.

And as a graduate, I couldn’t help but worry about my future.

Especially when the rest of my cohort from university were discussing their careers. They talked about getting to senior level. About being fast-tracked to manager. Or even negotiation tactics on how to get the salary they thought they should be getting.

They looked to the future with certainty while I didn’t even know what my next year would look like. Does “senior” even mean anything in a field of less than a 100 people?

So, again, the question kept haunting me.

Am I wasting my time by doing computational design?

I wanted someone to tell me what the next step was. To show me what it meant to “climb the ranks.” To give me a promotion checklist to work on. Most importantly, I wanted someone to tell me that I was learning useful stuff for the future.

But as uncertain as things were, the work was too interesting to give up. I was coding, I was scripting, I was exploring digital concepts with clients and directors. It was one of the most interesting times of my career.

So, I soldiered on, hoping the company would overcome the growing pains of starting a new digital team.

A few projects and tools (and years) later...

We still didn’t know a damn thing.

And like anything new, the interesting bits started to go stale. And this idea of being a digital person in this structural company started to really weigh on me.

I got promoted to senior. Cool, but again, no one knew what that meant. Every fortnight, we had meetings about budgets and R&D initiatives.. We had directors chasing us to create concepts that never saw the light of day.

On paper, cool stuff but no one knew how all of that got translated into value for the company and into our roles. Every performance review was tense as I kept pushing for a clearer direction and more pay (as does everyone).

At some point, I stopped waiting for the moment when the path would become obvious. And kept questioning whether I had made a terrible career decision.

Then AI showed up

At first, it was amazing.

I ignored everyone who said “AI would take our jobs” because I found myself performing at a higher level. I was executing at a speed that wasn’t possible before. Tools and workflows got created much quicker because of it. Maybe this was a way of proving my value and finally getting some direction. Maybe, this will bring back the glory days.

But then, engineers, drafters, …. everyone started using it.

And not just chatting with it, they started building their own automations, creating custom tools, connecting AI directly to their workflows. When the digital team couldn’t respond to them because of budgets or politics, they simply used AI.

Suddenly, the threat seemed real.

If people can build their own tools now, why would they need me?

In fact, a quick google tells you that domain experts make the best use of AI. If you’re an expert drafter or engineer, you can use AI to build something amazing because you know the field so well.

So, if my value is connecting people to digital tools, and AI can now do that, what is my value?

If I had focused on being a structural engineer from the beginning, I could be using AI right now to build tools because I would’ve have been a domain expert.

Instead, I’m in this weird middle ground, knowing a lot about software and the AEC industry, but not enough in either domain to be a true expert. If I had stuck to a typical engineering career and just learnt to code as a hobby, would I be in a better position?

Almost a decade later, I guess it’s the same question that still keeps me up at night.

But there’s no such thing as certainty

When I was a graduate, I wanted someone to show me the path to senior.

Then, I wanted to know how to climb the ranks. To know what was next apart from making tools and concepts.

Now, with AI so good at executing and people building their own tools, how do I move forward?

The good news is, as humans, we’re good at recognizing patterns. And the pattern here is that my career has always been uncertain. AI is just the latest version of the same feeling… I think.

And as intoxicating as it is to daydream about “if I just stuck to engineering, my life would be better”, the truth is, I wouldn’t be here if it wasn’t for this weird intersection.

I wouldn’t have started this newsletter or delivered all the incredible projects and tools in the past if I had just been a regular engineer.

And you might be feeling this too

Maybe not about computational design. But about something.

Maybe it’s the job market or the economy. Maybe, like me, it’s the thought that AI is coming for our jobs.

But as the saying goes, “the only constant is change”.

Which means, I’ll never get the certainty I crave.

Which as uncomfortable as it feels (all the damn time), it’s a good thing. It’s what I’ve had to remind myself while writing this. Certainty was never the thing that moved me forward anyway. It was following what was valuable and interesting at the time.

Whenever I waited for the path to become clear, nothing happened. But every time I just did the work because it was interesting, it opened up new pathways for me.

P.S. If you can’t tell, this article is more for me than it is for you. I’m dealing with a lot of uncertainty right now and writing this has reminded me how much I’ve had to navigate to get here.

P.P.S. I’ve got an announcement next week. Let’s just say I’m done waiting for the path to become clear.

Meet Nate.

He’s a senior structural engineer. The kind of person that’s always looking for ways to make delivery less painful.

He was working on a high-rise project which has concrete columns. It was a 23 floor building with about 20 or so columns per level. What engineers then typically do to assess the columns, is a technique called a “column load rundown”.

You take results from the analysis model, put them into a design program, and check that every column works. The problem though, is you have to do this for each column on every floor. On this project, that’s more than 400 columns. And every time there’s a design change, you do it again.

It is as tedious as it actually sounds.

Which is why it’s known as a “rite of passage” for graduate engineers. Because it’s labour intensive and considered as “engineering grunt work”, most companies make graduates do them. That solves the cost issue but it still takes a long time to do them.

So, most companies have some sort of workflow to speed this up. Not fully automated but not entirely manual either. Generally, enough for new graduates produce results in a decent amount of time but still too tedious for senior engineers to use.

In this company, Nate built that workflow. It was an Excel spreadsheet that would take the results from an analysis model and through some inputs, it would design all the columns per floor. That meant, the graduates on this project only had to do this 23 times instead of 400+ times. What used to take three days now took about four hours.

But the spreadsheet wasn’t perfect. It only supported one analysis program and it only handled single-storey columns. And since Nate is busy with other projects all the time, the spreadsheet fell behind with each new requirement it couldn’t handle.

Not to mention, fixing a spreadsheet he built for other teams isn’t in his KPIs. It won’t get him promoted. Upper management only cares about how billable he is, not what tools he’s made. It’s not something he can justify spending a Tuesday on when there are deadlines to hit.

And so, the spreadsheet remains out of date. People still use it because it’s still better than doing the rundowns manually. But they start working around it, adding band-aids to cover for the things it can’t do.

In fact, there’s a new graduate working on this project, her name is Rey, and she’s using AI to build a new column rundown spreadsheet because she can’t get Nate’s to work.

But we all know how that goes...

The tension of being billable vs internally useful

Nate’s story, unfortunately, represents most internal tools ever built in the AEC (Architecture, Engineering, Construction) industry. Unless it’s a company’s core business offering, tools like these always follow a similar story.

Nate wasn’t trying to build a product. He was just trying to get through a painful process faster. He saw a problem, and he built something that fixed it. Which is most people in this industry. No one is thinking about “internal tooling” or “automation strategy.” Everyone just wants something that makes their lives easier.

Not to mention, building something that solves your exact problem is fun and creative. Chatting to AI or even building a new spreadsheet is more fun than doing a column rundown for 400+ columns over and over again.

But the minute you build something useful that everyone else wants, there’s a tension on your time that didn’t exist before. You now have to teeter between being billable and being internally useful because you now accidentally own what you’ve built

Doing a column rundown one by one is slow, but you’re making progress. And you can charge that time to the project because that’s just what it takes to get it done. But if you work on Nate’s tool, how do you charge your time to something that helps on all projects?

It becomes a battle of solving today’s problem vs solving it in a way that lasts.

And companies usually only rewards the first because anytime that isn’t charge to projects is considered overhead. And when the company looks to promote Nate, it’ll be because of his projects, not because of the spreadsheets he made. Nobody gets promoted for maintaining an Excel sheet.

So, you build something useful, and now you’re accidentally responsible for a product. With no time, no incentive, and no support to keep it alive.

If we look at pure software development, there’s a reason why “product management” exists as a completely separate role. It’s the work of tracking what’s broken, deciding what to improve, and checking its alignment with the current business.

It’s maintenance, and it’s treated as real work.

AEC has nothing like this. The person who builds the tool is the product manager, the support team, the developer, and they’re also a full-time engineer with billable targets. Which is why most of these tools die.

The Rebuild Reflex

With AI in the mix now, building things is faster than ever. You can get a working macro, a script, even a small app in a few a hours. The barrier to creating something has basically collapsed.

Which means the ownership problem gets worse.

Before AI, building something took enough effort that most people wouldn’t bother. They’d work with whatever tools they had, even if those tools were somewhat broken. But now, instead of wrestling with Nate’s semi-broken spreadsheet, anyone can just build their own version. I call this the rebuild reflex. It’s when it feels easier to rebuild something from scratch than to understand and maintain what already exists.

And project deadlines accelerate this. You’re even more inclined to build rather than maintain because the known effort of creating something new feels safer than the unknown effort of debugging someone else’s thing. Even if it’s objectively slower, it feels more in your control.

So, instead of one well-maintained tool, you end up with a dozen half-working ones. All doing roughly the same thing but uniquely for each project.

And well, from a numbers point of view, individual productivity goes up because everyone has a new tool that solves their problem. But what companies miss is the drift in quality and standards. When everyone does things their way, there’s no consistent bar for delivery anymore. How do you standardize the way people do things if they are all on unique tools ?

Not to mention, a graduate and a senior can both ask AI to build a column rundown spreadsheet. But the senior knows which features actually matter. They know enough to hone in on where normal spreadsheets fail. They know what “correct” means in context.

But a graduate who just started might just listen to the AI, even when it’s wrong. And if their manager is too busy to do a thorough review, that could lead to a real problem. I don’t even want to think about what happens when that graduate-made spreadsheet ends up in the hands of other graduates. (Yes, I’ve seen this happen.)

The Missing Role

So what did Nate’s team actually need? Well, they needed someone who owned the tool. Someone who could filter through requests, decide what changes mattered, and actually had the time to make them.

In other words, a product owner.

Now, I know that sounds like a role most 20-person AEC firms can’t justify. And that’s kind of true because the reality is that most firms don’t have the volume of tools or the budget to warrant a full-time hire for that.

But that doesn’t mean the work doesn’t need to happen. It just means you have to be intentional about how it happens. Because if you make “being billable” compete against “working on internal tools” for the average person, being billable will always win. Which is why the tools die.

One option is working with someone external who can fill that role for you. Someone who helps develop and maintain your tools without pulling your billable staff off projects. That’s a lot of what I do for my clients. It means you don’t have to keep someone fully resourced on just the tools, and there’s no battle between being billable and internal development.

Not to mention I work with you to figure out the direction of the tools, I don’t just come in and assume control, we’ll still work together on it.

If that sounds like something that could help, reply to this email or book a time to chat through the button below.

Thanks for reading.

Being a “digital” person in the AEC (Architecture, Engineering, Construction) is a weird place to be. Especially, if you work for a consultancy.

To put it simply, there are two modes of operating. Fire-fighting or tool building.

Fire-fighting is solving problems on projects. Scripting, pulling data, fixing models, whatever it takes to get the job done as quick as possible. These are where tools like Grasshopper, Dynamo or Python shine because no one cares about how robust your solution is. They just want results.

Tool building is the polar opposite. It’s when you’ve seen a problem enough times that you decide to invest in a proper tool, something reusable. It’s more like conventional software development, and it’s probably why I got into this field in the first place.

But the problem though is that these two operating modes are not equal. Working on projects is billable to clients. Tool building, even though more beneficial in the long run, isn’t.

So, there’s always a bias towards fire-fighting.

The Competence Trap

If you’ve been doing this for a while, you know how this plays out. You start out as someone who can solve problems quickly. You’re good with Grasshopper or Dynamo or whatever the tool is. People notice and love having you on their projects because you’re efficient and deliver at a high quality.

You start earning a reputation of putting out fires. You solve problems well, deliver at a high quality and let’s face it, you’re also cheap. So, to some extent, putting out fires becomes your value.

So, what happens when you want to build something? You’ve been fire-fighting long enough to see where a proper tool would help everyone. But the team doesn’t see you as the person who builds things, they see you as the person who fixes things.

And those are two very different roles, even if they use the same skills.

You know that if you could free up a week or two, you’d be able to build something that would make things just way more efficient. A true proper tool that could solve the pain points that you’ve been seeing so often on projects.

But every time, you sit to start, you get interrupted. Someone, somewhere needs your help. You’re just too good at putting out fires. And because it’s urgent and billable, you say yes.

Why “Just Block Time” Doesn’t Work

All the time hacks in the world can’t save you here. You can’t just “carve out time” or try one of those calendar-blocking things. If a project needs you, it doesn’t care when you’ve blocked your calendar or what AI tools you’re using. It needs you to put out those fires now.

And if you do manage to protect a few hours, building and fire-fighting require completely different kinds of energy. You can’t fix someone’s Revit model all morning and then design a new tool in the afternoon.

Well, you can. You just won’t do it well. If you’re like me, you’d be tempted to rush the tool building process because you don’t know when is the next time you will get to it.

Building requires a clear head, a longer time horizon, and the mental space to think about problems that aren’t screaming at you. You really do need the space to just sit with the problem.

What Actually Helps

The antidote, as you might guess, is simple.

If you can’t carve out time within a day, you have to carve out whole days or even weeks.

And that means choosing which fires to fight and which to let burn. I said it was simple but it definitely isn’t easy.

Essentially, you have to say no. Which means letting people down. And being okay with people seeing you as the “bad guy” because you didn’t help them. That’s unfortunately, the cost of setting boundaries. You have to learn to undo the reputation that got you where you are.

I don’t know about you, but that’s the hardest part for me. Even though fire-fighting is stressful, there’s a camaraderie to it. You have people around you trying to solve the same problem and when you do, you feel like a hero.

That elated sense of accomplishment when you fixed something under pressure or delivered when the timeline was ridiculous is unparalleled.

When you’re building things that prevent the next ten fires, nobody even knows it happened. The system rewards the dramatic rescue, not the prevention. And unfortunately, making people more efficient is less dramatic than rescuing them from projects.

Balancing Tools and Projects

I’ve definitely not figured this out. I still have weeks where every day is reactive. But I am trying to get better at protecting that all too important tool-building time.

Also, I have noticed that if you’re only valuable because you fix things, that’s a trap. I mean, my value isn’t speed or being “on-call” all the time. It should be my expertise and that means I should be working on things that bring the most value.

That could be fire-fighting if the project was really high profile and valuable. Or it could be tool-building because there is something vital that needs to be built.

The point here is that if I see something that I can build that prevents fires, I should do that, instead of wanting to work on projects all the time. Because it’s all too easy to get swept up by the urgency of projects.

The art is in balancing the billable and urgent projects with building things that actually make a long term difference.

If you’ve been in the same spot as me, I hope this article helped you think through things a bit more and if you’ve been wanting to build something for a while now but are stuck in fire-fighting mode, reach out by either replying or emailing me at braden@bradenkoh.com. Maybe we’ll find something awesome to work on together.

As always,

Thanks for reading.

~Braden

About ten years ago, a steel roof panel fabrication company built an internal tool that changed how they worked. With some inputs and a button, the tool turned an engineer-designed Excel spreadsheet into a 3D model and drawings. It became an integral part of their client delivery process.

For what they needed at the time, it was perfect. They delivered faster and more consistently than they ever had before.

But over the decade, things changed. The company grew and started taking on more custom projects from clients. They expanded from one product line to five. They are now also looking to migrate to Tekla Structures, a more modern program than what they were using. And all this while, there were no updates to the tool. It still used the same templates and workflows from a decade ago.

I was brought in because they wanted to explore migrating their tool to Tekla. I thought it was going to be straight forward, after all, most companies don’t have such a strong workflow. But what I found instead, was a tool that was poorly designed, full of hard-coded variables and worst of all deeply entwined with old processes. The kind of thing where changing one thing breaks everything else, a glass cannon, if you will.

The tool also only worked for one out of five product lines. The templates that once standardized their process now blocked the custom work their clients were asking for. And moving to Tekla meant an overhaul of 15 years of accumulated process decisions and assets.

Needless to say, the quote was expensive. And sadly but unsurprisingly, they didn’t accept it.

How tools drift

So this is actually one of the most common ways internal tools become a problem. The tool was right when it was built. It met the needs of the entire business. In fact, it even enhanced their delivery.

But time doesn’t stop and neither do the needs of the business. As they grew, the people that worked on the tool left and it was never maintained nor updated. When that happens, the context for why the tool was built the way it was goes with them. The tool bifurcated from what the business needed it to do. Yet, they kept using it because it was easier to workaround it than to update it, at least, until now.

In my experience, there are three ways a tool falls out of alignment with the people using it.

The process changed but the tool didn’t.

The team refines how they work. They adopt new standards, restructure how they deliver projects, maybe even expand into a new line of business. But the tool stays locked in time.

Sometimes it’s because nobody budgeted for updates or maintenance. But most of the time it’s the sunk cost fallacy, companies think once they invested in building the tool, they should only reap the rewards. That they’ve invested three months into development, so why would they keep putting money into it?

Success expanded the scope.

Counterintuitively, sometimes success is why internal tools fail. I’ve seen cases where the first release was so well-received that requests flooded in. And instead of redesigning and integrating those properly, new features just got tacked on. And on. And on. Until updating it means untangling years of organic growth that was never structured to scale.

The tool kept taking on more responsibility without the proper foundations to support it. Making a tool for one person and making a tool for a company are very different endeavors. So, it becomes more brittle as time passes, making both the usage and maintenance of the tool progressively harder.

The team outgrew it.

Tools work best when there’s a solid process behind them. The fabrication company built templates for their tool, which is smart because the more standardized the process, the easier it is to automate on top of it. That meant for repeat clients, they could save about 50% of turnaround time.

But adding templates also meant tightly coupling the tool to their old program. And as the company took on more custom work and expanded their product lines, they outgrew those templates. Every time they tried to update them, something broke. So they stopped trying and just worked around it instead.

Now, the templates that once sped up their delivery, now hindered the work they actually needed to do. The tool went from working for them to working against them.

Why it’s hard to notice

These three things happen when nobody’s monitoring the alignment between the tool and the company. It also doesn’t help that the tool doesn’t give you any indication of misalignment.

The tool technically still works and since it’s too fragile to update, people just work around it. They add a manual workaround here, a workaround there. Each one doesn’t feel like a big deal. But, over time, these workarounds then become the default mode of operating.

The fabrication company only found out about this misalignment when market pressure forced them to move. By then, fixing it was expensive and an operational nightmare, when it could have been a series of small, incremental updates spread over years.

Functional vs alignment

So, it comes down to what I call functional vs alignment.

Most tools work, they are functional. You put in the inputs and it spits out a result. It does exactly what it was designed to do.

But that’s the baseline, it’s what any tool should do at its minimum. The better question is whether the tool is aligned to the way you work. As in, when you have new processes, does the tool work the way we want it to?

“Functional” is a technical question. “Alignment” is then a people and process question. It’s about whether the tool matches the way the team actually operates right now.

A tool can pass every technical check and still be the wrong tool for the job. And depending on how far the tool has drifted from the current process, it becomes a burden rather than an advantage.

That’s much harder to find because you can’t test for it. There’s no error message that says “this tool no longer fits your process.” And in fact, what people don’t always realize is that the more you build now, the more you have to maintain.

Misalignment is dangerous precisely because it’s not visible until it’s already expensive to fix.

What actually fixes this

The instinct is usually to rebuild. A clean slate with new requirements and fresh energy. That’s what the fabrication company wanted. They didn’t want to deal with the complexity of an old, poorly designed tool. So the idea, was to migrate what made the old tool work into a new one.

Which for them, even though they declined my offer, is the best move. Because the old tool has diverged too far from the original design. But if they simply rebuilt the tool and not maintained it, they would be repeating this cycle over again.

The good news, is that there are two things anyone can do to break the cycle. They are simple but like most things, they aren’t easy.

Check the fit regularly.

This is the biggest lever you have. Any time an existing tool causes friction or you find yourself making a workaround, ask: does this tool still fit our process?

This single question combined with having regular review sessions will ensure that the tool is aligned with how any business is moving. If there’s friction between the tool and the way you’re working, it’s a signal that the tool might be out of date and it’s time to put in a fix while it’s small.

And if you can document everything diligently, you end up with a history of how both the tool and your process have evolved, which is incredibly useful the next time someone asks “why does it work this way?”

Make room for small changes.

If the person closest to the tool can see the drift but can’t do anything about it, you’re just watching the problem grow. It doesn’t always mean rebuilding. Sometimes people just need the room to make incremental changes without it turning into a budgetary affair.

I have seen this time and time again when drafters make manual workarounds for internal Revit plugins. Whether the plugin really should just be updated but the company didn’t want to invest in the plugins anymore until it was causing them too much trouble.

If you budget for maintenance from the beginning, smaller adjustments made earlier will cost a fraction of what they cost later. Let the problems accumulate and the effort / time it takes to fix them will compound.

When the tool has already drifted too far

Okay, what if you’re already in trouble? The workarounds have calcified and incremental updates just makes things worse.

Then, unfortunately, you do have to rip off the band-aid and rebuild. But this time you have the chance to do it right, with proper design, documentation, and communication. You give the new tool a better chance of surviving longer than the old one.

It’s expensive but there are some suggestions on how to ease the cost of it. Like building features incrementally or rolling out new updates over a period of time rather than a hard switch between the old and new.

The hard part was never building it

Building the right tool is a moment in time. The requirements are clear, there’s energy and momentum. People are excited, you have AI, and it can even be fun.

The hard part is keeping it the right tool as time goes on. I keep coming back to maintenance because I’ve seen tools that had good intentions and design decay from the harsh reality of time and changing business needs. If a tool is critical to your business, it should evolve with the business. Not stop the day it launched.

And I get why companies don’t prioritize this. Tool maintenance isn’t a full time job, it needs attention regularly but not constantly. The problem is that hiring someone just for that is hard to justify. Which is why the default is to only work on it during their “free time”. Maintenance, as important as it is, gets squeezed in-between projects.

That’s a lot of what I do. Yes, I build tools but I also stay close to the work after we’re done. After we build something, we have what I call a “Hypercare phase”. A dedicated time each month specifically for the kind of alignment work that we’ve seen here. It’s not squeezed into free time nor is it only when something breaking, it’s built into the engagement from the start.

If you’ve got a tool that still works but doesn’t quite fit anymore, or if you’re about to build something, I’d love to hear about it. Simply reply to this email or use the button below to book a call.

Thanks for reading,

Braden