The Business Architect's FRAME™

Most entrepreneurs move from idea to building faster than they move from idea to understanding.

That's not laziness.

Building feels like progress. A logo exists. A website exists. A product exists. You can point at it.

An idea is harder to point at. So people rush past it, straight into construction, and ask the important question far too late.

What exactly are we building here?

I've written before about what happens when that question arrives too late — when a product gets mistaken for a business, or when a founder builds forward for months without ever working out what needs to be true first. What I haven't done, until now, is name the discipline I actually use to stop it from happening — in my own work, and in the work I do with founders.

I call it The Business Architect's FRAME.

Not because the acronym is clever. Because five questions kept showing up, in roughly the same order, across almost every founder, product and pivot I've worked with — and naming them made the discipline easier to teach, easier to repeat, and much harder to quietly skip.

Five questions, not five steps

FRAME stands for Find, Reality-Test, Architect, Make, Evolve.

Each letter is a question, not a task to check off:

FIND — Is there a real problem or opportunity here, and does it have meaningful potential?

REALITY-TEST — What is the evidence that this is a good idea?

ARCHITECT — How does the business need to work, as one coherent system?

MAKE — What needs to happen, in what order, to make that architecture exist?

EVOLVE — What is the market saying, and what should change because of it?

FRAME is not a business plan. A business plan describes a business, usually the way you'd like it to look once it's finished. FRAME doesn't describe. It decides — what deserves further investigation, what deserves evidence, what deserves architecture, what deserves to be built, and what the business should become once it meets people who don't work for you.

And it isn't a linear checklist. You don't complete FIND, graduate, and never think about it again. Reality doesn't cooperate that neatly. EVOLVE, the last letter, exists specifically to send you back into any of the other four the moment the market tells you something your plan didn't.

The defining principle is simple. Evidence before commitment. Architecture before execution. Reality before certainty.

FIND — is there something here?

Is there a real problem or opportunity here, and does it have meaningful potential?

That's the only question FIND is trying to answer.

Not "is my idea good." Not "will this make me rich." Just: is there something here worth spending more time on?

FIND starts wherever the entrepreneur actually is. Sometimes that's an observation — something is clearly broken, inconvenient, or badly served. Sometimes it's a skill looking for a problem to attach itself to. Sometimes it's a product that already exists, built by a founder who never quite got around to asking whether anyone needed it. And sometimes there's nothing yet but the ambition, in which case start with how to find a business idea.

Wherever it starts, the job is the same. Separate the problem from the founder's preferred solution. Identify who might actually experience it, which is a very different exercise from filling in a customer avatar; I've written separately about how to define your ideal customer properly. Look for real signals — urgency, existing behavior, money already being spent, workarounds already being cobbled together — rather than plausible-sounding stories.

FIND is discovery, not validation. Its job is to produce a focused opportunity: what might be worth solving, for whom, why it might matter, and which assumptions now need to survive contact with reality.

It does not earn the right to build. That comes later. FIND earns the right to test.

REALITY-TEST — what's the evidence?

What is the evidence that this is a good idea, and what evidence could prove us wrong?

This is where the idea leaves the founder's head and meets people who have no reason to be polite about it.

I call this putting the idea on trial, because that's closer to what actually happens than "research" or "validation." A trial has two sides. Somebody has to argue against the idea, not just for it. You go looking for the customer, the alternative, the willingness to pay, the actual behavior — and you go looking, deliberately, for the evidence that could kill the thing you're excited about.

Most founders skip that second half. They collect confirming evidence and call it research. Somebody said something encouraging in a coffee chat, and the idea quietly graduates to "validated" in their own head.

That's not evidence. That's a compliment.

Real reality-testing asks harder questions. Who actually has this problem, and how much does it cost them? What have they already tried, and why didn't it work? What would they need to see before they'd pay for this? What are the alternatives — real competitors and improvised workarounds — doing instead? Does the size of the opportunity justify the size of the commitment being asked of you?

Evidence doesn't produce certainty. Nothing does, this early. What it produces is a better decision than the one conviction alone would have made for you.

That decision has three honest outcomes.

PROCEED — enough evidence exists to justify the work of architecture.

EVOLVE — the opportunity still has potential, but something important has to change first: the customer, the offer, or the model.

STOP — the evidence doesn't justify further commitment.

Stopping is not failure, and neither is evolving. An idea doesn't earn commitment simply by existing, and I've written elsewhere about why a business idea needs evidence before it deserves greater commitment. Refusing to keep funding a bad idea with more of your time is not the same as giving up on entrepreneurship. It's the same discipline, aimed at a different idea. If you want the longer version of how to actually run this stage, I've written a separate guide on how to know if a business idea is actually viable.

ARCHITECT — how does the business work?

How does the business need to work, as one coherent system?

This is the part of FRAME that does the most work, and the part most often skipped entirely — which is strange, because it's also the part most people think they're already doing when they write a "business plan" or sketch a go-to-market slide.

They're not. A business plan describes pieces. Architecture designs how the pieces work together.

Here's what that means in practice.

Change the customer, and you may have just changed the offer.

Change the offer, and you may have just changed the price.

Change the price, and the economics change with it.

Change the economics, and the acquisition channel you could previously afford is suddenly out of reach.

Change the acquisition channel, and the delivery model built for word-of-mouth customers may not survive paid ones.

None of that is a list. It's a system. Customer, offer, positioning, pricing, journey, delivery, operating model, resources, partners, financial logic, revenue model, cash requirements — Business Architecture is the discipline of designing how all of it holds together, not producing a folder of separate documents about each piece in isolation.

This is also where the smallest credible version of the business gets defined, and the roadmap gets reverse-engineered from it. Not "what could we eventually build," but what has to become true first, and what that means has to happen before it.

It's worth being precise about what this isn't. It isn't consulting, where someone studies your business from the outside and hands you a set of recommendations to implement yourself. It isn't coaching, where someone helps you find your own answers through better questions. Business Architecture is the work of actually designing the system, alongside the entrepreneur rather than instead of them, so that when the pieces meet reality, they're built to hold together — not to each look reasonable on their own.

Architecture doesn't mean months of planning before anything happens. Sometimes the next architectural decision is talk to ten more customers. Sometimes it's build the smallest version that can take a payment. The point of architecture isn't to postpone reality. It's to reach reality with the fewest unnecessary casualties.

The gate here is simple: READY TO BUILD. Not certain. Not risk-free. Coherent enough that moving into execution becomes a deliberate decision, not a hopeful one.

MAKE — what needs to happen to make it exist?

What needs to happen, in what order, to make that architecture exist in reality?

Architecture that never leaves the whiteboard is theory with good production values. MAKE is where it stops being theory.

This is not "build everything the architecture describes." Most of it, at this stage, still doesn't deserve to exist yet. MAKE means sequencing execution around what the architecture says is necessary right now — building only what's required to reach the next real customer, the next transaction, the next piece of evidence — and resisting the urge to build the rest simply because you finally can.

Go-to-market. First customers. The operating capability required to actually deliver what was promised. MAKE moves all of it from decision into consequence. Revenue starts. Delivery starts. And with them, real constraints show up that no amount of planning could have surfaced, because some things only become visible once customers, cash and time are all moving at once.

Capital fits here too, when it fits at all. Not as a milestone every business is assumed to need on the way to legitimacy, but as one resource among several — used when the architecture has already shown why it's required and what it's meant to unlock. Raising money isn't a stage of MAKE. It's occasionally a tool inside it. If you built the product before you built the business around it, I've written a longer answer on how to turn an app into an actual business — most of it lives inside ARCHITECT and MAKE.

The output of MAKE is a business that's no longer theoretical. It's exposed — to customers who owe you nothing, to operating constraints nobody warned you about, to transactions that either happen or don't. That exposure is the point.

EVOLVE — what is the market saying?

What is the market saying, and what should we change, strengthen, scale, simplify or re-architect because of it?

Once something exists, reality starts talking back.

Customers behave differently than they said they would.

Something sells that you almost didn't build.

Something you were proud of sits there, unbought.

Friction shows up in places the architecture never anticipated.

Competitors move.

The economics look different at ten customers than they did on a spreadsheet.

I think of this as the market's echo. You built something, sent it out, and now something is coming back. EVOLVE is the discipline of actually listening to it, instead of defending the original plan out of attachment to having made it.

Listening means watching what customers do, not only what they say. It means comparing the architecture against what's actually happening in the field, and being honest about the gap. Sometimes the honest answer is strengthen what's working, and leave the rest alone. Sometimes it's simplify, because half of what got built is now dead weight. Sometimes it's this needs to scale, carefully, before the constraints it's about to expose become the whole story. And sometimes the honest answer is a pivot, or a return to an earlier question entirely.

That's the part people misunderstand about EVOLVE. It isn't only optimization — the comfortable work of tightening what already works. It's also the less comfortable work: admitting a piece of the architecture was wrong, and doing something about it before the market makes the decision for you.

FRAME is a cycle, not a funnel

The letters are ordered. Businesses are not nearly so cooperative.

Reality can send you backward, sideways, or straight into another FRAME entirely — and none of that means the method failed.

If the problem turns out weaker than expected, you return to FIND or REALITY-TEST.

If the customer was right but the offer wasn't, you return to ARCHITECT.

If the architecture was sound but execution is failing, you return to MAKE.

If traction exposes a constraint nobody saw coming, you EVOLVE the architecture before you scale straight into it.

And if a genuinely new opportunity shows up along the way, you begin another FRAME.

I call this Re-FRAME, and it isn't a failure state. It's what using new evidence to improve a business actually looks like in practice, as opposed to in a pitch deck.

A funnel only moves in one direction, and calls anything else churn. FRAME expects to be revisited — because the business it's describing is alive, and living things don't hold still just because you've finished writing a chapter about them.

Who this is for

FRAME isn't only for the idea-stage founder staring at a blank page, although it works there too — if you're wondering whether you're actually ready to start, I've written about the signs that separate a serious founder from someone who just likes the idea of one.

It works for the aspiring entrepreneur asking whether there's actually a business inside an idea they can't stop thinking about.

It works for the experienced professional who knows exactly what they're capable of, and has no idea yet what business should be built around it.

It works for the founder who already built the product, and is only now discovering that shipping it was the easy part.

It works for the existing small business where the pieces no longer fit together the way they used to.

It works for the pivot — what's actually changed, and what that means has to be re-architected.

And it works for growth, where the harder question isn't can we get bigger, but what has to change in the architecture before we do — so that getting bigger doesn't break the thing that made us worth scaling in the first place.

Different entry points. Same five questions, asked in whatever order reality currently requires.

What FRAME is not

It's not a guaranteed formula. Evidence reduces avoidable guessing. It doesn't eliminate uncertainty, and nobody should promise you it will.

It's not a rigid five-step funnel. It's closer to five lenses you keep picking back up, in whatever order the business currently needs.

It's not a business plan with a better name. A plan describes. Architecture designs how the parts actually work together.

And it's not permission to build first and think later. Execution follows architecture, and stays answerable to whatever evidence shows up next.

An idea is not a business. A product isn't automatically one either, and neither is an MVP, a logo, or a business plan sitting quietly in a folder nobody reads.

A business is what's left once an idea has survived evidence, been designed as a system, made to exist, and adjusted based on what actually happened.

FRAME is the discipline I use to get there.

And the one I keep using once we arrive — because arriving is never quite as permanent as it looks from the outside.