From PoC to product: the tree ring method

For many businesses, building software feels like a leap of faith. You have an idea, a budget, and somewhere the hope that it'll all work out. Months later you receive something. Sometimes exactly what you wanted. Often not quite.

At Tech_42, we work differently. And since AI has become part of our process, that "differently" has become even more radical.

The tree ring method

When you cut through a tree, you see rings. Each ring tells a story: a year of growth, layer by layer, from the inside out. The core is narrow, but sturdy. Each subsequent ring builds on what's already there.

That's how we build software.

We start small — not with a sixty-slide PowerPoint, but with something that works. A first ring. From there we build layer by layer: bigger, richer, more robust. But at every moment you have a working product. Not a promise, not a mockup — something that runs.

We summarize this philosophy in four words: think big, start lean.

Ring 1: the Proof of Concept

Everything starts with a question. Not "what do you want to build?" but "what do you want to prove?"

A Proof of Concept isn't a product. It's an experiment. Is this technically feasible? Is there demand? Does our assumption hold? We build just enough to answer that question — and not a single line more.

This used to take days, even for just that. You had to set up an environment, figure out APIs, piece together a frontend. Now, with AI as part of the team, we build a PoC in hours. Sometimes in an afternoon.

I open Claude Code, describe the problem, and together we build a working version. Not pixel-perfect, not production-ready — but enough to show: this works, and this is how it feels.

That speed changes everything. Because a PoC that costs an afternoon, you dare to build. A PoC that costs two weeks, you postpone. Or worse: you skip it entirely and jump straight into "the real work." And that's where projects go off the rails.

Ring 2: the prototype

The PoC has proven the idea works. Now we build a prototype — the next ring.

A prototype is more than an experiment. It has an interface, a flow, an experience. It's something you can show people and get feedback on. Not "imagine it works like this," but: here, try it.

This is where AI truly shines. I now build complete dashboards, interactive flows, working forms in a single evening. Things that used to require a two-week sprint. Not because it's simple, but because the searching, writing, and configuration work is largely automated.

And the beautiful thing is: a prototype doesn't need to survive. It's a disposable product with a purpose — gathering feedback. Clients see it, react, and say: "This, but different" or "Yes, exactly this." Both are worth gold.

We take that feedback into the next ring.

Ring 3: the MVP

The Minimum Viable Product. The smallest version of your product that delivers real value. Not everything, but enough. Enough to launch, serve users, and learn from actual usage.

This is where it gets serious. We throw away the prototype. Yes, really. We start over, but now with all the knowledge from the previous rings. We know what works, what users want, which assumptions were right and which weren't.

This is deliberate. Building a prototype with speed and building an MVP with structure are two different disciplines. With the prototype, you can take shortcuts. With the MVP, you can't. This is where we lay the foundation the tree will continue to grow on.

With AI on board, this foundation is laid faster than ever. Not because we rush, but because the repetitive work — boilerplate, standard CRUD, configuration, tests — is largely written by AI. I focus on architecture, data models, and the decisions that determine whether the system will still stand in two years.

Ring 4, 5, 6... the product grows

After the MVP, every subsequent ring is an iteration. New features, improved flows, scalability, integrations. Each ring makes the product richer, but it keeps running throughout. There's never a moment where "everything stops until version 2.0 is ready."

This is the core of how Tech_42 works: continuously delivering value. Strategize, Build, Launch, Evolve — and then again. Each cycle is a ring. Each ring is a working product.

Why this works

The tree ring method works because it does three things that traditional approaches don't:

1. Reduce risk You never invest months in something you only learn is wrong afterward. After each ring you evaluate: do we continue, adjust, or stop? That's not failure — that's smart business.

2. Speed without chaos Building fast doesn't mean building sloppy. Each ring has a different goal and different quality requirements. A PoC can be messy. An MVP can't. By consciously separating those layers, you combine speed with quality.

3. Feedback as fuel Every ring produces something tangible. Something you can show, test, and discuss. The sooner you get feedback, the less you throw away. And the better the end result.

The role of AI in all of this

I sometimes get asked: "Does AI replace the developer?"

No. AI replaces the part of development that's boring, repetitive, and error-prone. It doesn't replace the thinking, the designing, the architectural decision-making.

What AI does do is accelerate the rings. Where a PoC used to take days, it now takes hours. Where a prototype took weeks, it now takes days. That means we can build more rings, gather feedback faster, and know sooner whether we're on the right track.

And that's exactly what our clients need. Not a vendor that delivers something after four months. A partner that builds alongside them, ring by ring, showing what's already standing at every step.

Start small, end big

A tree starts as a seed. But give it light, water, and time, and it grows into something that lasts for generations.

That's how we look at software. Start small. Prove your assumptions. Build layer by layer. And end up with something that stands firm — not because you got it right the first time, but because you made it a little better with every ring.

Think big. Start lean. Scale fast.

Ring by ring.

— Chris