How Jamii Tech Approaches 0→1 Product Development for Founder-Led Teams

Danny McLane··8 min read

Most 0-to-1 projects fail the same way. The founder has a vision. The agency builds the vision. Six months later there's a product with 40 features, 2 users, and a founder who is out of money and angry.

Jamii Tech has built enough 0-to-1 products for founder-led teams that we have a specific playbook. It's boring. That's the point.

Phase 0: The riskiest assumption

Before we write any code, we figure out the one thing that — if it's wrong — kills the whole product.

Sometimes it's demand ("will anyone pay for this?"). Sometimes it's distribution ("can we reach the people who'd pay?"). Sometimes it's feasibility ("can this actually be built with current infrastructure?"). Almost never is it "can we build a beautiful UI?" — that's rarely the risk.

Every founder wants to start with the UI. We start with the riskiest assumption and design the MVP around testing it.

Phase 1: The smallest thing that could work

The MVP is not your product. The MVP is the smallest thing that can test the riskiest assumption. That's a different question.

For a B2B SaaS: often it's a landing page + a waitlist + five manual customer calls. No code.

For a marketplace: often it's a single-sided onboarding flow that tests supply before building demand.

For a consumer app: often it's a web prototype with three screens and a Stripe link, not a native app with push notifications and a full onboarding.

At Jamii Technology we have said no to more MVPs than we've built. That's the job. The point is to save the founder six months of building the wrong thing.

Phase 2: The boring stack

When we do build, we default to the most boring stack that works:

  • Frontend: React + Vite + Tailwind + shadcn/ui. Not because they're trendy but because they're unopinionated and the ecosystem is mature.
  • Backend: Supabase for auth + Postgres + row-level security + edge functions. One service, one SQL database, one auth provider. No microservices for an MVP.
  • Hosting: Vercel. Auto-deploy from git. You will not outgrow it.
  • Payments: Stripe. Obviously.
  • Analytics: PostHog or Plausible. Do not use Google Analytics for a product — it is designed for marketing, not for understanding your users.

Founders sometimes push back on this. "Why not Next.js App Router? Why not a microservice per domain? Why not our own auth?"

Because it's an MVP. You want to be wrong fast, not beautiful slow.

Phase 3: Ship weekly, not monthly

We ship the first deployable version within two weeks. It is ugly. That is the point.

From there, we ship every week. Not "iterate in sprints" — actually push to production every Thursday. Founders use the product. Real users use the product. Decisions get made based on real signal, not Figma review.

The best predictor of 0-to-1 success is how fast a team can learn from real users. Shipping weekly is the forcing function.

Phase 4: The feature you don't build

Halfway through most 0-to-1 engagements, the founder has a new feature idea. It's a good idea. We don't build it.

Instead, we ask: does building this delay testing the riskiest assumption? If yes, we park it. If no, we build it.

That discipline — not building the shiny new thing — is what separates shipped products from "in development" products.

What this looks like in practice

Typical Jamii Tech 0-to-1 engagement:

  • Week 0: Riskiest-assumption workshop. One afternoon, in person if you're in the Bay Area.
  • Weeks 1-2: Scope cut. Figma wireframes. The MVP fits on one page of paper.
  • Weeks 3-4: First deployable version. Not pretty. Works.
  • Weeks 5-12: Ship weekly. Real users. Learn.
  • Week 12: Honest retrospective. Does the signal say keep going, pivot, or kill?

Most engagements are 8 to 12 weeks. A few go longer. A few get killed at week 6, and that's a success.

The hard part is saying no

The technology side of 0-to-1 is not the hard part. Any competent studio can ship a React + Supabase MVP. The hard part is scope discipline — knowing what NOT to build, and having the founder relationship to push back without losing the project.

That is what founder-led Jamii Technology is built for. I've killed my own feature ideas. I will kill yours too, if it helps you ship.

If you're starting something, talk to us.

— Danny McLane, Founder, Jamii Technology

Danny McLane
Founder of Jamii Technology. Read more →

Related reading

Work with Jamii Technology

Bay Area product, web, and media from a founder-led studio in San Jose.

Start a project