Pick The Technology After The Problem, Not Before

What Everyone Says

Build on LLMs. That's where the capability is, that's where the funding is, and that's what buyers are asking for by name. Start with the model, find a workflow to wrap around it, ship in weeks instead of years.

It feels like the safe path because everyone credible is on it. The infrastructure is there, the demos are magic, and nobody gets criticised for building with the thing every other founder is building with.

Why That's Wrong

Felix Hoffmann's read: "I almost feel like all founders are digging in the same part. I don't know why they're digging their grave... I feel like almost all of them are building a wrapper, more or less."

He's blunt about who benefits from the framing. On the claim that SaaS is dead: "this is something that obviously OpenAI and Anthropic want you to believe. And of course they want you to build with their products and that's why they're saying these things, but it's just not true."

The hidden assumption is that the technology choice is settled before you've looked at the problem. Felix inverts it: "You should think about okay, what is the customer problem and then when you know that problem, you should think about what is the best solution for that problem and not know that you want to use LLMs in the first place as a solution."

And the window has closed anyway. "The wrappers, they were super successful, like Lovable... because they were the first ones to do that, but now it's almost exactly the opposite. If you're now building a wrapper, now it's already far too late."

What Felix Did Instead

7Learnings has been an AI company since well before ChatGPT. The product forecasts demand for each product at each price, then sets the price that hits the retailer's goal. It's predictive machine learning, and it has no LLM in the decision.

That isn't nostalgia. It's three requirements the category imposes: "in enterprise decision automation, there's a lot of things that has to be deterministic, has to be kind of cheap, it has to be accurate. And for these reasons alone, these three reasons, [LLMs] don't make sense for something like pricing or marketing optimization."

Add a fourth, which is the one enterprise buyers actually raise: "if you're automating a decision, you have to explain why you come to that conclusion... nobody knows why LLMs do what they do."

His architecture answers it. The model predicts a checkable intermediate layer, not the answer. "We're not predicting the next word of the answer. We are predicting an in between step like data, raw data, which you can check up on. We're predicting sales and you can check the sales on the next day."

Result: 10 customers to their first $1M ARR, and a 13% profit uplift in an early customer test.

The Principle Underneath

This isn't anti-LLM. Felix is explicit: "I'm not against LMs, not at all. They're great. They're also making my company more productive." He expects LLMs to improve parts of the prediction over time.

The principle is that some decisions have hard constraints, and the constraints pick the technology. Determinism, cost per call, accuracy, and explainability are not preferences. If your buyer needs the same answer twice, or has to justify it to a finance team, generation is the wrong layer.

His forecast for the category: "every software will use LLMs to some extent... It's not like LLMs will replace software. All software will use LLMs."

Should You Do This?

Do this if your product makes a repeated decision the customer must be able to audit, at a volume where per-call cost matters.

Skip it if the output is language, or the user is in the loop every time and inconsistency is survivable.

The question to ask: would my customer accept a different answer tomorrow for the same input? If no, the decision layer can't be generative, whatever you wrap around it.