Live data from Hacker News

The minimum viable unit of saleable software

brandur.org

61–70 of 89 posts

Re: The minimum viable unit of saleable software

#61
There's another dimension to the Salesforce CRM "build" argument; which is to reduce your 25 seats down to 5, and expend Eng resources to building "agents" to automate many recurring data-entry CRM tasks.

This is also the reason the stock has hit a 3-year low. Not because CRM can be replaced entirely. But because the seat count can be reduced 50%+.

Re: The minimum viable unit of saleable software

#62
I feel like my HN comments fall now into 3 categories :

- free software exists since the 80s, having software that costs literally 0, not even being "very cheap" is NOT new

- Goodhart's law where we get a new KPI only to make the entire process and ecosystem around it pointless

- the rest (but it's rare)

so... yeah this one is option #1.

Re: The minimum viable unit of saleable software

#64

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.

[flagged]

Re: The minimum viable unit of saleable software

#65
post #16

I have multiple side projects that I would never have contemplated building before but whose utility now exceeds the much lower cost to build. I got a few weeks in to each and then stalled on all of them because the effort and motivation required to extend beyond the crazed early days _is_ still more than the utility I get. In a professional context, paying someone for software to do something outside my core domain…

I've been surprised by how far my motivation has taken me. I have multiple projects now that are so much further ahead than I have ever managed before. I would get stuck on some small issue or key-decision and then would struggle to move past it. Certainly, I still have those tendencies, but it's easier than ever to push through and build a throwaway version with code that might not be what I end up shipping, but is…

To be clear these projects made it way further than they could have without AI. But any blocker that takes me out of the flow can easily become the thing that ends it. Not even necessarily because it’s a difficult problem, but just because I’m no longer getting that AI high.

Re: The minimum viable unit of saleable software

#66
I feel like the build threshold discussed is _extremely_ optimistic?

> But does that always hold true? Let’s take the other side for a second by examining a much higher-priced SaaS product. Gemini reports that the price of a fully loaded Salesforce seat is ~$500/mo. Say you need 50 seats, that’s $25k/mo!

> For that price you could have 1.5x engineering resources (25 / 16.7) working on your clone full time. Once again, a CRM’s a reasonably complex piece of software and a rebuild wouldn’t be trivial, but no matter how you construe it, this is closer to a “build” decision, even for a smaller company. (And with Salesforce down 30% YTD, the markets seem to believe it too.)

If $25k for salesforce is too much, my view is that your first thought should be to look for a cheaper competitor, not build a thing?

Ok, you vibed your own. Great! Now you need custom integrations for everything, you can't hire out of the market, you have to re-train everyone and all new starters, you have an extra thing to HA, monitor, back up etc. People can't google for answers about it anymore. This is before we can talk about what it actually costs in terms of bikeshedding, roadmap creation, project management, product management etc etc. Plus compliance, security, your org policies and relevant regulations if you're storing personal information. Think of how many meetings it would take to get this done, the political costs, and how much it costs to get consensus in big companies.

There is also RISK. Nobody is gonna get fired for choosing SalesForce, but there are many different angles by which building an in-house solution for something considered commodity (tho an expensive one) can go horribly wrong.

The more subtle cost is _brain space_. Human engineers have context limits too; switching projects has costs, and you can't put ONE engineer on the thing and expect it to be sustainable. You need about a minimum of four people to understand anything you expect to maintain and operate long term.

Your org's capacity for engineering focus is precious and IMHO you should try really hard not to use it on non-core stuff unless you have to.

Re: The minimum viable unit of saleable software

#67
post #51

> Are you crazy?! Anything you ship can be instantly displaced by an internal package built by an LLM! That's funny, the first thing every LLM I use generally does is install a bunch of third party packages...

Too bad there is absolutely no way of steering the output and it's a completely random slot machine, as so thoughtfully explained by lots of people lots of time, who for sure know what they are talking about.

Re: The minimum viable unit of saleable software

#68
> One user there posted about how his company had been spending $400/mo on Atlassian’s Jira. He’d felt personally slighted by this outrageous bill, so he’d had his team build a new internal task tracker using Claude.

I dislike Jira as much as anyone but these anecdotes are far removed from what I've experienced. Opus 4.8 continues to trip itself up over trivialities that go beyond one-shotting a most basic CRUD app, let alone implementing something complex you yourself don't understand.

Re: The minimum viable unit of saleable software

#69
Actually the math is worse.

Every new line increases dramatically the complexity of the software which requires more cost and most maintenance. If you stop at a single tool this is still manageable.

Imagine now that you do the same for 10 other products - all critical systems. You will end up running the tools to save on imaginary money. Even then, software vendors can simply undercut and offer the software cheaper because they use agents too.

So building everything in-house is not the right way to go unless you have no other option - which was always the case pre coding assistants.

If you ask engineers of course they will say yes. It is yet another nice toy project and interesting challenge. But decision makers need to learn to say no - more often they used to.

Re: The minimum viable unit of saleable software

#70
This is quite an interesting one to me because dotnet has a couple of job queues, with hangfire (hangfire.io) probably being the main one. I've used hangfire for years and it's OK, but it was lacking a few critical features for the current project I'm working on. I've tried extending hangfire before and it's quite unpleasant to work with, so I decided to go down the LLM build route https://github.com/hackf5/sheddueller. It took about a week to build the service that did everything I need. The code is good enough and it was definitely the right choice. The real benefit is that I can add any features that I need and make it work in harmony with the main project.
Post reply on HN