Platform Engineering And Woodworking

Paul StovellAugust 26, 2025 • 5 min read

What is something that woodworkers, blacksmiths, and programmers have in common? One answer is that practitioners of these crafts have the unique ability to make their own tools.

In fact, making your own tools is so essential to these crafts that tool-making is part of their training and tradition. Hammers, tongs, and chisels are among the first items an apprentice blacksmith learns to make. The first projects for an amateur woodworker are often to build a workbench, a circular saw guide, sawhorses, or a cross-cut sled. Tool-making is so essential to these crafts that it’s not uncommon to detour midway through a production project into making a tool to assist with the project, a detour that becomes a natural part of the work process.

Programmers are, perhaps, the ultimate tool-makers. Every programmer has a collection of scripts and utility programs they’ve built to make small tasks more productive. Octopus Deploy started life as a collection of automation scripts I would take from project to project in my consulting days. Tool-making isn’t just a way to gain productivity; it’s also immensely satisfying. It gives us extensive control over our work environment: unlike every other profession, we don’t need to put up with bad tools, because we can always make our own.

When making the tool consumes the project

Tool-making is never free, however. In woodworking or blacksmithing, it consumes raw materials and time. For programmers, we don’t have a raw material constraint (except perhaps coffee, the raw material that programmers turn into working code!), but we do have a time constraint. And the complexity of software and the optimistic nature of programmers mean that we often underestimate how difficult a particular tool can be to make.

For example, a programmer may need to complete a task that takes 5 minutes, like resetting the local test data they use in the application they are working on. And they might perform that task 5 or 6 times a month. So it’s quite common for good programmers to take an hour or so to create a script or a small utility program to automate the task. Even if the ROI calculation means the time they save automating isn’t going to be paid back for a long time, it can still be a smart thing to do if it results in less context switching, better accuracy, or is simply more satisfying.

As organizations scale their Continuous Delivery practices, this craft approach can lead to an unexpected problem: the tool-building starts consuming more resources than the actual work. Teams that began by automating a few deployment scenarios find themselves spending months building elaborate internal platforms to handle every edge case across dozens of applications. A deployment pipeline that started as a simple script to push a web application to production grows into a complex system supporting microservices, legacy mainframes, mobile apps, and that one critical application written in a programming language nobody wants to touch.

The irony is striking. The organization wants to create valuable software for its customers, but engineering teams are spending more and more time maintaining their custom-built tooling instead of creating features. Like a woodworker who spends more time perfecting their jigs than crafting furniture, these teams have lost sight of what they’re really trying to accomplish.

Platform Engineering and developer experience

Platform Engineering is downstream of developer experience, even when it’s not the primary motivation for building an internal developer platform. Removing barriers to let developers improve the flow of value benefits the whole organization. Getting software into production and running that software in production is hard, and it wastes time for each team to reinvent solutions to this from first principles.

The best platform teams never lose sight of that developer experience. They build thin platforms that let the innovation of underlying tools accelerate their pace, so their platform can remain market-leading over the long term and at a lower cost than chasing that innovation with a custom-built platform. We often refer to internal developer platforms as the glue. What if we changed that to think of these platforms as the minimal jig that helps fit the professional-grade saws and drills to the shape the organization needs?

The platform, like the jig, should never become the build. When it does, it gets in the way and slows developers down instead of being their force multiplier.

Platform Hub: Shifting complexity away from Platform Engineers

We built Platform Hub to lighten the load for platform builders. When they need to support Continuous Delivery at scale, Platform Hub tackles the complexity of template management and policy guardrails. The traditional approach is to create a template and clone it across all your applications, then face the nightmare of keeping hundreds of copies in sync as requirements evolve.

Platform Hub solves the cloning problem by keeping a single versioned template connected to all the places you use it. You can roll out non-breaking changes automatically and track the progress of significant updates. You can even require crucial steps like security scanning using policies, so you know all your deployments meet your standards.

By handling this complexity below the platform level, your teams can focus on what matters: shaping the tools to fit your organization’s specific needs while letting professional-grade tooling handle the heavy lifting. Less time building jigs; more time creating value.

Happy deployments!