Software MVPs can no longer be low quality | Hacker News Reader

Software MVPs can no longer be low quality

threadreaderapp.com

28 pointssynergy2027 comments

> Your competition is no longer non-software solutions. It's probably existing, but sub-optimal software. Which means if you're going to compete with it, your software needs to be significantly better.

This is the crux of this person’s argument, but it’s not a generally true statement.

If you are competing with existing software, then it’s true that you need to bring something new to the table: A new feature that people need, a lower price for core functionality, or a better experience. If you don’t have any differentiator, of course you’re going to fail.

However, you still need to find what that MVP is and ship that.

I think there is a real problem of people taking the old MVP advice too literally about shipping software when you’re still embarrassed by the quality. Recently there are numerous examples of companies shipping things that are so MVP that they’re either nearly unusable or missing actual key features that people need. The recent trend of AI hardware assistants is a prime example. The products are so MVP that they’re not even enjoyable to use and the promised killer features are missing. As a result, the reviews are terrible and people are noticing. Even if they can improve the product later, it’s going to be very difficult to recover from all of those initial negative impressions.

Yep, the view in the post is narrow and singular. It just happens to be the type of apps that show up on HN. I would call them lifestyle apps where "craft and taste" is what differentiates them.

People overly focus on the M and completely forget about the V in MVP.

A MVP should be whatever is "minimally viable"; it's right there in the name. It never meant bad software.

I would add the P stands for product. Something you are willing to purchase. I'll pay for a working, shipping product. No effing way I'm ever paying for a beta. If I'm "testing" then my feedback and time is the exchange.

This depends highly on your target niche though. Beyond what the author mentions in terms of competition, I think higher quality MVPs are demanded for another reason: as the state of our tooling improves, the product of those tools will be expected to have improved as well. Iterating is faster with interpreted languages compared to compiled languages. Libraries make it near effortless to add features like social login, we have entire ecosystems of templating (things like Tailwind). AI has lowered the barrier for graphic generation and other elements that were once deemed "nice to haves".

I love anything that says we need to build better software.

That said, just how crappy are people’s MVPs these days?

The point of an MVP is to make something tiny and less polished, but functional, not actually broken.

> And in the age of AI, there's only going to be more software, along with LLMs that avoid the need to even use software.

This doesn’t make any sense. An LLM is software.

Yes LLM is software but you don’t need to create a software to translate documents anymore, for example. ChatGPT is enough. So a translation mvp app won’t cut it. But a high quality one would

Dont get me started on this. I have heard this "embarassed by quality" argument for almost 15 years. And the wierd thing is founders actually take this to mean building purposefully shitty products. And these days with amazing tooling building not-so-shitty product is actually in my observation only 10-20% more effort but pays off a lot in the medium time. I am so annoyed at the number of times we ship something with "oh this is as simple as adding X and we can refine later". The X rarely gets used, the later never comes (rightly so as the feature was never useful to begin with and was nothing more than a personal gut of who ever was championing it). Worse the bugs around X show up much sooner as it has to N^2 interface with the rest of the features. There is a tangible and short term cost to all this tech-debt that gets treated as "oh thats just engineering". Ok end of weekly rant.

There may be something to this.

I've been letting people use semi-supervised development previews of Timelinize[0] for a little over a year now -- it is unfinished, unpolished, buggy software, but I wanted to get it in people's hands while I stand by in real-time ready for feedback, to prove out the concept and see if I am even on the right track. I let users know it is in the very early, rough stages, and to really just follow the instructions and do the happy path for now.

The feedback is lukewarm, and most users are disinterested at this point. Which is unfortunate, since I believe that a fully functional application would actually draw them in, because a few testers did actually express amazement at the basic idea of what they saw the software do for them in an initial trial run. Most feedback got lost in the weeds of the known bugs and unfinished aspects, though, which didn't really tell me anything I didn't already know, and it just discouraged testers from trying more/again.

Could be a did it wrong. But at this point I'm having to forge ahead in my nights/weekends and basically finish writing this very complicated piece of software in the hopes it'll be something great, even though it doesn't exactly have direct competition that I know of. (Ultimately, though, I just need it to be great for me and my family. I am just hoping others will find it useful too.) When I finally do release a public beta, it had better be good. That's what I know now.

PS. Looking for a different name that doesn't sound like Tylenol -- according to repeated user feedback.

[0] https://x.com/timelinize and https://timelinize.com

That is not a MVP. It's also not a DP. And from your description it's not even a beta.

What you have is a PoC (proof of concept).

Also you should carefully screen who you expose this to. If the feedback is lukewarm you are using the wrong testers. Because your PoC is too early. It appears everyone has different expectations. You were expecting enthusiastic feedback to gauge interest, your testers were expecting a product near completion.

I went to your website and clicked around but I couldn't really tell what I can use this for. I can guess, but at the moment it just kinda seems like "look all your data shoved into a single unified database!" Maybe I just missed it browsing on mobile, but I think you use cases more than you need to address bugs or unfinished aspects.

Sidenote, but I've stopped visiting Twitter/X since you basically can't ever see a post without being logged in.

imo bugs that do affect the functionality means your mvp is wrong. Mvp doesn't mean buggy software, it means a software that can execute core functions without bothering the user. If the software can't deliver core functions reliably, maybe it hasn't reached mvp? if users encounter bugs in other areas of your software, maybe you should reevaluate what are the core functions of your app or what users do indeed use?

It was never about "low quality" it had to be viable. That meant it did a thing better than the competition or current solution.

What it meant was that you were allowed to not have features, or required someone to guide a user when they first used it.

Also Viable is doing a lot of heavy lifting here.

Viable for a some internal tool is wildly different to a product released by a large company.

My MVP has a very poor quality UI, and I feel the pain for it. On the other hand, UX is OK and functionality is 100% what its typical persona expects for their business process. So, it works and customers are happy. My everyday wish is to give its UI a revamp, but I don't have the means to do it now.

People have been talking about "minimum lovable products" for years now. It's well known that garbage won't be viable.

Paradoxically though, most new products wait far too long until they begin testing viability, so MVP logic still applies.

Do people not talk about "red ocean/blue ocean" anymore?

https://www.blueoceanstrategy.com/tools/red-ocean-vs-blue-oc...

The author's point is that a blue ocean strategy won't work in a red ocean.

> This advice made sense when there wasn't much software out there.

But the author is under the impression that until recently every market was blue ocean and now, suddenly, all are red. I can only assume he's been a heads-down dev not paying much attention to the business in the past.

I think this is true, but it hinges on a very specific definition of 'quality'. An MVP only needs to demonstrate that it solves the problem it aims to solve - everything else can be awful and people will still buy in if they see the value the software gives them. People need to see 'quality' in the solution to the problem, not necessarily in things like UX, UI, perf, code quality etc.

Yes but most low hang fruits are gone by now unless if one chase underdeveloped markets

There are still massive markets that are chronically underserved by tech. The idea that 'software is eating the world' is done already is so far from true.

Shippable MVPs were never about trading quality for time to market. That's a misunderstanding, borne from people taking the idea too literally.

You could:

- trade tech debt (future changes are harder) for time to market

- features for time to market

- a bit of usability for time to market

But not quality, never quality if you're going to ship it.

If the quality is too low, it's not viable. This was always true.

MVP is a great approach, but very tricky to balance against "you only get one chance to make a first impression".

This is true, unless you build a low quality MVP and it does well.

I can't express how much I agree with it!

Well, the time frame to ship an mvp should be kept constant. Naturally, better tools enable more capable MVPs.

Just a couple of years ago, I would not have dreamt of creating an mvp with advanced Ai functionality. Now that's just another part of any mvp.

> read some of the writings of @karrisaarinen at @linear. He speaks about the need to build with taste and quality when you are building in a mature market against incumbents.

This is true in mature markets. No one would give Linear a real shot if it was worse than Jira or the dozens of others like it. To get someone to take the product seriously, it needed to be really good on at least one key dimension and couldn't be terrible on others.

Analytics software is a mature market. Our differentiator at Definite[0] is that we give you a full data stack in one platform. You can't build that as a product in a few weeks. We ran MVP's where we manually built data stacks for customers, but our product took a year to get into an MVP state.

0 - https://www.definite.app/

Reply on news.ycombinator.com