Forem: Ismael fi

Why MVPs in 2026 Are Not Ugly Anymore

Ismael fi — Sat, 21 Feb 2026 15:23:01 +0000

I Used to Believe the Classic MVP Advice

Ship fast. Cut corners. Design later.

For a long time, that logic made sense.

Time was limited. Budgets were tight. Users were more forgiving.

That context doesn’t exist anymore.

Not because founders changed.

Because users did.

Quietly.

The Assumption That No Longer Holds

The old rule was simple:

“An MVP can be ugly. People only care about the problem.”

I built more than one product with that mindset.

What I missed was what users were actually comparing us to.

Not other MVPs.

Not early stage startups.

They were comparing us to the tools they already use every day.

Clean.

Fast.

Calm.

Predictable.

That’s what software feels like to them now.

So when they open your product, they don’t ask:

“Is this an MVP?”

They ask, often unconsciously:

“Does this feel serious?”

Users Don’t Downgrade Expectations Anymore

Nobody thinks they’re “trying an early product.”

They’re just trying a product.

And their baseline is already set by years of using very good software.

When something feels clumsy, it doesn’t register as early.

It registers as careless.

That difference matters more than we like to admit.

AI Quietly Removed the Main Excuse

For years, bad UX had a convenient justification.

“It’s expensive.”

“It takes time.”

“We’ll clean it up later.”

That excuse is mostly gone.

AI didn’t magically make products great.

But it made acceptable quality much cheaper and much faster.

Layouts.

Copy.

Empty states.

Basic flows.

Not perfect.

But no longer an afterthought.

So when an MVP feels rough in 2026, users don’t think:

“They’re early.”

They think:

“They didn’t bother.”

Speed Isn’t the Bottleneck Anymore

This part took me longer to accept.

We still talk about speed as if it’s the main advantage.

Build faster.

Ship faster.

Iterate faster.

But most founders can already ship fast now.

The real constraint has shifted.

It’s taste.

It’s judgment.

It’s knowing what deserves attention and what doesn’t.

You can move fast and still learn nothing.

I’ve done that more than once.

Why High-Fidelity MVPs Teach Better Lessons

This was one of the biggest surprises for me.

When an MVP is rough, feedback is noisy.

Users complain about surface things:

“I didn’t get it.”

“It feels confusing.”

“I got lost.”

You end up fixing friction instead of understanding the problem.

When an MVP is clean, feedback changes.

People talk about:

What they expected
What they don’t need
Where value actually shows up
What feels unnecessary

That’s product feedback, not polish feedback.

High-fidelity MVPs don’t just convert better.

They help you learn the right things sooner.

Where AI Genuinely Helps

AI is very good at removing friction around thinking.

Drafting copy.

Exploring layouts.

Creating variations.

Speeding up boring decisions.

Used well, it gives you more space to think about:

The core flow
The moment of value
What really matters to the user

It amplifies judgment when judgment is already there.

Where AI Still Fails

AI doesn’t feel confusion.

It doesn’t hesitate.

It doesn’t get stuck.

It doesn’t feel that subtle “something’s off” moment.

That still comes from watching real people use your product.

And sitting with the discomfort of seeing where they struggle.

No prompt replaces that.

The Real Shift

The shift isn’t “build beautiful MVPs.”

It’s this:

An MVP is no longer just a test of an idea.

It’s a test of care.

Care in what you include.

Care in what you remove.

Care in how much you respect the user’s time.

Ugly MVPs used to buy you speed.

Now they often just buy you the wrong conclusions.

Where I’m Still Unsure

I’m still navigating the line between:

Moving fast
Being deliberate

Between:

Keeping things simple
Not cutting the wrong corners

That tension doesn’t disappear.

But pretending that ugly MVPs still work in 2026

is how you spend months learning the wrong lessons.

I learned that the slow way.

I’m Ismaël, and I run MVPable, a small product studio focused on shipping high-fidelity MVPs. This piece comes from mistakes I made while building and rebuilding products, not from theory.

I’m curious how other builders are thinking about this tradeoff right now.

I Didn’t Build MVPable to Save Time.

Ismael fi — Fri, 19 Jul 2024 08:47:26 +0000

I Built It Because I Was Tired of Starting From Zero.

A few days ago I pushed a full refresh of MVPable Kit.

Cleaner structure.

Better defaults.

Solid documentation.

It’s sitting at 150 stars now.

That number isn’t huge.

But it’s real.

And it reflects something I didn’t expect when I first built it.

The Real Situation

For years, every SaaS project started the same way.

New repo.

Rewire auth.

Reconnect Stripe.

Rebuild admin logic.

Re-decide folder structure.

I kept telling myself that starting clean meant starting smart.

Most of the time, it just meant repeating myself.

What I Expected

I thought each project deserved a fresh foundation.

Custom decisions.

Tailored architecture.

More control.

Instead, I kept rebuilding the same 70 percent.

And losing weeks before even testing the core idea.

What Actually Happened

At some point I stopped romanticizing setup.

I just wanted a base that:

Works
Scales
Doesn’t fight me
Doesn’t require rethinking everything

So I extracted what I kept rebuilding.

That became MVPable.

Not as a product launch.

More as a personal standard.

The Boring Truth

The foundation of most SaaS products is not unique.

Auth.

Billing.

Roles.

Admin.

Basic SEO structure.

None of this differentiates you.

Execution does.

Iteration does.

Clarity does.

Why the Refresh Mattered

The recent refresh wasn’t cosmetic.

It was about removing ambiguity.

Better documentation.

Clear setup steps.

Cleaner structure.

Less guessing.

Because friction doesn’t only exist in code.

It exists in onboarding builders too.

If someone clones your repo and feels lost,

you failed before they even start.

The Part That Changed My Thinking

Seeing 150 stars isn’t about validation.

It’s a signal.

It means other builders are also tired of rebuilding foundations.

And documentation matters more than clever abstractions.

People don’t need brilliance.

They need clarity.

What Surprised Me

Speed didn’t just improve when I used it.

Confidence did.

When your base is stable and documented:

You don’t hesitate.
You don’t re-architect mid-build.
You don’t second-guess every structural choice.

You focus on what users will actually see.

That shift is subtle.

But it compounds.

The Tradeoff I’m Still Aware Of

There’s a danger in having a strong base.

You can confuse smooth setup with real progress.

Shipping infrastructure feels productive.

Shipping value is different.

So I try to treat MVPable as scaffolding.

Not as the house.

What I’m Doing Next

I’m refining it based on real usage.

Removing what doesn’t earn its place.

Clarifying what causes hesitation.

And documenting decisions more than features.

Because future me will forget why I chose something.

And so will everyone else.

Quiet Takeaway

I used to think speed came from working harder.

Now I think speed comes from deciding once

and documenting it well.

Still testing that idea.

But the refresh feels like a step in the right direction.

My magical tech stack as an Indie Hacker

Ismael fi — Fri, 10 Jun 2022 19:40:40 +0000

Introduction and Context

Hello, this is Ismael. Five years ago, I was working full-time as a telecom engineer. I decided to pivot my career and become a web developer. I started with vanilla JavaScript, then followed the trend and picked up React. After months of working on React projects, I landed my first freelance job 😎.

However, I realized that just working as a web developer wasn't fulfilling enough. I wanted to explore marketing, growth hacking, and business. Eventually, I found my true calling: creating software products. React is fantastic, but it's not always sufficient for delivering comprehensive software solutions, especially for SaaS.

After trying React + Express.js, I found it challenging to deliver high-quality, thoroughly tested products quickly as a solo developer. My college experience with PHP and OOP helped me get started with Laravel, and I fell in love with it. With Laravel, I had my app up and running in a few commands, complete with authentication, routing, views, and controllers.

If you don't have much web development experience, I recommend starting with PHP and then moving to Laravel to kickstart your next project. Don't like PHP? Rails, based on Ruby, is a good alternative.

Alright, let's dive in! 🚀

Design

I design everything in Figma and then implement it in Tailwind CSS, with the help of Tailwind UI.

Development Stack (TALL: Tailwind CSS, Alpine.js, Livewire & Laravel)

Language: PHP & JavaScript
Framework: Laravel & Livewire – a full-stack framework for Laravel that makes building dynamic interfaces simple
Front-end: Alpine.js & Blade (Laravel’s template engine)
UI: Tailwind CSS
Starter Kit: MVPable – a minimal SaaS boilerplate
- Demo: saaskit.mvpable.com
Local Server: DBngin & Laravel Valet for local webserver needs
Admin Panels: FilamentPHP
Database Management: TablePlus
Source Control: GitHub
CI/CD Tools: CircleCI / Jenkins
HTTPS Certificates (Local): Valet — one command: valet secure
Mail Testing: Mailtrap

Production

Servers and Databases: AWS
Static Sites: Netlify
Error Tracking: Larabug
Downtime Tracking: Oh Dear
Analytics: Google Analytics
Mails: Mailtrap
No-Code and Integration: n8n – helps reduce my codebase by 20%. Let me know in the comments if you want to see a blog post on this topic.
Server Management: Ploi – installs on the fly: NGINX, MySQL/PostgreSQL/MariaDB, Redis, Supervisor, PHP (multiple versions), Composer, Memcached, NodeJS, UFW Firewall, Fail2ban, and other basic packages.
DNS Management: CloudFlare (integrates with Ploi)
Code Generator: Vemto – an amazing tool that helps me focus on value rather than developing CRUD functionality. Let me know in the comments if you want to know more about it.

Conclusion

This is my go-to approach for creating software products:

Find a Framework: Choose one backed by a large community with an easy learning curve. This way, you can ask for help and progress faster.
Keep Your Codebase Small: Fewer errors and more confidence.
Don't Reinvent the Wheel: Pick a framework that offers essential building blocks like database/ORM, queues, WebSockets, and authentication.
Monolithic Architecture: One codebase to manage everything.

Next time, I'll share tactics on how to find product ideas and attract your first customers.

About Me

Hello everyone! I'm Ismael. I help entrepreneurs launch their MVPs by using both no-code and code tools to quickly create and launch digital products that are both scalable and easy to maintain, starting from the very beginning.

Any questions? You can DM me on Twitter @ismael_fi 🐦.

Petite confession

Ismael fi — Tue, 28 May 2019 12:45:03 +0000

I love reading blogs. I've been reading blogs for some time now, I guess, for three years.

I had a lot of privilege reading discussions and reflections of some blog authors on various topics. My daily dose of news and blog analysis continues to grow. I like this feeling that reigns in my mind after reading a carefully written article.

I am very happy to join the party.

Cheers!

--- FR ---

J'adore lire des blogs. Je lis des blogs depuis quelque temps déjà, je suppose, depuis trois ans.

J’ai eu beaucoup de privilège de lire des discussions et des réflexions de certains auteurs de blogs sur des sujets variés. Ma dose quotidienne de nouvelles et d’analyses de blogs ne cesse pas d'accroître. J'aime cette sensation qui règne dans mon esprit après avoir lu un article soigneusement rédigé.

Je suis donc très heureux de me rejoindre à la fête et partager avec vous mon opinion.

à bientôt !

Ismaïl.