News for hackers. Stuff that matters.

kbiessy

I also think the trend will be to bill per solved ticket (many are starting to offer this), and thus based on the outcome. But I also have a hard time with pricing that isn’t clear, such as “~XXX Resolutions/month.” I don’t have a solution at all, but from a customer’s perspective, I’d be pretty cautious. If there’s one area where I’m not a fan of approximations, it’s definitely pricing. Maybe the future will prove me wrong, and people will be comfortable with it.
Nice game, I like the idea. And the UI is pleasant. Just a comment, it might be nice to be able to skip a question that you're sure you don't know the answer to.
Re:Bad ideas that aren't bad anymore on Thursday November 12, 2026 @08:44AM (#50466976)
I fully agree that there are maintenance risks when you buy software, but imho, those risks are much much more easier to mitigate: buy only "mature" software, make sure that maintenance is governed by contract, know your path to reversibility, etc.

Ultimately, in my opinion, this “make or buy” issue goes back to the age-old debate about how companies choose to adapt to the processes already built into the software they purchase. The companies that will “make” are probably the ones that would have developed custom solutions at some point anyway.

Re:Why aren't we shipping faster now? on Thursday November 12, 2026 @05:32AM (#50465371)
Places where this gets stuck: IT services firms. I work for a software vendor that only sells through them, and most of them still bill by the day (at least in Europe).

For a service firm billing days, cutting the team in half because the shipping pace is the same would clearly breaks the business. So nobody there is in a hurry to measure outcomes, and the client’s procurement team compares day rates anyway. At least up to now.

Re:Bad ideas that aren't bad anymore on Thursday November 12, 2026 @05:00AM (#50465170)
I'm going to talk about the item on this list that I know best. The "building instead of buying" is the one I’d question.

The cost of writing the tool is mostly gone, on that I agree. The cost of owning it hasn’t moved that much I think. If I look after the software stack of a couple of small companies I know, the custom tools are those that end up hurting the most. Nobody remembers it was custom made, until the API call breaks, or the person who built it leaves. I think the cost of maintenance is particularly high.

An afternoon build doesn’t fix long terme maintenance, nor does it provide functional knowledge. I think generalists stand to gain a lot from AI, but there will still be a huge role for experts to guide and maintain software in the future.