I started my career as a finance manager, transitioned into product management, and now I’m building my own products.

Back in my finance days, while managing a £6M budget, I uncovered a £15k leak hiding in plain sight: FX fees.

Today, I see solo founders making the exact same mistake. I realised most founders are quietly losing 2-5% of their revenue to what I call the Lazy Tax: - Stripe's ~2% auto-conversion fee on inbound revenue, - plus their local bank's ~3% spread when paying for global SaaS tools (AWS, Claude, Ads).

So I built FixMyFX to show founders their exact leak and how to fix it (using multi-currency accounts to achieve a zero FX leak setup).

Initially, I had Claude build this in React. Realised a simple calculator shouldn't need a 150kb payload and a complex build process. Threw the React code away and rebuilt it as a single lightweight HTML file using Alpine.js and Tailwind.

It's completely free and ungated. I hope it helps you keep a bit more of your hard-earned revenue. Would love your feedback.

Tania

Comments URL: https://news.ycombinator.com/item?id=47652213

Points: 4

# Comments: 1

and I to mine. :)

Pre-Build in|Validation is unambiguous about what needs to happen before we get into building. It doesn't take away from Customer Discovery nor from the Customer Development methodology.

it's curious that you're not commenting on the MVP => PVI tho

I'm new on here. if not markdown then what?

tbh I've never met a LI addict, so I wouldn't know if I saw one post.

I agree that it was never _meant_ to indicate that you jump straight into building an MVP.

However, people don't read the small print. Appreciate that a book isn't the proverbial 'small print' but not many founders read The Four Steps, The Startup Owner's Manual, The Lean Startup etc. _before_ they dive into figuring out how to take their idea forward.

I speak from experience - I've spoken with a number of founders who focused on building an MVP first and have spent hundreds of thousands in the process without any hope that they'd get their investments back.

The idea of MVP makes sense. But the term MVP is unhelpful and is responsible for more value destruction than it's helped create.

In fact I see two problems:

1. the phase before the MVP doesn't have a name 2. the term MVP suggests you need a product to validate your idea

To address these problems:

a. we need a name for the phase that comes before building - Pre-Build in|Validation

b. we build a Proven Viable Idea, not an MVP.

It's 2025, nearly a quarter-century since Frank Robinson coined "MVP" in 2001.

Robinson described MVP as a functional product "just the right size" for immediate needs. Eric Ries later refined it as "the smallest thing you can make or do to test your hypothesis."

Here's where things get interesting: Ries never required this "smallest thing" to be a working product. He explicitly recommended against writing code until evidence justified that investment.

There are two major problems tho:

1. People don't read the fine print 2. The P in MVP stands for Product

This creates a narrative that founders must build something to test ideas. The result? Countless founders spend thousands on MVPs only to discover nobody will pay for them.

## The Monkey and the Pedestal: A Mental Model

Consider this analogy: You need to teach a monkey to juggle flaming torches while standing on a pedestal.

Building a platform (pedestal) is straightforward, but teaching a monkey to juggle torches may be impossible.

The real challenge for any SaaS product is determining if people will pay for your solution. There's no point in creating a beautiful interface if nobody wants your product.

This mental model emphasises tackling the hardest problems first. For SaaS products, building the digital product is actually the easy part—it's just creating a pedestal. The difficult task is verifying if anyone would pay for your solution.

## From MVP to Pre-Build in|Validation™

Maybe we need a new framework that prioritises challenging our assumptions before writing code.

Enter Pre-Build in|Validation —an approach where we deliberately challenge ideas before investing resources in building them.

The term deliberately places "in" before "validation" because this process is equally about invalidating ideas as validating them. Many founders fall victim to confirmation bias, seeking evidence that supports their hypothesis while ignoring contradictory signals. Catching fatal flaws early saves tremendous resources. A quick, inexpensive "no" is far more valuable than an expensive, time-consuming "maybe."

## A Real-World Example: Bilingual Books

I had an idea for bilingual books with flexible language alternation—allowing readers to choose how text is displayed across two languages.

Instead of building this product, I spent just 5.5 hours over 10 days gathering feedback from parents raising bilingual children. This minimal investment provided invaluable feedback that led me to abandon the idea. Had I built an MVP first, I would have wasted months of development time and significant resources.

## Is MVP Truly Outdated?

Perhaps not entirely but its interpretation needs recalibration.

Somewhere along the way, "minimum viable product" became interpreted as "the smallest product we can build" rather than "the smallest experiment we can run."

What if we returned to Ries's original intent? What if we recognised that the "P" in MVP doesn't necessarily mean "product" in the conventional sense?

Our industry might benefit from embracing approaches that emphasise challenging assumptions before writing code. The true bottleneck isn't technical capability—it's finding a genuine problem-solution fit that people will pay for.

## The Path Forward

As founders in 2025, we have unprecedented access to tools and frameworks. The barriers to creating digital products are lower than ever. Paradoxically, this ease of creation makes it even more critical to validate ideas before building.

Perhaps it's time to move beyond MVP as our guiding framework and embrace methodologies that prioritise early invalidation over premature validation. After all, the most valuable learning often comes not from confirming what we believe, but from discovering why we might be wrong.

---

What do you think? Has MVP served its purpose, or does it still have relevance today?

Comments URL: https://news.ycombinator.com/item?id=43692886

Points: 1

# Comments: 12

will let you know when I'm ready to post more about this.

anyway, I got my first comment on here. that's a win in my book :)

btw, just seeing that you're a woman! I thought HN is overrun with men LOL

i'm in two minds about how much to share on here.

any suggestions? I'm new to HN and any advice is appreciated

You've probably experienced it: The nods of approval. The "that sounds awesome!" comments. The eager email signups.

And then...silence when it actually matters.

I recently watched a talented dev spend months building a solution everyone "loved" during conversations, only to launch to an empty room. The dev's devastation was palpable.

That conversation revealed something crucial: there's a specific type of danger lurking in the SaaS validation process that nobody talks about. It feels incredibly positive but leads directly to wasted time, depleted savings, and shelved dreams.

I've discovered a simple formula that explains this phenomenon:

*Encouraging Feedback + ??? = Startup Graveyard*

I'm working on something that will help you see through the fog of well-meaning enthusiasm to find the signal of genuine market demand.

Not just another "build an MVP" guide or "talk to customers" rehash.

This is about recognising a specific psychological pattern that tricks even the smartest builders into seeing validation where none exists.

Coming soon. For those who'd rather build what people actually need than what they politely claim to want.

Interested? Drop a comment.

Comments URL: https://news.ycombinator.com/item?id=43592327

Points: 3

# Comments: 6