The Owned-Asset MVP: how to build (and validate) your first product yourself

Start here, because it decides everything after it. In Zero to One, Peter Thiel argues that valuable companies are built on something proprietary — a secret, an edge, an asset that is genuinely yours. In Built to Sell, John Warrillow makes the practical version of the same point: a business is only worth something when it's an asset you own and can hand over — not a dependency you rent and can't extract.

Software you own and understand is an asset. Software you rent is a liability wearing an asset's clothes.

That's the whole thesis of the Owned-Asset MVP: use AI to build fast, but build a real, custom-code product on a standard stack you control — so you understand it, can change it, and actually own it. Here's the honest spectrum, because it's not as simple as “no-code bad, code good.”

The dividing line isn't code vs. no-code — Lovable, Bolt, and v0 all export real code. It's understanding (code you can't read or fix is a liability, and it fails an acquirer's due diligence), the hard 20% (real security and data isolation, which all of them thin out on), and lock-in. We go tool-by-tool in the companion piece: AI app builder vs. custom code.

The single most expensive mistake founders make is building too much before proving anyone wants any of it. The discipline that fixes it is the discipline that makes an MVP an MVP: decide what not to build.

Find the one loop

Every product has one core loop — the smallest sequence of actions that delivers its core value. For a marketplace: one side posts, the other finds it, they transact. For a SaaS tool: the user brings something in, the product does the one useful thing, they get a result worth coming back for. Write yours in a single sentence. If you can't, you haven't scoped it yet.

Name your high-expectation customer

Before you build, borrow a move from Superhuman's product-market-fit work (more on the full engine in Chapter 8): write a one-paragraph portrait of your high-expectation customer — the specific, demanding person who will get the most from your core loop. Their role, their day, the exact pain your loop removes. You are not building for “everyone.” You are building for them. Every later decision gets easier when you have a real person to build for.

This is Entrepreneur First's edge-first thinking in practice: start from a sharp, specific insight about a specific person, not a broad market you hope exists.

Six tools. Each is free to start, and each is the standard professionals actually use — which is the point: you're learning the real thing, not a toy.

• Claude — your AI pair-programmer. It writes code, explains it in plain English, and fixes errors with you. You direct; it types.
• Next.js (with TypeScript) — the framework your app is built in. It handles pages, routing, and speed. It's what a huge share of modern web apps run on.
• Shadcn — a library of clean, accessible UI components (buttons, forms, dialogs) you copy into your project and own. Your app looks professional from day one.
• Supabase — your backend: a Postgres database, user logins (auth), file storage, and row-level security (the feature that keeps each user's data private). It's an open-source platform, so you're never locked in.
• Vercel — hosting. It puts your app on the internet and redeploys it automatically every time you save changes.
• GitHub — version control: a saved history of every change, so you can always go back. It's also where your code actually lives — the asset you own.

You'll create three accounts and connect them once. After this, every change you make goes live automatically. Do it in this order.

1. Install the essentials. Install Node.js (the runtime), a code editor (Cursor or VS Code, both with Claude built in), and create free accounts at GitHub, Supabase, and Vercel.
2. Create the app. In your editor's terminal, scaffold a Next.js app and add Shadcn:

npx create-next-app@latest my-app --typescript --tailwind --app
cd my-app
npx shadcn@latest init

Don't worry about what every flag means — this is the standard modern setup. Run npm run dev and open http://localhost:3000: your app is running on your machine.

3. Push it to GitHub. Create a repository, then connect your project to it. This is the moment your code becomes an owned, versioned asset:

git init
git add -A
git commit -m "First version"
git branch -M main
git remote add origin https://github.com/you/my-app.git
git push -u origin main

4. Deploy to Vercel. In Vercel, click Add New → Project, import your GitHub repo, and deploy. You now have a live URL. From now on, every git push redeploys automatically.
5. Create your Supabase project. In Supabase, create a new project, then copy its URL and keys into a .env.local file in your app (Supabase shows you exactly which values). Your app now has a real database.

Now build the one loop from Chapter 2. The skill isn't coding — it's directing: describing what you want precisely, reviewing what Claude produces, and testing it. Give Claude context, not just a request.

How to prompt for real features

A good prompt states the goal, the stack, the exact behaviour, and asks for small steps. Here's the shape:

I'm building a Next.js 15 app (App Router, TypeScript, Tailwind,
Shadcn) with a Supabase backend. I'm not a developer, so explain
each step in plain English and keep changes small.

Goal: let a signed-in user create a "project" with a title and
a note, and see a list of their own projects.

Please: (1) give me the SQL to create the table in Supabase,
(2) build a form using Shadcn components, (3) show the list.
Tell me exactly which files to change and what to paste.

Work in small loops: ask for one step, paste the code where Claude says, run npm run dev, and see if it works. If you hit an error, paste the entire error back to Claude and ask it to explain and fix. You'll be surprised how far this gets you.

Two things turn a demo into a real product: users can log in, and each user only sees their own data. Supabase handles both — but the second one, row-level security (RLS), is where most DIY apps quietly go wrong. Get it right and you're genuinely ahead of most builder-generated apps.

Authentication

Supabase Auth gives you email/password and social logins out of the box. Ask Claude to add Supabase Auth to your app with a sign-in page — it's a well-trodden path and the code is standard.

Row-level security — the part that actually matters

RLS is a rule enforced by the database itself: “a user can only read or change rows that belong to them.” Because it's enforced at the database — not just hidden in the interface — it holds even if something else is misconfigured. Here's a real policy for the projects table from Chapter 5:

-- Turn on row-level security for the table
alter table projects enable row level security;

-- Users can only see their own rows
create policy "Users read own projects"
  on projects for select
  using ( auth.uid() = user_id );

-- Users can only create rows owned by themselves
create policy "Users insert own projects"
  on projects for insert
  with check ( auth.uid() = user_id );

The whole point of an MVP is to change it fast based on what real people do. But changing a live app is scary — until you set up a safe loop. Two features make it painless.

• Vercel preview deploys. Instead of editing main directly, work on a branch. Every branch gets its own private preview URL you can test (and share) before it goes live.
• Supabase branches. These give you a separate copy of your database for testing changes to your data structure — so you can experiment without touching real user data.

The safe loop, start to finish:

git checkout -b add-search        # start a branch
# ...make changes with Claude, test locally...
git add -A && git commit -m "add search"
git push -u origin add-search     # Vercel builds a preview URL

Open a pull request on GitHub, check the preview, and when it's right, merge to main — which deploys to production. You ship weekly, confidently, and can always roll back. This is exactly how professional teams work; you're just doing it solo.

Here's the chapter every “build an app” guide skips — and it's the one that decides whether you have a business. Building the app was the means. Finding out whether anyone needs it is the end. Don't guess. Measure.

The test: ask users “How would you feel if you could no longer use this?” If 40%+ say “very disappointed,” you have the leading edge of product-market fit.

This is Sean Ellis's benchmark, made famous by Rahul Vohra at Superhuman, who used it to turn a fuzzy feeling into a number they improved quarter over quarter. You can run it with as few as ~40 responses from active users. The full method — the four questions, how to segment believers, and how to build a roadmap from the answers — is in the companion guide: the product-market fit survey (with a free template).

The short version of what to do with the results:

1. Segment. Look only at the “very disappointed” users — that's your true audience. Who are they? That's your high-expectation customer from Chapter 2, confirmed by data.
2. Learn. From the “somewhat disappointed” group who value your core benefit, find the one thing blocking them.
3. Build 50/50. Split your roadmap between deepening what your believers love and removing that blocker. Ignore the “not disappointed” crowd — building for them dilutes the product.

Re-survey new users each quarter and watch the number climb. That number, not your feature count, is your real progress.

You can genuinely get a real, validated MVP live with everything above. But honesty matters, so here's the truth: the last 20% is where software gets hard, and it's the 20% you can't easily see is broken. This is exactly where AI builders and DIY apps quietly fail.

• Security done properly — RLS on every table, no leaked keys, safe handling of anything sensitive. A single missed policy is a breach.
• Payments — Stripe is easy to start and full of edge cases (failed charges, refunds, webhooks that must never double-bill) that have to be exactly right because it's money.
• Multi-tenant isolation, scale, and reliability — as real usage arrives, the shortcuts that were fine for ten users break for ten thousand.
• Compliance — the moment you hold real personal data (and especially health or financial data), you inherit real legal responsibilities.

Knowing where DIY ends is a skill, not a failure.

Plenty of founders build the validated first version themselves, then bring in a professional to harden it for real users — often the most efficient path there is. That's literally what Godelian does: takes a scoped, proven idea and ships an owned, production-grade version, typically for $15–30k in weeks. If you get here, that's a good conversation to have. Either way, you'll know exactly what you're asking for — which makes you a far better client.

Come back to where we started. In Built to Sell, the whole argument is that a valuable company is a teachable, repeatable, owned asset — one that can run, and be handed over, without its founder holding it together by hand.

Look at what you've built by following this method:

• You own the code — it's in your GitHub, on a standard stack any developer can pick up.
• You have evidence — a product-market-fit score and real users, not a hunch.
• You understand it — you can explain how it works, which is exactly what survives an acquirer's due diligence.

A no-code rental fails that test: at diligence, “we don't own the code and can't extract it” tanks a valuation or kills the deal. An owned, understood, validated codebase is the thing a buyer can actually acquire. I've been on the selling side of that table — a startup I built was acquired in 2025 — and the difference between an asset and a dependency is the difference between a deal and a polite no.

Start from your edge. Scope it to the bone. Build it with AI on a stack you own. Prove someone wants it. And never mistake a rented product for an asset you own.

That's the Owned-Asset MVP. Now go build yours — and when you hit the hard 20%, you know where we are.