Every Tool You Build Has a Price
even the fast ones
A few posts ago, I talked about what makes a solution (a script, a workflow or anything) last. How do you know that what you're building today will still be valuable six months from now?
My answer was a triangle with three important variables: creation, updates and usage.
It's my take on the popular iron triangle from project management (scope, time, cost). And like that triangle, you can’t have all three, there’s always a trade-off somewhere.
But what this triangle misses is how your solution delivers values over time. Every time you build something, there's an inherent cost to value ratio that you should be considering.
The Problem with “Just Solving It”
In the AEC industry, everything feels urgent. Everyone wants a solution yesterday. Deadlines are tight. Budgets are tighter. And I still want to go home on time. There is so much pressure to just "solve it now" and worry about everything else later.
But tools built in a rush are never robust. Over time, they will break again and again, each time costing more to fix than the last. Eventually people stop trusting your solution and revert back to their old ways.
Or what's worse, they want to build something new from scratch again. Since tools like Grasshopper, Excel, and Python, it’s easy to spin something up quickly. But that doesn’t fix the deeper issue. It just repeats the cycle with a new name. Design Tool_V4_Final_Final anyone ?
If we want to build tools that truly change how people work and provide lasting value, we have to look past the immediate deadline. That means identifying recurring patterns worth solving. Even if that slows us down for this project. It's about betting on the long game, not just surviving the sprint. It's about having faith that we are solving something bigger.
Types of solutions
But that doesn't mean we should only work on big-picture ideas. Sometimes a quick fix is absolutely necessary and can be a lot of fun to solve. What I am arguing for here, is the intentionality of we are building. Did we build something for the project? Or did we build something for the entire business ?
Most brittle tools I’ve seen come from mixing those two up, using a quick fix meant for one project as if it were built for the long term.
That's why in the longevity of a tool post , I introduced three types of computational solutions.
One-off scripts
Reusable templates
Proper tools
Each has a place in our work, but the goal isn’t to turn everything into “proper tools”. It's to understand what you’re making and why. Again, it's about being intentional.
Thinking about value (and cost) over time
We covered a lot about the longevity of tools but not enough about it's value and cost. It's tricky to define what makes a tool “worth it" simply because it's hard to predict how often and how many people will use it. To me, the most accurate metric is number of users. But even then, while it's helpful to know, it doesn't tell the full story.
A rough mental model that I use now is this:
Value = (Number of Users × Frequency of Use × Impact) – Cost to Maintain - Cost to develop
You’re not going to be able to put numbers in this equation but that’s okay. The point is to consider the full picture. It helps me consider all the aspects of what makes a tool valuable and whether it's worth investing the time and effort in making it.
For example:
A script that saves 30 minutes once is useful to projects but limited in impact.
A tool that saves 10 minutes a day for five people every year provides real compounding value, but it may take way longer to create such a tool.
Using this equation means, doing the work to understand all parts that make up the value of a solution. It may mean talking to future users to get an idea for the number of users. Or understanding how frequent this problem occurs. Or how much effort would it be to maintain this new workflow. It ensures that I am treating the root problem not just it's symptoms.
The general cost and value of solutions
Over the years, I have noticed a pattern in how each solution type behaves over time. Let’s see how they compare.
One-off Solutions
These are tools that are easy to make but hard to maintain over the long run. They are mostly used in a pinch or to solve a specific problem. Like this script that I wrote to extract centerlines from models.
Reusable Templates
These are tools that can be reused but need some tweaking to make it work for specific situations. Like custom Revit familie that can reduce the errors in the drafting process but still needs the right parameters to work properly. Or this Grasshopper script that creates 3D visualization from properties of a model.
Proper Tools
These are tools that mirror normal software. They take longer and more effort to create but when done correctly will provide lasting value for very little maintenance cost. It also takes some planning and skill to ensure that the design of the tool actually solves the problem at hand.
Note: sadly I don't have any personal examples of this, since I can't share the tools that I have made because they have sensitive company intellectual property
So, the next time, before you build...
Step back and consider the intention. Consider how long the solution will last and how much cost/ value it actually takes/delivers. I know it seems like a lot to think about especially if someone is just asking you to solve a simple problem, but planning now pays dividends later. And in my experience, there is no such thing as "simple" or "one-off".
And sometimes, a fast script is the right answer. But even when you're moving fast, being intentional means you’re less likely to confuse a band-aid for a real fix. If you can get even rough estimates for how many people might use your solution, how often, and how much time it saves, you’ll have a much better sense of whether it’s worth the investment.
We often judge tools by how quickly they were built. Or how much time they saved. But time works both ways. A tool that saves time today might cost you more in the future, especially if it was not planned or designed well because you had to rush. Everything has a price. You either pay it now, or you pay it later.
Thank you for reading, your support means the world to me.
Consider subscribing if you haven’t, it helps me know my work is useful. You’ll also get a gift from me as a thank you.