←back to thread

Ask HN: Were early stage products always so buggy?

10 points AbstractH24 | 3 comments | 21 Apr 25 21:39 UTC | HN request time: 0.627s | source

I help startups roll out tools for their go-to-market teams. These days, I keep coming across different products with small teams, the backing of notable VCs, and lots of potential, but then when I go to use them the UIs are just littered with bugs which prevent them from functioning. And often it has nothing to do with prompting, hallucination, or anything like that. It's simple things like "when I hit save, my data disappears."

I'm accustomed to working with buggy tools, nothing I do is mission-critical, so things aren't as thoroughly tested as a car might be before hitting the road. But it seems things are getting released with more and more bugs. Am I nuts?

Seems like there are three possibilities to me:

1. This is just what happens with products that are new to market. 2. People creating these products are relying too much on tools like Cursor that don't work right. 3. The pressure to keep up is getting faster and faster, so companies are releasing products that are less and less thoroughly tested.

My gut tells me it's a combination of 2 and 3, and this is a sign we're reaching a new stage in the AI bubble. But maybe I'm wrong and being overly cynical.

Show context
TheKelsbee ◴[21 Apr 25 23:44 UTC] No.43757670[source]▶
Years ago, before the Internet, software was expected to be rather buggy. It took a long time to research and fix. Releasing software was expensive, you had to put it on physical media and ship it. QA was critical role, it was way less expensive to test the hell out it and fix it than it was to ship new code. The idea that computers could be trusted to perform tasks well was easily shattered when things went wrong, and the additional optics of losing customer trust went a long way into driving QA.

Fast forward to today, and it's way cheaper to ship code with bugs to prove out an idea works than it is to spend even a few minutes writing test cases and doing even a modicum of QA.

Ultimately, it's a not just a combination of all 3 things you've mentioned, which are all contributing factors; the real problem is any level of QA before proving an idea is seen as a waste of time and money. As someone who started in tech support & QA 30 years ago, it's really tough to see.

replies(2): >>43757707 #>>43759571 #
1. AbstractH24 ◴[21 Apr 25 23:50 UTC] No.43757707[source]▶
It just seems like the idea its actually cheaper to ship broken code than invest in QA is, well, wrong.

And I'm just thinking about the amount of time people spend paying me to work through these bugs with the team at the startup building it.

Putting aside the whole "it's easier to keep a customer than it is to acquire one" and "easier to keep your good reputation that overcome a bad one" side of things (and there is one tool a client asked me to use that I told them either the tool goes or I do),

replies(1): >>43757898 #
2. didgetmaster ◴[22 Apr 25 00:21 UTC] No.43757898[source]▶
Your argument certainly holds water for a company that is thinking long term. But too many individuals within organizations are thinking short term instead.

Ship out the product, even if it isn't ready. Meet your performance goals for shipping on time. Collect your bonus and exercise your stock options. Bail to another gig before the consequences for the buggy product hits the fan.

replies(1): >>43758961 #
3. AbstractH24 ◴[22 Apr 25 03:56 UTC] No.43758961[source]▶
Aligning incentives is a very delicate art.