Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The minimum viable unit of saleable software

brandur.org

Post reply on HN
Print view View original

31–40 of 89 posts

Re: The minimum viable unit of saleable software

#31

Post by Aurornis »

aaronbrethorst wrote: post #10
applfanboysbgon wrote: post #3

Be careful with making decisions about your livelihood based on a rational calculus. As you correctly point out, there is a threshold for which a programmer or company should not even blink at the cost of software. It's often the case that if the software they're buying saves one single hour of productivity, it's value-positive... and yet they won't buy it. Individual devs are notorious for refusing to pay a cent out…

Plus, too many companies don't spend their money in a logical fashion. As a manager, you can direct your $200,000/year engineer in any way you want, but try to spend any amount of money on a new SaaS product and procurement might huffily demand hours of your time and weeks of delay to authorize even $40/month, let alone $400/month. That said, I think the path Brandur is describing is well-trodden and proven out by pr…

Some of my past employers were pretty good about authorizing small and medium expenditures quickly, or in some cases not requiring any authorization at all.

This feature almost always went away as the company grew and the abuse became too much to ignore. I thought it would be safe to trust developers and to deal with isolated abuse when it came up, but the number of people who see any spending perk and treat it like a target they need to maximize is way higher than I ever thought.

There are a lot of examples of this, like companies that offer to pay for dinner if people have to stay late. This seemingly always turns into a game where people hang out in the office and scroll on their phones until the allowed time arrives, then they take their dinner and leave. This doesn’t happen at small companies where you can witness what people are doing, but cross the threshold to big company and many people start doing whatever they can get away with.

There was a big story a few years ago about how employees at a big company were even caught using this perk to order their home groceries because the DoorDash like service they used had launched a section where they could get those things delivered with their food. It was crazy that employees making mid six figure salaries were still brazenly breaking the rules for personal gain of a couple hundreds of dollars per month.

Re: The minimum viable unit of saleable software

#33

Post by sublinear »

monkeydust wrote: post #11

I wouldn't underestimate the community effect of software. There are plenty of features that get shipped because a small but important minority requested them, only to benefit the long tail of users who never knew to ask for such a feature but now find it indispensable. If everyone is building their own isolated solutions, how does this positive externality manifest itself?

Much of the business world sees that as very high risk.

In their eyes, community moderation is an inverted pendulum that eventually falls over. Either one niche and unprofitable direction dominates, or the community turns it into an incoherent junk drawer of features. You're also opening yourself up to competitors poisoning the whole thing. To investors, it signals a lack of vision.

Feedback isn't inherently good or bad, but it can be unnecessary risk if you already know you have a solid product that meets the most common use cases with the strongest demand.

This is why successful products tend to be very mediocre. They're the average of all insights considered. Doing anything else is leaving money on the table.

To answer your question, nobody wants their product to become the platform that launches your directly competing product. That's suicide. You're asking to ride someone else's coattails.

Re: The minimum viable unit of saleable software

#34

Post by Eridrus »

applfanboysbgon wrote: post #3

Be careful with making decisions about your livelihood based on a rational calculus. As you correctly point out, there is a threshold for which a programmer or company should not even blink at the cost of software. It's often the case that if the software they're buying saves one single hour of productivity, it's value-positive... and yet they won't buy it. Individual devs are notorious for refusing to pay a cent out…

I think people are more rational than given credit for. Their decisions are not necessarily rational for the company, but they are often pretty rational for themselves.

And some bureaucracy is often necessary to evaluate security, data protection agreements, etc.

Some companies are not efficiently allocating resources and so projects sit in legal/security review for longer than is reasonable, but it makes sense that individual developers don't have unilateral authority to use 3rd party vendors.

Re: The minimum viable unit of saleable software

#35

Post by chrisweekly »

brandur wrote: post #6
applfanboysbgon wrote: post #3

Be careful with making decisions about your livelihood based on a rational calculus. As you correctly point out, there is a threshold for which a programmer or company should not even blink at the cost of software. It's often the case that if the software they're buying saves one single hour of productivity, it's value-positive... and yet they won't buy it. Individual devs are notorious for refusing to pay a cent out…

Yes, I roughly agree with all of this. In fact, for most of my existence, I'm been one of those cheap programmers. The circumstances that led to me trying to push River for the next few months were somewhat accidental, and it felt like a good moment to at least make a go of trying to make it work. I'm not committing the rest of my career/life to any particular decision one way or the other. I'll reiterate too that I…

"one of those cheap programmers"

"one of those stingy programmers" might be clearer wrt this use of "cheap" meaning "tightwad" not "inexpensive"

Re: The minimum viable unit of saleable software

#36

Post by CrzyLngPwd »

I am forced to use jira soon as I was using BB issues and that is expiring soon.

So I'll build something simple for us, that integrates with our systems and how we like to do things.

It won't cost us much since our meagre requirements are nothing comparted to a full fledged Jira replacement.

Without LLMs it would have taken maybe a couple of days effort and perhaps an hour a month to fix any bugs we miss or add an extra overlooked feature.

With LLMs ... we shall see.

We won't set out to solve all of the world's issue tracking problems, so that will save a lot of time.

KISS is the goal.

Re: The minimum viable unit of saleable software

#37

Post by bze12 »

“Build vs buy” assumes that there are only two parties. If it’s easier to build internally, then it’s easier for a 3rd party competitor to enter the market and bid the price down. I think the "zone of viability" is real, it just narrows and shifts downward.

The author hints at this in a footnote: > It does, however, pencil out to use a different product instead. In this particular case, it’s easy: use Linear instead of Jira.

Re: The minimum viable unit of saleable software

#38

Post by xyzzy_plugh »

piterrro wrote: post #12

Good luck on your new endeavour! Selling to devs is hard, did you consider building in public? That would def help get traction imo. Your point about considering API design and overall architecture would definitely differentiate among the all AI slop out there

What evidence is there that building in public has any impact in traction?

I know a founder who has been building in public and it has had zero impact on his inbound.

Re: The minimum viable unit of saleable software

#40

Post by woadwarrior01 »

ahamilton454 wrote: post #20
galaxyLogic wrote: post #19

Earlier quoted context omitted.

I find myself fixing the spec of my software often, and that makes lots of existing code obsolete. Creating working code is getting cheaper with AI, but creating great specs which make the software easy and intuitive to use seems to be more difficult for AI. Why? Because you have to actually use the product to discover what is wrong, or sub-optimal, with it.

Yeah exactly, I literally don’t know how to change my spec until I’ve gathered more data. I was building a transaction classifier recently and I initially thought it would be a trivial “solved” problem. Throw transactions into a tiny local LLM, let it classify. But that approach was too slow, and not accurate enough. I didn’t know that though until I tried and then needed to change the spec.

You'd probably get much further along by fine tuning a small BERT style encoder model based classifier for it. IMO, even something as simple as training a linear classifier on the CLS token embeddings from a frozen encoder might work.
Post reply on HN