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.

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.

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.

> 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.

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.

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.

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!

That's funny, the first thing every LLM I use generally does is install a bunch of third party packages...

Great quote!

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.

I don’t think I can take the author seriously after this claim. They must be a beginner when it comes to AI coding. And I’m not advocating vibe yolo coding either.

On the other hand, if someone has a $400/mo Jira bill that means at least 40 users, so $400/month seems like a distraction compared to total comp.

But again, it takes just one SDE to spend a weekend replacing it. That SDE probably has strong opinions on why Jira doesn’t work for them, and strong opinions on what a task system looks like in an AI world. In this world, I’d say Jira is the risk, regardless of its monthly cost.

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.

He, the CEO, saw this as saving $40K per year. Until I asked simple questions:

What happens when Joe leaves?

When he goes on vacation?

If he has a health emergency?

The LLM isn't going to magically maintain the software, evolve, fix or support it.

What are you going to do?

The obvious conclusion was that he likely had to hire another person to work with Joe on this in-house CRM and, at a minimum, have redundant project ownership. Backup for development, maintenance and support.

The easy conclusion was: This will save him $40K a year until he decides to hire another person, at which point this "free" software will cost him $150K per year, $110K/year more than what he was paying Salesforce. If he does not hire a second person to work in the internal CRM, he might get lucky and things could be fine for a few years or he will have to face a crisis at some point when Joe is no longer around and nobody knows the first thing about his mini-CRM, not even the LLM.

I wonder how many people are falling for this trap these days. The allure of zero-cost software vs. the reality of introducing risk, technical debt and organizational risk.

To be sure, we are using LLM's extensively. However, until this is better understood, in the realm of software development it is constrained to what I would call "advanced auto complete" at the file level rather than anything resembling project-wide work. When we do write full applications, they are often relatively trivial internal tools that a person could complete in not much more than one week. In other words, easy to understand and code if another engineer had to jump in and none of these utilities are mission critical.

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.

Sure everyone could build their own XYZ with AI, but unless that has comparable economies of scale, everyone really doing so is gonna set us back. imho.

Once you get people using your software, you have people using your software.

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.

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.

- 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.

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

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%+.