Opinions expressed by business partners are their own.
The first version of our financial app forced users to fax a sign-up form in 2018.
It worked.
This experience taught me a lesson every founder eventually learns the hard way: early traction is more important than pretty systems. If you’re waiting for something to polish up before testing your demand, you’re probably waiting too long.
This is the story of how an “ugly” MVP helped us validate trust, validate real customer behavior, and avoid the most common mistake that stalls early-stage companies.
When faxing was a feature
When we launched Unit’s first savings and investment app for young families, the experience was designed to feel modern and simple. Parents can upload a photo of their child, tap a few buttons, and see how an 18-year-old can grow to $100,000 a month. Opening a 529 custodial account suddenly felt as easy as ordering takeout.
Behind the scenes, in 2018, the only way a registered financial advisor could actually open a 529 account was to fax a PDF to a US state. When the first fax went through successfully, we celebrated like we had just closed a Series A. A few days later, the supplier called: “We no longer accept faxes. Please send everything by slow mail.”
It felt ridiculous and fragile. In hindsight, it was exactly the right way to start. Building proof of concept without significant investment forced us to focus on validating demand before scaling infrastructure.
How the best startups start small
It wasn’t just an investment. The most famous startups didn’t start polished — they started scrappy.
- Zappos: Nick Swinmorn photographed the shoes in stores, posted them online, bought pairs at retail, and shipped them himself.
- Airbnb: Brian Chesky and Joe Gebbia rented air mattresses in their apartment and served breakfast to guests during a sold-out conference.
- Uber: Travis Kalinek and Garrett Kemp manually texted a small circle of limo drivers for an invitation-only service.
These founders were not obsessed with beautiful systems. They were all focused on taking the fastest route from idea to minimum viable product.
What exactly is an MVP?
An MVP is not a simplified version of your final product. This is the most basic version you can build to test demand and collect real customer feedback. Many founders aim for completeness rather than specification, dreaming of full feature sets, flawless UX, scalable infrastructure and polished backends. The reality looks very different.
A true MVP is a front-end with enough value to deliver, paired with a messy, manual backend. Your product can look polished to customers while being completely impenetrable behind the scenes. It’s not a flaw – it’s the point.
Learning through an ugly MVP
The biggest surprise in the build-up to No MVP wasn’t technical — it was emotional. Onboarding wasn’t just a chimney. It was a trust test.
Early data shows that parents are relegated to the second screen. Problem: We were asking for both the child’s and the parent’s Social Security numbers too early. Compliance was understandable, but from a human perspective, it was scary. Parents weren’t rejecting the product—they were rejecting a moment that felt too threatening.
The fix was not complex engineering. We moved SSN requests later in the flow and added plain English explanations about security and why the information was needed. Completion rates improved almost immediately.
The lesson was simple: get something clickable into the hands of consumers as quickly as possible. You don’t need a perfect system to test trust. You need a product that works well enough to tell consumers where it isn’t.
Early beta lessons forced a big realization: Unit MVP was working because it was ugly. Friction, manual processes, and imperfect systems surfaced in exactly the way that matters most—where customers hesitate, what they trust, and what they’re willing to push. Across industries and decades, startups that win don’t start with polish — they start with learning.
Three principles that actually matter
Progress comes from learning, not polish. MVPs work when they help founders replace assumptions with evidence. These three rules consistently appear in companies that ultimately scale:
1. Speed over perfection
Markets reward learning speed, not beauty. Early-stage founders often believe that a product needs to be “ready” before it can face the world. Perfect products delay the one thing that matters most: real-world feedback.
2. Get customer feedback fast
Features don’t create clarity – conversations do. Early users will forgive errors, missing functionality and manual processes. What they will not forgive is being neglected.
3. Prove demand before spending big
Capital does not cure uncertainty – it exacerbates it. Incorrect decisions make it expensive to validate demand locks before scaling and undoing them.
We followed the same discipline. The evidence came first. Then there was the investment. The strongest MVPs don’t minimize effort—they minimize regret.
The first version of our financial app forced users to fax a sign-up form in 2018.
It worked.
This experience taught me a lesson every founder eventually learns the hard way: early traction is more important than pretty systems. If you’re waiting for something to polish up before testing your demand, you’re probably waiting too long.
