Top
Best
New

Posted by brandur 2 days ago

The minimum viable unit of saleable software(brandur.org)
214 points | 79 commentspage 2
stevenjgarner 2 days ago|
I think this is a well thought out understanding of your specific snapshot in time. However these are indeed exponential times. It may be more realistic to do your calculus on time shifting assumptions, especially given how clear you are about the development time and life cycle of the product.
ChrisMarshallNY 2 days ago||
> the internet’s most wretched hive of engagement farmers and master solicitors of fake information and fictional anecdotes, LinkedIn

Great quote!

mattas 2 days ago|
Ahem. "AI-powered engagement farmers..."
gherkinnn 2 days ago||
> 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.

kwdev 21 hours ago||
It sounds a bit like people are trending to the software version of sustenance farming not realizing that what drove society forward is compounding impact efficiency.

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.

deftio 2 days ago||
Truly agree with the framing of buy vs build.

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.

butlike 22 hours ago||
To be fair, the masthead image gives it away before the article even starts: the minimum viable unit of saleable software should be that it's peaceful to explore.

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

_pdp_ 2 days ago||
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.

drchaim 2 days ago||
Brandur of course knows more than me, and his framing sounds correct. I would be worried about whether the TAM of Go + Postgres is enough for business sustainability, but that says probably more about my fears than the reality in this huge market called “internet”
CrzyLngPwd 2 days ago||
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.

dotancohen 2 days ago|
If your choices are "use Jira" vs. "build task management software with an LLM" then you are already in a losing proposition. Go spend some time with Redmine before building your own. Redmine is free, far better than Jira, and already includes the features you don't yet realize you need.
danvayn 21 hours ago||
Yeah, it’s a false dichotomy. Ironically, even in the advent of LLMs very little has changed here. An off the shelf solution to a problem has always usually been better than building it yourself most of the time. People just think it’s easier to build now, and it is. But that doesn’t mean it’s the efficient choice.
jwitchel 2 days ago|
I recently asked Claude to duplicate Google Docs. It practically threw up. I tried to have it write a plan, decompose it, deobfuscate it.

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.

gobdovan 2 days ago|
I'm not sure I'm following you. What does 'duplicate Google Docs' mean? We already have OSS rich text editor (ProseMirror) and CRDT implementations (yjs, automerge). Are you talking about replicating every single enterprise Docs has? Integration with a large suite of other services you control? Replicating the business model too?

'duplicate Google Docs' spans everything from providing the actual service to replicating the world and becoming Google.

jwitchel 2 days ago||
I was looking for a dead on feature for feature exact replica including look and feel. You are 100% correct there are some excellent tools and libraries that duplicate most (all?) of the features. But I was playing around with the idea of what it would take for a perfect replica (for science of course). Turns out it's really hard even if you jump start it with those libraries and an existing reference implementation.

That was the point of my comment... Robust commercial software is hard.

More comments...