Episode Summary

Every great product—or operational improvement—starts with an idea. But the first version of that idea is almost always wrong. In this episode, Justin Davis and Greg Ross-Munro explain why prototyping is the fastest and safest way to test ideas before committing serious resources to building them.

They explore what a prototype actually is, how it differs from a technical proof-of-concept, and why the goal is always to learn as much as possible with the least amount of effort. From spreadsheets and Google Forms to automation tools and AI-assisted builders, Justin and Greg share practical ways service companies can prototype solutions quickly. They also discuss a common trap founders fall into: becoming emotionally attached to early versions of their products. The key lesson is simple—build just enough to answer the question you’re trying to test.

Episode notes

• Why prototyping is essential when building products or improving business processes
• The reality that your first idea is almost always wrong
• How prototypes help reduce risk and prevent expensive mistakes
• The “steering a car” analogy for correcting product direction early
• The goal of a prototype: maximum learning with minimum effort
• Why businesses should only build the lowest fidelity version necessary
• Practical prototyping tools:
  • Spreadsheets
  • Google Forms
  • Email workflows
  • Automation tools like Make.com and n8n
  • AI-assisted tools like Replit, Lovable, and Bolt
• The difference between prototypes vs. proof of concept
  • Proof of concept: “Can we technically do this?”
  • Prototype: “Is this the right solution?”
• How spreadsheets inside companies often contain hidden intellectual property
• Why founders often become emotionally attached to prototypes (the IKEA Effect)
• The danger of sunk-cost bias in product development
• Why early products should be treated as disposable learning tools
• The idea that prototypes may eventually become simply the first phase of a product’s lifecycle
  

Episode Transcript

Justin Davis: Hey there, welcome in to Leap to Scale. I’m Justin Davis, and this is the podcast that’s out there to help service companies figure out how to get past the headcount ceiling, how to grow using technology, and scale beyond trading hours for dollars. That’s about productizing your business and improving efficiency through technology. We break it down on every episode and talk about it.

Greg Ross-Munro: I’m Greg Ross-Munro.

Justin: One of the parts of the process you have to go through when you’re trying to improve internal efficiencies, scale past headcount, or productize part of your business is finding ideas about how to do that.

We’ll do another episode about how to find those ideas and how to think about that in the context of your business. But once you have an idea, you have to figure out if it actually works or not.

That’s where prototypes come in.

A prototype is a way to help you discover whether the thing you’re building actually solves the problem you think it does. It’s a tool you can use to test your idea before committing significant time or money.

Today we’re going to break down what prototypes are, why you use them, when you use them, how to build them, and why they’re important to this entire process.

Greg: Justin, I have a question. I think everyone knows what a prototype is in general. You see things like a prototype Bugatti Chiron or a prototype of a new car. My son is obsessed with Bugatti Chirons at the moment.

So it’s like the first version of something you build. Sometimes those prototypes are made of clay or other materials. But how is a software prototype different from the kinds of prototypes we see in the physical world?

Justin: That’s a good question. Let’s back up to fundamentals for a second.

When you have an idea for something—whether it’s improving your business efficiency with technology or productizing part of your expertise—you don’t actually have 100 percent certainty that the idea will work.

Being creative is hard because the things you imagine in your head rarely translate perfectly into the real world.

That translation process is where prototypes become useful.

Greg: I’d like to quote one of my favorite thinkers on this subject, Mr. Justin Davis. You once gave a whole talk about how your idea is almost certainly wrong.

Your first idea is almost always wrong. The important thing is figuring out how it’s wrong as quickly as possible.

Justin: That’s exactly right. Almost certainly wrong.

And that’s where software prototyping becomes powerful. With modern technology, code, AI tools, low‑code systems, and workflow tools, you can test ideas quickly and cheaply.

When you have an idea, what you’re really doing is placing a bet. You’re betting time and resources on whether your idea will solve the problem you think it will.

But since there’s always uncertainty, prototyping allows you to test that idea with very small investments.

It’s the fastest and cheapest way to check whether you’re on the right track.

Think about it like steering a car. If you drift slightly off course and correct quickly, you’re fine. But if you keep driving without checking, you can end up miles off the road.

Prototyping is how you keep correcting your direction early.

Greg: That analogy works especially well since we started with cars.

There’s also a cost aspect to prototypes. Everything requires investment.

The perfect prototype sits at the intersection of the least amount of work and the least amount of cost necessary to validate the idea.

If you can spend the smallest amount of time and money and still determine whether your idea works, that’s the ideal prototype.

Justin: Exactly. It’s basic return on investment thinking.

Your goal is to build the smallest possible thing that gives you the answer you need.

People sometimes build massive solutions when they could have built something much simpler and learned the same lesson.

Greg: We’ve seen this happen before. I once saw a large company spend over a million dollars designing a product before showing it to a single stakeholder or customer.

When the executive team finally saw it, they were furious. All that investment happened without validating whether the idea was correct.

That’s about the worst case scenario.

Justin: Right. The lesson there is to only build what you need.

Be lazy in a good way.

When we talk about fidelity in prototypes, we’re talking about how detailed or complex the thing needs to be.

You don’t always need a full web application. Sometimes a spreadsheet is enough.

In fact, I like to say that almost all software is built to replace a spreadsheet somewhere.

Spreadsheets are incredibly powerful prototyping tools.

Greg: Especially if you put a Google Form in front of them.

Justin: Exactly.

A spreadsheet and a simple form might be enough to test an idea with real users. You might be able to run an early product or service that way for dozens of customers before it becomes unmanageable.

You can also assemble prototypes from existing tools instead of building them from scratch.

When you outgrow spreadsheets, you can move into workflow automation tools like Make.com or n8n. You can connect systems together, trigger emails, process forms, or integrate with accounting tools.

And now you can even embed AI into those workflows.

The key is to start with the smallest possible thing.

Another important principle is to match the fidelity of your prototype to the certainty you have about your idea.

If your idea is still vague, your prototype should be simple—maybe just a sketch. As your understanding improves, you can increase the complexity.

Greg: That brings up an interesting distinction.

There’s a difference between a prototype and a proof of concept.

A proof of concept asks a technical question: “Can this be done?”

A prototype asks a different question: “Should we build this?”

Justin: Exactly. A proof of concept is about feasibility. A prototype is about usability and value.

Both are trying to answer questions. That’s the key idea.

You’re not building the final product. You’re answering questions about whether the idea works.

So you should only build enough to answer that question.

Sometimes I even build proof‑of‑concept code in the command line with simple data streams. It strips away all the visual decoration and focuses only on the logic.

Greg: Another thing people might not realize is that they may already have prototypes inside their businesses.

If you run a service company, you probably have spreadsheets that calculate something important. Maybe they determine pricing, estimate costs, or automate part of a workflow.

Those spreadsheets are prototypes.

Justin: That’s a fantastic point.

Those spreadsheets are often intellectual property. They represent the unique way your business solves problems.

If you find a spreadsheet that your company relies on heavily, that might be the seed of a product.

You might even be able to sell the spreadsheet itself as an early version of a product to test demand.

Greg: These days we’re also seeing people prototype with AI‑assisted tools and low‑code builders.

Tools like Lovable, Replit, and Bolt allow people to create functional applications quickly.

But there’s a downside. People become emotionally attached to what they build.

When it’s time to rebuild the prototype properly, they struggle to let go.

Justin: That’s a real psychological phenomenon. It’s called the IKEA Effect.

When you build something yourself, you assign it more value simply because you created it.

In entrepreneurship, that can become dangerous.

You start believing your idea is great simply because you’ve invested time into it.

There’s also the sunk‑cost fallacy, where the more time you invest, the harder it becomes to walk away.

But prototypes are disposable. They exist to teach you something.

If you learn the lesson, they’ve done their job.

Greg: So the takeaway is simple: prototype first.

Whether it’s on paper, in PowerPoint, with a spreadsheet, or with automation tools—build the simplest version possible.

Validate the idea before investing heavily.

And don’t become emotionally attached to the prototype.

Eventually you may need to rebuild it properly as a real product.

Justin: I’ve actually been thinking about something related to that.

In the future, we may stop thinking about prototypes as separate things entirely.

Instead, they may just be the earliest phase of the product itself.

The prototype might simply evolve into the real product over time.

Greg: I actually agree with that. Maybe in the next episode we should talk about how to design prototypes that can grow into real products.

But for now, most people should be comfortable throwing prototypes away.

Justin: That sounds like a great topic for part two.

Greg: Perfect. I think I’ve got some arguments ready for that discussion.

Justin: I’m looking forward to it.

Thanks for listening everyone, and we’ll see you in the next episode of Leap to Scale.

Greg: See you next time.