What Project Turnkey Was Supposed to Be

Project Turnkey started as one thing: an ML-powered lease analyzer. Tenants upload a lease, the system reads it, and surfaces the risks they'd miss without hiring a lawyer. Clear problem, clear user, clear value proposition.

I built it in under a month. But I didn't launch the lease analyzer. I launched the lease analyzer, a landlord-rating aggregation system with an interactive apartment-mapping feature. A month of work that could have been two weeks to a paywall, with the remaining time spent on features nobody had asked for.

The landlord rating system wasn't a bad idea. Verified apartment reviews are a real need. But "real need" and "belongs in the MVP" are not the same thing. That feature could have been its own product. It could have been added in iteration two after real users told me what they actually wanted. Instead, I bolted it onto the lease analyzer before a single person had paid to use the core product.

Two Forces I Didn't Want to Admit

The first one is obvious. I'm an engineer. I love building. When I see a technically interesting problem adjacent to the one I'm solving, it's hard to say no. The apartment mapping feature was genuinely cool to build. That's not a good enough reason to build it before launch.

The second one is the one I didn't want to name: building is easier than selling.

Every feature I added before launch was another week I didn't have to put the product in front of someone and find out if they cared. It felt like progress. It wasn't. It was insulation. I was padding the product because I wasn't ready to hear "no" — or worse, nothing at all. There's a specific kind of anxiety that comes with putting something you built in front of a stranger and asking them to pay for it. Adding features numbs that anxiety. It gives you something to do that feels productive while you avoid the one thing that actually is.

I know this because I've seen the proof from the other side. When I describe Project Turnkey to people now — just the lease analyzer, "upload your lease, ML finds the risks" — their eyes light up. It's sharp. It's interesting. It's easy to understand. The moment I start explaining the apartment mapping and the landlord rating system, I'm not adding intrigue. I'm losing it. The pitch gets blurry. If you can't explain it in two sentences without someone's attention drifting, you've built past your MVP.

I could have been selling sooner. Not by much — the whole project was under a month — but even two weeks of real user data would have changed what I built next. Instead, I had a bigger product and the same number of paying users: zero.

The Line Nobody Draws

Most founders don't have a launch problem. They have a definition problem. They don't know what "ready" means, so they keep building. Here's where I draw the line now:

Demo. No authentication, no payments. Users can see it, click around, maybe give you feedback — but they can't commit. This is useful for investor meetings and early user interviews. It is not validation. There's no skin in the game. A user who says "this is cool" while browsing a demo is giving you a different signal than a user who hands you a credit card.

MVP. Authentication, payments, and one core feature that tests your riskiest assumption. That's it. Users can sign up, pay, and use the thing. The lease analyzer behind a paywall was Project Turnkey's MVP. If someone will give you their credit card and log in more than once, you have signal. Everything else is noise.

Over-built. Multiple features, secondary workflows, nice-to-haves — all before a single paying user has touched the core product. The landlord ratings. The apartment mapping. Every feature added before launch is a hypothesis you're treating as a requirement. And if you're being honest with yourself, some of those features aren't hypotheses. They're procrastination with a commit history.

Every product is different, and I'll be the first to say these lines bend. Marketplaces with chicken-and-egg dynamics, enterprise products with long sales cycles, anything where the core value requires network effects — the auth-plus-payments-plus-one-feature formula doesn't always apply cleanly. But for the vast majority of founders building something that solves a specific problem for a specific person, this framework holds. Don't use edge cases as an excuse to keep building.

Why Payments Are the Real Threshold

A free signup is interest. A payment is commitment. These produce completely different feedback.

Free users say "this is cool." Paying users say "this is broken," "I need this to do X," and "I'd pay more if it could do Y." That's the feedback that tells you what to build next. You can't get it from a demo. You can't get it from a free beta with six features and no paywall. You get it by putting the core thing behind a transaction and seeing what happens.

If I'd put the lease analyzer behind Stripe at week two, even at a low price point, I'd have learned more in a week than I learned building the apartment mapping feature.

The Fear-of-Selling Test

Here's a test I use now, for myself and for every founder I work with: if you keep finding reasons the product isn't ready, ask yourself whether you're solving a product problem or avoiding a sales problem.

If the feature you're adding would make the product meaningfully better for the user who's already trying to give you money — build it. If the feature you're adding would make you feel more confident about showing it to someone — stop. That's not product development. That's stage fright with a commit history.

The lease analyzer was ready. I just wasn't ready to sell it.

What I Do Differently Now

When I work with founders, this is the framework. Define the riskiest assumption. Build the minimum product that tests it. Put a paywall on it. Launch. Learn. Then iterate based on what real users tell you — not what you think they'll want.

The verified apartment reviews might come in iteration two. Or they might not come at all because users asked for something you never would have guessed. That's the point. The point of launching isn't revenue. It's learning. And you can't learn from users who don't exist yet.

Every week you delay launch is a week you're building on assumptions instead of evidence. The product might be ready. The question is whether you are.

If you're sitting on something that works but doesn't feel ready — or if you're three features deep into what started as one idea — that's exactly when to talk.