MRJ.
← Back to Writing
From MVP to PVP

From MVP to PVP

By Marvin R. Johnson Published: 10-08-2026

From MVP to PVP: Building Software for One

For most of my career in technology, building software required answering a fundamental question:

Is the market big enough?

We talked about TAM, SAM and SOM. We did user research, competitive analysis and financial models. We needed to understand how many potential customers existed because software was expensive to build.

If you were going to invest hundreds of thousands or millions of dollars in a product, you needed a market large enough to justify the investment.

But the economics of software are changing.

AI-assisted development and tools associated with vibe coding are dramatically reducing the time, money and expertise required to turn an idea into a working application.

And I think that creates a new category of product development.

I'm calling it the Personally Viable Product, or PVP.

What is a PVP?

We've all heard of the MVP, or Minimum Viable Product.

The basic idea is to build the smallest version of a product necessary to test whether customers want it.

A PVP starts somewhere else.

What if the initial market is just one person?

You.

A Personally Viable Product is a piece of software that is inexpensive and fast enough to build that you can justify creating it simply because you have a problem you want to solve.

Think about the way we have used Excel for years.

You might spend an afternoon building a spreadsheet to forecast revenue, analyze an investment or automate a repetitive task.

You don't need a business plan.

You don't need a TAM.

You don't need a product roadmap.

You build it because the problem is worth solving for you.

AI is bringing that same dynamic to software.

The difference is that the thing you build doesn't have to be a spreadsheet anymore. It can be a real application.

My Own PVP

I recently experienced this with a product I'm calling QR Code Art.

I wanted artistic QR codes that I could customize, track and manage.

Under the traditional software development model, I might have started with market research.

How big is the market?

Who are the competitors?

What is the TAM?

What is the SOM?

Is this opportunity large enough to justify building?

Instead, I asked a much simpler question:

Can I build this for myself?

Using AI-assisted development and vibe coding, I built it.

It became a functioning application that I can use to create, manage and track artistic QR codes.

And I now use it for several of my projects.

That's the PVP concept.

I didn't need to prove there was a market before I built the product.

I was the market.

Maybe there is a large market for artistic, trackable QR codes.

Maybe there isn't.

I can figure that out later.

The important thing is that the cost of finding out became low enough that I didn't need to know before I started.

Your SOM Can Be One

This is where I think the PVP concept gets interesting for product management.

For decades, we have generally started with the market and worked backward.

Market → Research → Business Case → Product → Customers

But AI makes another sequence possible:

Problem → Build → Use → Learn → Market

That doesn't make TAM, SAM and SOM irrelevant.

If you're building a venture-backed company, market size still matters.

But not every piece of software needs to start as a venture-backed company.

Some software can start as a solution to a problem experienced by one person.

And that person can be the builder.

The economics make this possible.

If something takes six months and a team of developers to build, you probably aren't going to build it just for yourself.

If it takes a weekend, the calculation is completely different.

The size of the market required to justify building something is directly connected to the cost of building it.

As that cost approaches zero, the minimum viable market gets smaller too.

Potentially, all the way down to one.

From PVP to MVP

Here's the part I find most interesting.

A PVP doesn't necessarily stay a PVP.

You build something for yourself.

You use it.

You discover that other people have the same problem.

Maybe there are ten of them.

Maybe 100.

Maybe 10,000.

Now you have something worth investigating as a traditional product.

Your PVP can become an MVP.

And perhaps eventually it becomes a company.

But you've changed the order of operations.

You didn't start by proving the market existed.

You started by solving a problem.

That's a very different way to discover products.

A New Layer of Software

I don't think this replaces traditional product development.

There will always be products that require significant investment, extensive research and large markets.

But I think we're going to see another layer of software emerge underneath them.

Small applications.

Highly specialized tools.

Personal workflows.

Industry-specific utilities.

Products built by people who aren't traditional software developers.

Software that would never have passed a traditional business case because the market was too small.

But now it doesn't have to.

The cost of building the software has become small enough to justify building it for yourself.

That's the real idea behind the Personally Viable Product.

We used to ask:

"How big is the market?"

Increasingly, we may start by asking:

"How cheap and fast can I solve the problem?"

And if the answer is cheap and fast enough, maybe a market of one is all the justification you need to start.


More Articles