The Golden Age of Building It Yourself
Originally Published March 10, 2026 on LinkedIn.
We are living in a golden age of building.
Not just in the traditional startup sense of raising capital and assembling engineering teams. That world has changed as well. Build cycles have compressed dramatically, validation is easier than ever, and prototypes that once took months can now be assembled in hours or days.
In that environment, features are no longer the moat. Shipping is. Proprietary data is. The insights and institutional knowledge accumulated over time are what endure.
Ideas decay incredibly fast now. If you do not build something, someone else will. If not today, then tomorrow. The half-life of an idea has never been shorter.
But that urgency also creates enormous opportunity.
And, frankly, it is also incredibly fun.
The collapse of the build–validate loop
Deep down, I have always been a product person. One of the things I used to enjoy most was writing product requirement documents and specs, turning an idea into something structured, thinking through edge cases, and defining workflows.
Wireframing was always particularly satisfying because it was the first moment you could actually see the product.
But it was still abstract. The real validation only came weeks or months later, once something was built.
Today, that gap has largely disappeared.
Instead of writing a specification and handing it off to engineering, I can often build the first version of a feature myself. In many cases it takes a few hours. And because the prototype is real, it can immediately be shown to customers or tested against live opportunities the same day.
There is something almost childlike about that moment when the thing you imagined suddenly works.
You tweak a prompt.
You connect a few systems.
You adjust a workflow.
And suddenly something real exists.
The distance between idea and validation has essentially collapsed.
You no longer need to describe the idea. You can simply build it and see what happens.
Building for yourself vs building for the institution
An important distinction shows up very quickly.
Many of these systems begin as personal tools.
A solo GP builds a deal tracker tailored exactly to how they source and evaluate investments. A market data manager assembles a contract-monitoring workflow to track vendor obligations. An operations lead builds a reporting system that finally produces the numbers the way they want them.
For that individual, the system works perfectly. It reflects how they think and how they operate.
This is where these tools are particularly powerful. They allow operators to shape software around how the work actually gets done, rather than forcing workflows into rigid systems designed years earlier.
But there is a hidden fragility.
What these systems actually contain is institutional knowledge embedded inside a personal tool.
The builder understands the assumptions.
The builder understands the edge cases.
The builder understands why things work the way they do.
But the system rarely explains itself.
Institutions cannot rely on personal systems.
The moment the builder leaves, the tool often becomes confusing or brittle. The logic is unclear, the workflows are undocumented, and the knowledge that made the system valuable disappears with the person who created it.
What looked like a system was actually a person plus a tool.
That is one reason many internal tools quietly disappear over time. They work brilliantly while the creator is around, but they never quite become part of the institution’s operating fabric.
Research from MIT has pointed to a similar pattern. Generative AI tools can dramatically increase individual productivity, but many organizations struggle to translate those gains into institutional performance.
AI amplifies individuals.
Institutions require durable systems.
The transition that actually matters
This is where the real product challenge begins.
A tool that works perfectly for one person must suddenly support an entire organization. That means shared workflows, consistent data structures, permissions, accountability, and durability that personal tools rarely require.
It also means something deeper.
The knowledge embedded in the system needs to be made explicit and understandable to others.
The personal workflow has to turn into institutional infrastructure.
That transition is where many real software products are born.
And it is also where some of the strongest product insights emerge. When a tool survives that transition, it usually means it captured something fundamental about how the work actually happens.
A new product development loop
The product development cycle has shifted.
For a long time, it followed a familiar pattern: an idea was specified, handed to engineering, built over several cycles, released, and only then tested in the real world.
Even with strong product practices, validation still took time.
I remember spending weeks building elaborate PowerPoint mockups and prototype flows to show customers and prospects. Those conversations were valuable, but translating them into a real product still required multiple steps and handoffs.
Today, the discovery phase happens earlier and in a very different way.
The operator, founder, or product thinker builds the first version themselves, uses it in practice, and refines the workflow before it ever becomes a formal product.
The first version is no longer hypothetical.
It already exists.
The distance between idea, experimentation, and validation has collapsed.
That is one reason new categories of software are appearing faster than at any point in the past. Many of them begin as internal systems built by someone who simply wanted a better way to work.
The opportunity, and the risk
As much excitement as I feel about these tools, there is also something that worries me.
We are creating a very different kind of digital divide.
There has never been less friction to build something. If you have ambition, curiosity, and creativity, you can now turn ideas into reality in ways that were previously impossible.
An idea for a children’s book can become a finished product.
A game can be prototyped in days.
A website or SaaS tool can emerge from an idea and become something real.
The tools are there.
Which means, in many ways, there are no more excuses.
And yet, many people are still sitting this moment out.
Some dismiss these tools entirely. Others assume they are only for engineers or technologists. Many keep waiting, assuming they will figure it out later.
That instinct is understandable.
But this moment will not wait.
The people who embrace these tools are not just working faster. They are building entirely new capabilities. They are learning how to turn ideas into systems and collaborate with technology rather than resist it.
And once that skill starts compounding, the gap can widen quickly.
That is the part that should give us pause.
The opportunity ahead
The golden age of building is already here.
But the real opportunity is not simply building tools for yourself. That part is becoming easier every day.
The real opportunity lies in recognizing when a personal system captures something valuable and turning it into something durable for the institution.
That transition from individual workflows to institutional infrastructure is where many of the next great software companies will emerge.
In a world where anyone can build, the advantage increasingly belongs to those who are willing to start.
Continue reading
This is a condensed version of the original piece.
For the full article, including additional examples and context:
👉 https://www.linkedin.com/pulse/golden-age-building-yourself-hendrik-bartel-vxcfc/?trackingId=pqMwE5kT0hENULJk1HQ1tQ%3D%3D
