Lately, I’ve been reaching out to companies about automation. And a common response I get now is that they’d rather use AI than hire someone like me. To them, it’s $20–$150 per month plus what they already pay their engineer to build new tools. Someone I’ve worked with before even told me, “Yeah, we’ve been using AI a lot which must be a hard blow for your business.”

That is a pretty good way to trigger a small midlife crisis. Especially since, I’ve spent almost a decade solving engineering problems with programming and visual scripting, and I’ve just left my full-time job to build a consultancy around automation for firms.

When I first started using AI, I was excited by how much more I could do. It doubled or even tripled my productivity and made me so good at my job, that I hadn’t even considered what that would mean when everyone else could build things too.

And as sucky as it is, it’s just the way of the world. From their side, describing what they want in a chat looks cheaper and easier than hiring someone to build it.

Okay, that is on the tool and programming side, what about visual scripting?

A large part of my work is using tools like Grasshopper and Dynamo to build scripts and tools for projects. A lot of those projects would not have gone smoothly if it weren’t for visual scripting.

But was that just because it was easier than programming? Does the use of AI now mean that it’s actually easier to generate code than to use visual scripts ?

The era of generic yet bespoke tools

The biggest advantage I see with AI-generated tools is being able to describe the exact workflow you want in a chat. You can give it as little or as much detail as you like, and it will move heaven and earth (on your computer) to make that happen. Even if it has to make stuff up.

It can be a small app or even a complex platform, but you get to control how it works and, to some extent, how it looks. Even if it looks similar to other AI-generated stuff out there, it’s tailored to the way you want it to work. Through a conversation and you are part of the creation process of your very own bespoke tool. It’s the IKEA effect, but for automation instead of furniture.

Compare that to giving someone a Grasshopper script. They need to get Rhino, the right plugins, then learn how to navigate the script. Even for someone experienced like me, someone else’s giant script can take a while to figure out. Not to mention, one small data format change and the script may break. You can fix it, but you have to understand enough of the components, data flow and the script itself to know where to even begin. AI-generated tools may need fixing too. But with AI, you just describe what went wrong and it’ll fix itself.

The role of visual scripting in an AI era

So, with all the downsides of visual scripting, why use it? Why not just get AI to keep whipping you up plugins for all your automation needs?

Well recently, I needed to create a parametric model of a facade baffle. In Grasshopper, that just meant connecting a bunch of geometrical and data components I already knew how to use. It took me about 2 hours to get the script up and running with the right inputs and no errors. Here’s what it looks like.

Now, imagine trying to explain that to an AI. Imagine trying to describe that with words. I think it would have taken me just as long, if not longer, to explain what I needed properly. In fact, just try explaining that to a friend with words.

Also, if I went through the AI route, it could only create that model in Rhino through scripts. Which meant I had to run it, look at the geometry and describe the fixes I wanted. Then, I’d have to delete the old geometry, get AI to make the changes and then run the script again. In Grasshopper, all I had to do is keep tweaking the components and the geometry changes. The feedback loop is instant.

Geometry can be hard to describe in words. The same goes for anything “graphical” like UI design.
I can see what I want, but explaining it with words is hard which reminds me of the Exact Instructions Challenge from a few years ago.

For geometry work and exploration like this, visual scripting is often still the quicker and better option. The instant feedback lets me see whether I got the geometry right or wrong without having to re-describe what to change.

Where I think AI takes over visual scripting is in the “tool” space. Where people used to create “tools” with Grasshopper, AI generated plugins do a much better job. A “tool” here refers to something that can be used repeatedly and by many people.

Plugins (AI-generated or not) are just easier to deploy to other teams and people. No one needs to know how to navigate Grasshopper or Dynamo just to use the tool. And since we can control how the interface behaves, we can tailor the user experience to exactly what they need to see and use. We don’t have to force our users to browse a visual script anymore. AI makes building that kind of interface and function more accessible now.

What if we add AI to visual scripting?

But, it doesn’t have to be AI vs visual scripting. What if we add AI to visual scripting? Can it overcome some of the short comings of pure AI or pure visual scripting ?

This year, Autodesk just added its Assistant to Dynamo Core 4.2, where it can generate and modify graphs. There are options for Grasshopper too, like Raven, which can build and edit scripts.

When you use AI to build a plugin or an application, checking its work means going through the code it generated. Which, maybe you can read but it’s going to be the best experience unless you really know how to use AI to generate code. But if it builds a visual script, following the components and connections is a lot easier. Especially if you know Grasshopper/Dynamo but not code.

So having AI assist us with visual scripts might mean that we get the benefits of AI but an easier time modifying it’s work than raw code.

I can see myself setting up a complex visual script for the geometry, then asking AI to help fix the data when an input format changes. Which is one of the most common errors and it’s usually the most time-consuming part to fix. With the components and connections already there, I wouldn’t have to describe the whole thing from scratch. I could point it to the problem, then follow the graph to check what it changed.

But it doesn’t take away the deployment problem. Sharing visual scripts (AI made or not) would still mean other have to know how to navigate Grasshopper / Dynamo. But it does mean that we have way more options now. Instead of AI vs visual scripts, we can opted for both now too.

So, what does this all mean?

There’s still a place for visual scripting, AI doesn’t entirely replace it.

The fact that Autodesk is adding an assistant to Dynamo means they think so too.

When I’m exploring geometry, being able to see the result and tweak it straight away is a key part of the development process. And being able to configure different ways of creating that geometry is still a very important part of the process.

Replacing that with an AI generated plugin just doesn’t make sense. The development cycle is more cumbersome and it’s hard to explain geometry to the AI in words. But adding AI to visual scripting might just give us the best of both worlds.

So, with those client conversations. AI lets their engineers build more themselves, and it makes me more efficient too. But an engineer with AI isn’t always the right setup for any problem. We’ve seen that if you don’t have the digital experience or the skillset, AI tends to suffer with geometry work and creating tools that need to scale.

As cliche as it sounds, the right solution depends on what needs building, the skills involved and how much time (money) you are willing to put into development.

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

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

For two years, I told people I couldn’t help them even though the tools they relied on for their projects kept breaking. Tools that I help make.

On paper, I had a great reason. I was working on one of the biggest projects the Melbourne office ever had. It was high-profile, massively urgent and needed all hands on deck. There were even people that couldn’t even go home during the holidays because of it.

Still, I had other drafters and engineers come to me with something broken or an improvement they needed on the tools that I helped built. But, I didn’t have the time to help because this project was the priority.

And from the company’s perspective, it’s the “right” move. The project brought in revenue and the company’s reputation was at stake. It’s even the "right” move personally because excelling on this project was the golden ticket for my manager and my manager’s boss.

But letting everyone else down because of it felt wrong. It’s shortsighted to go all in on the project and leave the internal tools broken. What would happen after the project ended? Would the glory of this project make up for letting everyone else down? Would they still trust me to build tools after this ? I am responsible for the people relying on them in the first place.

Even when I found time to help, I was always rushing. That might have made things worse, but I never knew whether I had two days or fifteen minutes before the project pulled me back in. So, I took whatever “free” time I had and went went as fast as I could. I was trying to squeeze in as much help as I could give.

If you balance project work with tool work, this is a struggle you probably know too well. It’s also a common theme I’ve touched on several times but I thought running my own consultancy meant I would have the freedom to do things differently.

But a few months in, earning money immediately through projects is still too intoxicating.

Long term vs short term

I no longer have internal tools to build and maintain but the tools I’m building now are products I hope to sell. So, I still have to choose between paid work in front of me and building something that might become valuable later.

With project work, there’s urgency, pressure and accountability to other people. With tools, there’s still pressure but it’s less urgent. In fact, the pressure is subtler because at least for me, it comes in the form of guilt.

Guilt that I let a product idea or development sit there for weeks because I am too busy delivering on projects. I know that a well-made tool can be more valuable in the long run than spending another week on a project. But I also know that only building tools is not financially sustainable. And spending all my time on projects and I might never build the tools or develop the skills that would help me in the future.

So, as cliché as it is, there’s a balance here.

We’ve established that trying to do both makes it easy for the short-term work to win. I doubt most managers would ever prioritise an internal tool over incoming revenue. Heck, even with my own consultancy, I struggle to do it.

I told myself, “After this week, I’ll take some time to work on those products.” That was two months ago, and I still haven’t started.

Protected capacity

Okay, so I needed to do something before I got swept back into working only on projects, just as I had in my previous job.

After researching how other firms operate, I decided to try protecting my own capacity for each kind of work. I would choose how much time to give projects and products, then put that time into my calendar before the week began. Reading Richard Rumelt’s Good Strategy / Bad Strategy helped me think through the choices behind that plan. A lot of it was about taking concrete steps instead of just dreaming that the right balance would come.

First, I had to answer what am I actually trying to achieve? Both in the work itself and financially? What do I actually want ?

For me, that meant creating a sustainable business where I can provide value and work on things I want to work on. Financially, that meant I wanted to make back what I used to earn, then work out what growing that income without taking more of my time would look like.

Super vague, I know. But that gave me somewhere to start. Then with that in mind, I needed to work out how to actually do that, which is the second question.

What kind of business would let me achieve those goals?

I needed to understand what a “sustainable business” meant within what I can do and what I’m willing to do. For me, that meant taking on client projects and building my own tools to sell. I will always want a mixture of the two. I enjoy projects, and they give me problems worth solving, but I also want time to develop my own products.

I’d like to see them as equal instead of “products” just filling in the downtime between projects like most firms do. So, then what are the concrete steps I can take to get there ? How much time do I want to spend on each?

A 50/50 split between projects and products seemed like a reasonable starting point for me. But I already knew that I can’t just say that, I would have to put in place something that forces me to achieve that.

Which meant getting really clear on where I am spending my time. What I now do is look ahead one or two weeks and put “work blocks” into my calendar. These are chunks of time dedicated to projects or tools, arranged around meetings and other commitments in life.

That lets me see how my time is spread out before I commit to more work. As the days progress and priorities change, I can move the blocks around and check whether I’m still making room for both.

If a project takes over a tool block, I can move that block to another day and see when I’ll return to it. That takes some of the guilt out of postponing it because I know I’ll have another session. This has been essential in stopping me from rushing product work all the time.

Making room

The blocks also give me something to review. I can look back at how I intended to spend my time and compare it with what I actually did.

Some weeks, the project is all-consuming. I can accept that. But if I still want to build products, I need to make more room for them in the weeks that follow. Otherwise, I will keep saying 50/50 while spending my time 90/10 and I am right back where I started.

I wish I’d had that clarity at my old firm. I wanted to sit down with my manager and talk about the broken tools, the people relying on them and the project commitments competing for my time. We could have weighed the consequences of delaying each kind of work and agreed on what I should do next. Instead, project work was always the number one priority, there was no conversation at all.

This whole “plan ahead with a vision” strategy works for me or even smaller teams but I can see how difficult it would be for larger firms. As simple as it is, they would still have to agree on how much time internal tools need, plan that work alongside the projects and revisit the plan when a deadline disrupts it. Combine that with office politics, role hierarchies and you’ll get a huge confusing mess.

I’m still figuring out the balance in my own business too. But I have to do something about working on all the things that matter to me instead of only on what is urgent. I want time to work through a problem properly, without wondering whether I have two days or fifteen minutes before I have to drop it again.

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

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

I remember a colleague of mine, now a friend, coming up to my desk one day to ask me a question. Let’s call her Kate. It’s not her real name, but it’ll do.

She sat beside me and asked, “Mind if I run something by you?” She opened her laptop and started to show me the problem.

Kate had been copying and pasting bending moments for each floor from her analysis program into Excel so she could design the columns on her current project.

On a smaller building, copying the results might take an afternoon. On a taller building like this one, the work would normally be split between a few engineers, with each person taking a range of floors.

This time, two of the engineers were off sick, and Kate needed to design all the columns alone while managing three other projects. What she needed was a way to speed the entire process up without taking up so much of her time.

We immediately got to work. I searched for ways to automate the workflow while she explored what the analysis program could do. There was no API, but with the right settings, it could produce a file with a consistent format, which meant a custom script could read that file and transfer the data into Excel.

So, we tried it.

Sitting side by side, we tested a few program settings and versions of the script. Sometimes the file didn’t have enough information and Kate had to dig through the settings to get it right. Other times, the script failed because there was a bug. We spent about two or three hours going back and forth before we had something that worked.

But that effort paid off. By the end of the project, Kate had probably used the script ten to twenty times, even after meeting the first deadline. The project conditions kept changing and the columns needed to be redesigned, but she no longer had to copy the results over by hand.

The friction being the external person

Now that I run my own consultancy, it isn’t as easy for people to come to me with their problems anymore. I knew I would lose some of that seamlessness, but I didn’t know how hard it would be to recreate that experience.

The work itself doesn’t change. Someone comes to me with a problem, we explore it a little, then decide whether to build something. But that conversation is different when we work for different companies.

People can’t walk up to my desk anymore. They can’t sit with me through a problem. In fact, before I can even see the problem, I might need to sign an NDA. They might be worried that I am too expensive. Heck, they might even think AI can do it, so why talk to someone like me?

All of that makes sense. We no longer work for the same company. Their projects and client information need protecting, and both of us need to know what we are agreeing to. But this creates a lot of friction before we even get to the problem.

When Kate and I worked for the same company, it was easy not to worry about trust and money. As someone external, I needed a way to make the work feel safe for someone who had never worked with me before.

When I started CodedConstructs, I thought fixed pricing would do that. I would do so much for free because I wanted people to be clear on exactly what we were solving. I would have several meetings, do analysis work and even prototype some stuff, all to be sure before we ever agreed to work together.

It felt honest because everyone was clear on the work, and a fixed price meant the client wouldn’t get a larger bill if I took longer than expected.

It felt like the safest way to work, and it had worked well for my past clients.

Kate only had to sit beside me and open her laptop. A new client had to sign an NDA, send me their files, explain the workflow and then decide whether to spend thousands of dollars with me before we had solved one thing together. It was still too much friction. They faced a large upfront commitment, while I could spend a week on discovery work and still hear no.

It also killed any opportunity for smaller automations. The script I made with Kate would never have made sense between two companies. I could have built it in the time it took to hold the meetings and write the proposal, while the cost of all that admin could exceed the cost of the tool itself.

Those smaller jobs were also our chance to solve something real together before either of us committed to something larger.

Trying to bring some of it back

I had overcorrected. I knew working between companies needed more paperwork and clearer boundaries, so I made the whole engagement feel like a handover. The client describes the problem, I define the complete solution, they sign the contract, I build it and they pay for it.

That felt like how an official consultancy should work. But it created one large decision at the beginning, when we knew the least about the tool, the problem and each other.

The clarity still matters, though. Everyone still needs to understand the problem, the solution and whether the cost makes sense. But I had inflated all of that into an admin nightmare instead of just trying to solve the problem.

Sometimes a fixed price will still be the right choice. If the problem and outcome are understood, it gives everyone certainty about what will be delivered and what it will cost. But if an idea is still unclear or if someone is unsure about it, a smaller first commitment gives us room to learn and explore before we agree to the complete build. It also gives us a chance to find out whether the thing we think is valuable actually is.

So, I have started offering hourly work again.

Hourly pricing alone doesn’t make the work safer. A complex solution will take as long as it has to take. I still estimate the effort, agree on a limit and stop for a conversation if the direction changes. But starting with a few hours reduces the friction of committing to a large build when you don’t even know if it’s valuable or if you trust me yet.

It also creates room for scripts and rougher automations that a fixed build might not justify. Someone can bring me one awkward script or one part of a workflow. We can work through it using their real files, see whether it helps and learn how we work together before committing to something bigger and more polished.

A smaller place to start

Hourly work won’t suit every project. Some problems are clear enough for a fixed price from the beginning. When the problem or solution is still uncertain, starting with a few hours gives us a lower-friction way to work on something real before either of us commits serious time and money.

The point is to choose how we work based on the trust between us and how much we understand about the problem. Fixed pricing can make a well-understood build predictable. Hourly work can give a muddier idea room to develop, provided we agree on the limits and keep checking whether the work is still useful.

I can’t recreate Kate walking over to my desk and opening her laptop. But I can create a smaller place to start with a new client. We can open their files, work through one real problem and decide together whether we should keep going.

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

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

A client once asked me to review an automation they had been using for years. They were an engineering manufacturer with several product lines, but the automation had only been built around one of them.

It was old but still really good. An engineer could configure the product in a spreadsheet and, with a push of a button, get a 3D model, a list of materials and a detailed set of drawings ready for production. They still had to clean up the drawings and add any custom parts, but the tool removed a huge amount of manual work.

Now, they wanted that same kind of efficiency for another product line.

The obvious starting point was to repurpose the tool they already had. But the tool had grown around the first product over several years. Its code, templates and rules all carried decisions made for that particular product. The client suspected that adapting the whole application would be expensive and bring across features the new product did not need. They still needed to know whether any of it could be carried across.

I was brought in to move the automation across. Given its history and complexity, I suggested we begin with a discovery phase. I could not assess a tool that had been working for several years from a surface-level explanation.

I discussed the existing and proposed workflows with the client and inspected the current tool’s code. Because I was coming to it fresh, I could stop and question decisions that had become a normal part of the workflow. I looked at which rules belonged to the underlying engineering process and which parts had grown around the first product line.

We spent close to a week in meetings and reviewed the codebase against sample files. The findings were close to what the client suspected. The current automation depended heavily on templates, parameters and files that were specific to one product line. Carrying all of that into the new product line would add functionality the workflow did not need and make the new application harder to maintain.

Rebuilding everything from scratch would also waste useful core engineering code. The application itself was the wrong starting point, but the codebase already had the company’s standards and rules baked in. Those parts were worth reusing.

My final recommendation was to keep the existing automation where it was and build a new one around the second product line, reusing only the engineering logic that genuinely belonged to both. That would preserve what already worked while giving the second product line a tool designed around its own workflow.

The client’s hunch was right, but the discovery phase still mattered because it turned that hunch into a clear direction.

A correct hunch still needs a build plan

Clients usually know their own workflows better than I do because they use them every day. They know which parts cause trouble, where people lose time and which tools have become difficult to work around.

A reasonable suspicion and a goal are enough to begin investigating, but they are a poor basis for defining the scope and price of a build. Suspecting that the existing tool would be too expensive to adapt told us nothing about what to do next. If it was too expensive, what should they do instead?

So, we needed to find out whether the expense came from the code, the rules, the templates or the way the tool had grown over time. Maybe the hunch was wrong and replacing a template would have been enough to keep it working for the new product line.

The discovery gave us the evidence we needed to explain the hunch. We could show why adapting the whole application would be expensive, which parts were still worth reusing and what the next steps should look like.

The investigation should match the uncertainty

Not everything requires such a detailed discovery phase. A small script and an established application carry different risks, so they do not need the same investigation.

The time and effort needed to reach an answer scale with the uncertainty. We still need to understand the pain points and the workflow, whether we are building a script or a full application.

Before I scope the build, I might ask for sample files, process documents, the codebase or the tool itself. That material gives us something concrete to investigate and a basis for deciding what comes next.

But we cannot stay in discovery forever. At some point, more investigation stops removing meaningful uncertainty and only delays the build. I tend to match the investigation to the consequences of the unknowns. If we cannot explain how it should work, what the inputs and outputs are or which assumptions could change the scope, then we still need to investigate more.

Sometimes a call and a few sample files are all it takes. In a case like this one, it can mean working through the manual process, the current problems and the existing code.

In the end, the client did not get a surprising answer. Their hunch was correct, but it was now supported by evidence and they have a clear direction on how to move forward. They knew what to leave untouched and what could be reused.

So if something is complex and you have a hunch about it. You should test it before making any decisions. This sounds like common sense but in this AI era, it can be so easy to over build something because it seemed easier.

The whole point of this is to understand what is going on and how to move forward.

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

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

Alright, week 8.

Two months into doing this full-time.

I hit another wall, or maybe an obstacle? I don’t know yet.

For the past two months, a big part of finding clients has been outbound marketing. It is the modern version of door-knocking. Instead of physically walking up to someone’s house to ask if they are interested in what you are selling, you send a cold message in form of an email or DM.

It is also notorious place for spam and people bothering you with stuff that you really don’t want. But when outbound marketing works, it is a way to let people know you exist.

Well, I don’t want to spam people. I don’t even think it would work if I tried anyway. I can’t email 10,000 people asking, “Hey, do you need automation?” and expect everyone to come running to me with their automation needs.

So, I have been using AI to help me find and filter for companies and teams that I think might benefit from what I do. I look for signals on their website or someone’s profile, then write an email around what I can see and what I think I can help with.

Basically, I acknowledge the signal, tell them about my experience or something similar I have done before, then explain where I may be able to help. It is a bet that the signal points to a problem they have that I might be able to help with.

And I did get a few replies and meetings from it. It was enough to make me think it was semi-working.

I knew my reply rates were lower that usual, but I am only one person, so I don’t need that many clients in one go.

Looking at the numbers

I couldn’t put that feeling to rest. So, this week I decided to do a bit of a data dive. Now that I have been doing outreach for two months, I have some data to look back on.

I wanted to know whether it was actually working, so I pulled the data together and looked at it properly.

My reply rate was about 5%. These are replies not whether or not it led to projects.

It was abysmal.

I felt really shit when I saw it. I mean, I know I am new to this and the first few emails I sent were really clunky, but it still sucks. It felt like I wasted two months of my time just flailing around.

So, I stopped what I was doing, took a break and re-evaluated the whole thing.

I am not going to start spamming people as promising as the “marketing gurus” on outbound marketing makes it sound. And the idea of using signals still makes sense to me. I have to change how I am doing it. And I have to experiment more instead of sticking with one thing and hoping it will work.

This will be the third direction I have tried in two months now. Every time I think I understand outbound a little better, I find another mistake I have been making. Or that it’s a failed experiment.

It is depressing to look back and think the last two months could have gone differently if I had known then what I know now. Yeah, I know there’s a quote somewhere about hindsight and all that. But it doesn’t mean it still doesn’t suck.

Never have I been so envious of people that started their own business and it just worked from the start. For me, it feels like running one experiment after another until something works.

It is me saying to the market, “Here’s what I believe in. Do you think it works?” and the market telling me to shove it where the sun don’t shine.

I don’t know if the next version will work, but I guess that’s the process, ey?

Alright, thanks for reading.

Onward to week 9.

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

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

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/

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

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/

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

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/

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

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/

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

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.

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.

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/

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

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/

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

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, come have a look: www.codedconstructs.com.

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

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/

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.

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

Computational Design Courses: https://learn.codedshapes.com/

Scripository (A library of computational scripts): https://scripository.com/