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%+.
The minimum viable unit of saleable software
61–70 of 89 posts
Re: The minimum viable unit of saleable software
#62- 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
#63Re: The minimum viable unit of saleable software
#64Good 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
#65I 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…
Re: The minimum viable unit of saleable software
#66> 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> 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...
Re: The minimum viable unit of saleable software
#68I 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
#69Every 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.