Why the Thing You’re Building Won’t Last
What separates a quick fix from a lasting solution
This week’s been rough. I have been dealing with so many problems with people and computers.
On paper, computational tools are great. Write a python script to automate the extraction of some data. Create a small Grasshopper script to model some geometry. Knowing how to use these tools can genuinely save a lot of time and effort.
But, trying scaling any of these tools across a team or worse, an entire company feels like a Sisyphean task.
Let's say I write a small but useful Python script and want to share it. Here’s what someone else would need:
Python installed (which is harder than is sounds depending on the IT team)
The correct packages installed (again, made more difficult by VPNs and firewalls)
A program to run the script and edit it's inputs (like VS Code or PyCharm)
And finally, some basic knowledge of how to tweak the inputs (like what strings are)
And that’s just getting the first version to work. Now imagine trying to push updates. Or dealing with someone’s new computer. Or that one package version that is slight different to yours but causes the script to fail and it's entirely your fault. Yes, I speak from experience. It’s never “plug and play” like people think.
There’s a reason software companies have deployment teams. Creating the solution is one problem. Delivering it is an entirely different one.
And it’s even worse in computational design, not because it's more complex, but because they weren’t built with deployment in mind. Grasshopper, Python, Dynamo... they’re amazing environments for creation, but they lack basic infrastructure for distribution. Yes, yes, there are some third-party solutions, but most sit behind paywalls or feel like clever hacks held together by duct tape.
To make things harder, we’re often bridging old and new tech at the same time. Take Revit as an example. A plugin that worked in 2024, no longer works in 2025 because Autodesk finally decided to upgrade something. So now, you have to maintain compatibility for both versions.
As amazing as computational design is for solving problems, scaling any kind of tool, even the simple ones, is hard to do seamlessly.
But why does this matter ?
A common argument I hear is: “Let’s just solve the problem first. We’ll figure the rest out later.” Project deadlines are tight. Budgets are also tight. So the default instinct is to solve first, then think about distribution later.
But that’s short-sighted. What you make affects how you deploy. And how you deploy shapes what you can actually make.
This matters even more when you’re building something for a team or a company, where there’s often an unspoken expectation that anything you make is "reusable". Maybe it works fine today because you manually copied folders, hardcoded paths, or wrote a setup script. But six months from now, nobody remembers how to set it up, not even you. And when the tool breaks and it will, they will blame you.
So what happens next? People stop using your tool. They start building their own version, because getting yours to work was too hard. It kept breaking and they have lost trust in it.
That's why how you distribute your tools should shape how you design it. If it needs to be deployed company-wide, maybe you write it in C#. It takes longer, but it’s more stable and easier to deploy. If it’s just one other person, a quick Grasshopper script might be perfect. Fast to write, quick to tweak.
There are no rules to this, but you have to ask the question before you build anything.
What affects the longevity of a solution
In my experience, the longevity of any computational tool comes down to three variables:
Ease of Creation
Ease of Use
Ease of Maintenance
Let’s break them down.
Ease of Creation
How fast can you build something ?
Excel is still king in most companies for this very reason. It’s quick, familiar and doesn't require any setup. Most people can open a blank sheet and build something that works within hours.
But the ease of creation usually comes at the cost of structure. And structure matters a lot when it comes to maintenance.
You can build and share an Excel file easily. But what happens when you need to push an update?
How do you make sure people are using the latest version? What if someone tweaks the sheet for their project but still needs to pull in your changes?
Ease of use
Can someone else use what you’ve made without you sitting next to them?
Back to our Excel example. How does someone know which cells are inputs and which are outputs? What each sheet does? What order to do things in?
You can add buttons, forms, and instructions to make this easier but the interface is fixed. No matter how hard you try, Excel will still be Excel. The more complex your solution, the more critical usability becomes. If you don’t guide users or provide feedback, they’ll either avoid it, or worse, misuse it.
I’ve seen companies manage over 100,000 projects using a single Excel file. It included timesheets, invoicing, fee proposals, everything. It was 10GB in size and unmanageable. There was even an F1 team that didn’t do well because they only used Excel to manage all their parts.
Clearer interfaces, better documentation, and guided workflows reduce the time you have to spend walking others through it. It also reduces the friction people have about using your tools.
Ease of Maintenance (aka Deployment)
How easy is it to fix, update, and distribute new versions?
As computational designers, our value often comes from solving complex problems at scale. If your script only works on your machine, you're not adding much value. Like it or not, distributing your tools is part of the job.
But in computational design, we rarely think that far ahead. We zip up folders, share files over email, and hope it all works. If people don’t have the latest version, or worse, don’t even know a new version exists, you’ve already lost.
What kind of solution are you actually building ?
Not everything needs to be a polished product. But it helps to know where your solution falls across these three variables.
One-off solutions
Scripts or spreadsheets that are made to solve a specific problem. Usually, tied to a single project. They might include reusable parts, but the overall solution isn’t scalable.
Reusable Templates
These are more generic versions of one-off solutions, often made after spotting patterns across projects. They still require manual tweaking for each use case, so you need someone who knows how to read and modify the code (especially in tools like Grasshopper or Dynamo).
They’re useful, but can be fragile if deployed poorly.
Proper Tools
This is where solutions start to look like real software. They’re designed with the user and reuse in mind. Built with better interfaces, robust logic, and clearer deployment strategies.
They usually take the form of desktop or web apps and they require more time and planning up front. But they’re stable, scalable, and far easier to support. They also provide value over and over again and for a long time.
Moving from solutions to products
There’s no perfect description for what we build. I’ve used “solutions,” “scripts,” and “tools” in this article but really, it’s anything that solves a problem. It might be used once or a hundred times. By you or someone else.
And that’s where we can learn from software teams. They call them products because they consider the whole picture: onboarding, documentation, versioning, user feedback. Not just the problem. It’s about building with scale in mind. And that’s something we often skip in computational design.
So, before building something you hope others will use, ask yourself:
Who is this for?
Will it be used more than once?
What breaks if someone else runs it?
How do I get it into their hands?
How will they even know it exists?
You won’t always have time to answer every question. Not everything needs to be scalable or perfect. But asking even a few of these will make what you build far more intentional and in turn, far more useful.
Final Thoughts
This is really about building with intention. It's about being clear on what you're delivering. A one-off solution, a reusable script or something more like a software product. Most people don't think about the longevity of their work. They build something, it works a few times, then it breaks and it gets abandoned. But when you stop to ask how it’ll be used, by whom, and how it’ll be maintained, your tools have a chance to deliver the impact we all want, over and over again.
If you enjoyed this article, consider subscribing to receive more directly in your inbox. It helps me know that people are enjoying what I am writing.
You’ll also get a gift from me as a thank you.