Your customers are more irrational than you are, and your appeal to them will likely need to resonate with them on an emotional level rather than logical one. I would argue that marketing is the hardest part of entrepreneurship, by far.
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 believe we're still quite early in the LLM age and are still waiting for the other shoe to drop. All LLM-generated software feels free at the moment because it's still novel and the exhilaration of accomplishment when you build something complex inside of a few hours is addictive beyond words. However, within a year or two I think we're going to have a lot more software, all of which needs maintaining to some degree, and we're going to become a little more reluctant to generate new projects to add to the heap. This'll cause an adjustment back to a more compromise position.
(Also, could be completely wrong about all of that, so take it for what it is.)
"one of those stingy programmers" might be clearer wrt this use of "cheap" meaning "tightwad" not "inexpensive"
That said, I think the path Brandur is describing is well-trodden and proven out by projects like Sidekiq.
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.
This creates so many weird inefficiencies that I have seen an entire billion dollar companies analytics run on free google sheets + compute because they couldn't figure out what to use for five years.
Build a good product and they will come.
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.
Packed full of insightful comments that cut against the grain and are logical even if unpleasant to hear, delivered with kindness and a thoughtful, caring tone, and backed up with strong justification.
Did I mention delivered with kindness?
And it mirrors my experience. The struggle has me convinced that to sell anyone anything your offer has to be so overwhelmingly good they’d not just win from having it but lose from not having it. It’s why the slick salespeople of old would talk for minutes at you just to get you to buy a thing once - non stop talking attacking your objections from every angle before finally moving on to the price. Sure, as the person offering the thing you see the value - but your prospect just showed up to your site, they’ve got an Amazon purchase to finish on another tab, the baby is crying in the other room, and there’s an outage. Sorry - your thing does what again?
Acquiring new software is a major commitment beyond just the price tag. It means integration, continuous maintenance, dealing with forced UI updates, supply chain exposure, and so on.
Every seasoned dev (unless very lucky) has dealt with bad software acquisitions, almost all of which seemed to be great deals at the time of purchase.
Not to mention enshittification, predatory prices increases, the supplier getting bought out, etc. The list goes on...
It’s a bit funny because I felt this way before coding agents as well, like you could clone something in just a few weeks. But in practice my expectations are rarely accurate.
Why? Because you have to actually use the product to discover what is wrong, or sub-optimal, with it.
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.
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.
Almost everything integrates with SF today and most often understanding, replicating and maintaining these integration pathways may need more than 1.5 engineers. You then bring 3 engineers (to cover absences) and buy enough tokens.
And we haven't even scratched other parts: disaster recovery, security, legal (CCPA/GDPR), etc
I know a founder who has been building in public and it has had zero impact on his inbound.
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 is still the practical option compared to the motivation and effort needed to maintain another dependency.
> 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.
If you are looking to replicate the exact same feature set of an existing product - buying would almost always be a better choice.
But it's rare for avg customer needs to perfectly match product features. Most often they need 20-40% of the product + some custom, business specific logic that's missing and is later fixed with spreadsheets/integrations. In that case it depends on how mission critical this software is.
I'd say investing into the core software that runs your business might very well be worth the effort, even if it's 10x between build vs buy.
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.
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.
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.
That's funny, the first thing every LLM I use generally does is install a bunch of third party packages...
Great quote!
Also, some software businesses use a ton of aggregated or hard to get data which needs to be synthesized and that doesn't go away even if the llm driven coding is cheap.
- 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.
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.
It gave me all sorts of reasons why this was a terrible idea. I've never seen it resist a task so directly and relentlessly.
It knew.
One point worth considering is that tools like Jira and Salesforce have dozens of screens and modals. But you only ever look at one at a time. So the enormity of the ask "duplicate Jira" is hard to see in its totality.
With Google docs, the entirety of the tool is almost one screen. It resists decomposition. So the true gravity of the request is more in your face.
You say you want to duplicate Asana or Service Now or Jira or Zendesk? Great, here's the keys to the car, a tank of gas, and a quarter to call me on a payphone when you get there. Oh wait payphones don't exist anymore...but it doesn't matter because you're never getting there.
These software platforms are built by thousands of engineers over more than a decade of dedicated work. They are they way they are for reasons. To think someone can duplicate them with some clever prompting is to completely fail to understand the scale of the problem at hand.
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%+.
So many things I am completely capable of doing on my own I simply don’t want to. I have better things to do. More valuable things.
Yes, build versus buy. The eternal question!
If you are lucky to have talented staff on your payroll, they should put their hard work into things which increase business revenue and profit, not things which reduce expenses. Unless there's an expense which is outrageous.
If that engineer in the article example can build a Salesforce clone, then he can instead build more valuable software which the business can sell for a profit. It could be a Salesforce clone even.
