Updates

A running log of what's shipping while MVPMarket gets built.

2026-08-12

Asked buyers this time. Here's what came back.

Been heavy on seller-side validation so far, proving MVPs are worth something if they clear a real bar. Hadn't actually asked the other half of the equation: do buyers trust this, and what would make them.

Posted a version of that question across a handful of subreddits. Got a lot back, more than expected, and a few patterns showed up again and again from people who'd never seen each other's answers.

The gap isn't features, it's data. A demo runs on clean, invented data. A real business has duplicate records, renamed fields, three date formats, an integration held together with tape. The tool works fine and then meets the mess. Setup pain is almost always import and exceptions, not configuration.

Documentation alone doesn't fix that. A handoff doc written before the sale is written by someone with every incentive to make it look easy. That's where "plug and play" claims come from in the first place. A buyer can't tell a good doc from a bad one until they're three weeks in.

What actually built trust, according to the people who buy this stuff regularly: sellers who say plainly what the tool doesn't do and who it isn't for. Nobody volunteers their own limits by default, so when someone does, it costs them something to say it, and that's exactly why it's a real signal.

Buy-first is the default, not build-first. Almost everyone said some version of the same thing: buy first, build only if the pain sticks around after real, repeated use. The cost nobody prices into "I'll just build it myself" is the maintenance, not the weekend it takes to stand something up.

A few other things came up enough to take seriously: buyers want to get their own data back out without asking anyone, and want to cancel without emailing a retention person. A couple of people said they test a seller's support response time before ever paying, treating it as a preview of what happens after.

One thing that came up but isn't happening yet: someone proposed holding payment in escrow until the tool actually works on the buyer's own data, not just the demo. That's the right long-term answer. It's also real payment infrastructure this project deliberately isn't building yet.

Changing because of this: listings will need a short, plain statement of what the tool doesn't do and who it's not for, not just a capability pitch. Also adding an optional field for sellers to note their security/privacy practices, since a couple of people evaluate that formally before recommending a purchase.

Not changing yet: no escrow, no automated verification of any of this. Still validation stage. The next real test is still whether an actual listing clears the bar and an actual buyer shows up.

2026-08-10

Infrastructure is live

Connected the waitlist to a real Supabase project and deployed to Railway. Signups now hit a live database instead of a placeholder, and the site is reachable at a public URL.

2026-08-10

Waitlist is live

Shipped the waitlist page: email + role signup backed by Supabase, a live signup counter, and the review bar that lays out what actually gets a listing approved.