A Note from the Editor
Hi there,
Last time (Issue 4) , we talked about who's going to run the website AI built for you. Today, we're going one step earlier: who is it for, and why would they stay?
More and more of my conversations with founders now start the same way: I built the MVP with AI. I just need you to make it production ready (for more about the abuse of “just”, check issue 3).
It's a fair ask, and that weekend build is genuinely impressive. Back in March 2025, YC said a quarter of its Winter batch had codebases that were 95% written by AI, and those were technical founders who could have written every line themselves.
But a working prototype proves one thing: that it can be built. It doesn't tell you whether anyone needs it, how they'll find it, or why they'll stay when someone copies it next weekend.
So before you say "we'll just build it and see" (yes, "just" is still around), let's look at what AI can't build for you.
One thing up front: this isn't an anti-AI issue either. We use AI every day, and last issue's Nest was about the tool Muhammad built with it. That's exactly why I'm writing this.
The question isn't whether you can build it. It's what you'll know tomorrow, who you'll reach next quarter and why they'll still pick you next year.
Let's go.
What to expect
Three things AI can't build for you: a question worth answering, a way to reach people, and a reason to stay.
Before you build: Three questions to answer, whoever ends up building it.
Behind the Scenes: What the Storkers were up to this week.
The prototype is the cheapest part
AI has changed what it costs to build a first version. It hasn't changed what it costs to find out whether anyone needs it.
Let's be fair about the scorecard. On speed to a working prototype, the solo AI build wins: a weekend instead of weeks. I won't pretend otherwise.
But a prototype answers the easiest question on the list. The ones that decide whether you have a business arrive on three timelines: tomorrow, next quarter and next year.
If you can build it in a weekend, so can everyone else.
The 3 things AI can't build for you
When building gets cheap, the hard parts don't disappear. They move to before you build and after you launch. Here are the three I see founders skip most often:
1. A question worth answering (tomorrow)
The goal of an MVP is to answer questions: validate your assumptions, find product-market fit, figure out which revenue model works and learn where to put your effort next. Eric Ries, who popularized the term, defined the MVP around learning, not features.
What you need to learn first depends on where you're headed:
Raising a seed round? Put yourself in your investors' shoes: what will they ask, and what would make them move forward?
Acquiring your first users? Define your ideal customer and be laser-focused. You can widen the circle later.
Going B2B? Find your first design partner and shape the product with them, not just for them.
Launching a program or an internal tool? Same idea: name the outcome, not the output. “Roll out the case management tool” is a project; “caseworkers log visits the same day instead of on Friday” is a goal.
SMART targets help, as long as each one tests something. 500 pre-signups in 6 months tests whether people feel the problem; $10,000 MRR in 4 months across two price points tests whether they’ll pay, and at what price.
A healthcare founder came to us with a feature list: everything their competitors could do, plus a few extras. When we asked what the first version was for, the real goal came out. They needed to prove they could collect consistent data with minimal effort from users to get strategic investors interested, investors interested. A lot of features in the list they’d shared don’t directly contribute to data capture. Their goal came down to one line: “This version will tell us whether we can get 500 users to share meaningful data consistently.” And that became our new starting point.
My advice: Before you write a line of code, finish this sentence: "This version will tell us whether ___." If you can't fill in the blank, you're not ready to build yet. You're ready to talk to users.
2. A way to reach people (next quarter)
Hope is not a strategy. Your acquisition plan has to match your stage, the time you can spare while building, and your budget.
Which brings me to the most underrated rule in this issue: you are building for the users you can acquire, not the ones you wish you had. If the only channel you can work next quarter is your network of HR managers, your first product is for HR managers. For a nonprofit, that's volunteers and donors; for an internal tool, it's the colleagues who have to choose it over their spreadsheet.
Paul Graham's Do Things That Don't Scale is blunt about it: founders have to go out and recruit their first users by hand. The authors of Traction go further and suggest spending about half your time on getting customers, testing a few channels cheaply before you commit to one.
Movana, a company I co-founded, set out to help anyone move. On paper, the customer was obvious: moving companies across the US, and the numbers worked. In practice, we had no way to reach them. We were building for users we couldn’t acquire. So we narrowed it to an audience we could reach: college students moving out between semesters. That one decision reshaped the product and the message. Next came booths on campus on Founders’ Day and joining parents’ groups on Facebook. The result: our first paying customers, lessons to improve the process next semester and a blueprint to replicate at other colleges.
My advice: Before you build, name the two or three channels you'll test next quarter, what each will cost in hours and money, and the result that would make you double down.
Unpopular opinion: Your first 50 users should take more of your time than your first version did.
3. A reason to stay (next year)
Every founder's old nightmare: "What if Google copies my idea?" These days it doesn't take Google, just one developer and a long weekend. So why would people pick you, and keep picking you?
Split your answers into two columns. What gets you in the door is your know-how and your values. They're real advantages, but a well-funded competitor can hire know-how, and AI is getting very good at packaging it. What keeps others out:
Distribution. Anyone can copy a dog raincoat. Few can copy a co-marketing deal with a pet insurer and a premium dog food brand.
Local focus. Be the go-to platform for padel players in the Bronx. Peter Thiel's version in Zero to One: start with a market small enough to dominate, then expand.
Switching costs. Once your product holds someone's data, history and daily workflow, leaving hurts. Hamilton Helmer counts it among his 7 Powers.
And no, price isn't a moat. Someone can always go lower, usually someone with deeper pockets. For a nonprofit or an internal tool, the copycat isn’t a startup. Your moat is why staff still open your tool after the person who championed it leaves.
We built Trade + Prosper, a marketplace that helps makers find and sign up for markets and fairs. Marketplaces are among the easiest products to copy and the hardest to grow: nobody joins until everyone else has. Its founder, Louise, had a head start. She’d sold at these markets herself with her family’s distillery, Cooper’s Daughter Spirits, and she produced Nyack Spring Forward Maker Market. Makers and organizers already knew her. Through her, Trade + Prosper became the go-to app for those makers and markets. That’s distribution, and nobody copies it over a weekend.
My advice: Write your advantages and your moats in two separate columns. If you don’t have clear moats listed, that becomes your priority for next year.
MVP or the "real" product? Wrong question.
The real question is what the next version needs to teach you, and what it needs to survive if it works.
That's how we work now. We use AI to prototype in days, so the budget goes into the parts that decide whether a product survives: the question it answers, the first users and the pieces that are hard to copy.
Here's what that looks like in practice:
Right now we’re building an observatory: a platform that brings social, economic and environmental indicators into one place for local decision-makers. The brief asked for an unlimited number of indicators, multiple integrations and advanced features. We’ve seen platforms like this stall for the same reasons: they cost too much to run, nobody owns the upkeep and few people use them. So we proposed the opposite. Version one goes to a small group of people who have a reason to use it and time to be trained. We take the management work off their plate and centralize it. And we start with a few dozens indicators instead of hundreds: we can add indicators any time. Launching hundreds that nobody maintains is much harder to walk back. Once the core is in use, the integrations, extra indicators and new use cases follow.
None of that is hard to build. All of it is hard to get right before you build.
Before you build, answer these three questions:
What will this version teach us? "Whether people like it" isn't an answer. Which people, doing what, by when?
Where are our first 50 users today? Name the community, the partner or the people. "Everyone" is not a place.
What would we still have if someone copied it next weekend? If the answer is "nothing", that's on top of the list for next year's work.
The three questions as a one-page "Before you build" worksheet, The first piece of the evergreen checklist. Draft: "Want these on one page?
Sitting on an idea, or on a weekend prototype you're not sure what to do with?
Just reply to this email. I read every one, and I'm happy to give you an honest second opinion, no pitch.
News from the Nest
After plenty of back and forth, we kicked off three projects almost at the same time over the past few weeks. One is with a startup in the wellness space (stay tuned, more in the next issue). The other two are observatories with a GIS component in Lebanon: one with an international development partner, and one with a local one. The first will help local government shape policy and the second will help local farmers plan their irrigation schedules.
For a long time, we've been looking for a way to support our local community with our skills at a larger scale, beyond our pro-bono work with the Lebanese Red Cross and supporting kids in villages along the southern border.
Big shout-out to Dr. Wassim Katerji, who heads our GIS practice and is leading the GIS side of both.
It's the local moat from earlier, in practice. Plenty of teams can build a GIS dashboard; fewer have roots in the communities that will use it. And neither goal is "a dashboard": it's better policy decisions and smarter irrigation.
Useful Resources: For tomorrow, next quarter and next year
Summary: Why your first users won't come to you, and why recruiting them by hand is how most successful startups got going. Short, practical and still the best essay on early acquisition.
Summary: A playbook for finding the one acquisition channel that works for you. Its Bullseye framework: brainstorm across 19 channels, run cheap tests on the three most promising, then focus on the winner.
Summary: The case for starting with a market small enough to dominate, then expanding. Read the chapter on the "last mover advantage" before you worry about being first.
Summary: A rigorous look at the handful of things that make a business hard to copy, from switching costs to network effects. Dense but worth it; if you'd rather listen, Helmer walks through it on Lenny's Podcast.
P.S. Next time: the decisions you can't walk back from, and why toddlers fall 17 times an hour. Know someone sitting on a weekend prototype? Forward this to them. If it was forwarded to you,
Ciao!
Chris