You're Paying Frontier Prices for Questions With Four Possible Answers
Most of what an AI product does is boring structured work, not thinking, and the person building your MVP is quietly deciding which is which
When I was building FlipSmrt, I had a flow that took a listing and decided whether it was worth buying and reselling. It worked. It was also slow enough that I stopped using my own product, which is the most damning review software can get.
So I sat down and listed every model call in that flow. Most of them were not thinking about anything. One was deciding whether the input was a listing or a search query. One was pulling a price and a condition out of messy text. One was picking a category from a fixed set. One was checking whether a description mentioned damage. Exactly two steps in the whole chain involved actual judgment, the kind where a smarter model gives you a genuinely better answer.
Every single one of those calls was going to the biggest, slowest model I had access to. Not because I decided that. Because that was the default, and I never revisited it.
The news that makes this worth writing about
Last week the team at Typesafe announced a new class of models they're calling System One Models, along with the first one, Jev. The claim is that on fast, structured decisions, it matches large language models on quality while being roughly two orders of magnitude faster and cheaper, and that it's constrained so it cannot produce an invalid output.
I haven't used it. It went into early access days ago and I'm not going to pretend otherwise. But I've been building around this exact gap for years, and I want to be clear about why it matters to you, because it is not "a cheaper model came out."
The name is borrowed from Kahneman. System One is the fast, automatic response. System Two is the slow, deliberate reasoning. The uncomfortable truth about most AI products is that somewhere between 80% and 90% of what they do is System One work. Route this request. Extract these five fields. Pick one of four labels. Decide whether this is a complaint or a question. None of that requires a model that can write an essay about Kant.
What "our product uses AI" actually buys you
When you commission an MVP, you get one number for cost, one for timeline, and if you're lucky, a vague sense that it'll feel snappy. What you do not get is the call inventory. Nobody hands you the list of "here are the eleven places this product asks a model something, and here's which model each one goes to and why."
That list is the product. Whether your app feels instant or sluggish, whether your per-user cost is a rounding error or the thing that eats your margin, is decided entirely by who made those eleven choices and whether they thought about them individually or once, at the top, and then copied it down.
Latency is the part founders feel first. Every call in a chain adds its delay to the total. If you have eight steps and each takes a second and a half, your user waits twelve seconds and leaves. If six of those steps are classification work that could return in milliseconds, the same product answers in three. Same features, same model quality where it counts, completely different product.
Cost is the part that shows up later and hurts longer. I spent six years as CTO at a company that went from pre-revenue to 10M monthly active users. At that scale, unit economics stop being a spreadsheet exercise and start being a feature-killer. We shipped things that users liked and then removed them, not because they didn't work, but because the cost per user made the whole business worse. That decision is brutal and it always arrives too late to be cheap.
You are making the same decision right now, at a hundred users instead of ten million, and it costs almost nothing to get it right today.
The part that's genuinely new
There's a second thing in that announcement worth more than the speed, and it's the constrained output. A model that is structurally incapable of returning something outside the allowed set of answers is not the same as a model that is very good at following instructions.
I've written a lot of defensive code in my career whose only purpose was to handle a large model returning "Category: Electronics (though it could arguably be Home Goods)" when the system needed the literal string electronics. Retries, validators, fallback parsers, alerts when the parser fails. That's real engineering time spent babysitting a model that was never designed to be a component in a pipeline.
If a class of models exists that simply cannot do that, a meaningful chunk of the glue code in your product stops needing to exist. That's not a cost saving. That's less surface area to break at 2am.
What you should actually do with this
Don't go swap models. You don't have the context to make that call and you shouldn't try.
Do ask for the inventory. Ask whoever is building your product, contractor, agency, or first engineering hire, for a list of every place the product calls a model, what each call is deciding, and which ones genuinely need a reasoning model. Then ask why for each one.
What you're testing is not their model knowledge. It's whether they think about your product as a system with distinct parts that have distinct requirements, or as one big pipe that everything flows through. The first kind of engineer will have the answer half-written already and will be a little annoyed you asked before they got to it. The second kind will tell you the big model is better at everything, which is true in the same way that a freight truck is better at carrying things than a bicycle.
That distinction is the single most useful signal I know of for evaluating a technical hire when you can't read code yourself. It shows up in a fifteen-minute conversation and it predicts about six months of your burn rate.
When I scope a fixed-scope MVP at $14,500, that inventory is part of the work, not an optimization pass we promise to do later. Later is when you have users and no time.
Your product doesn't need to be smart everywhere. It needs to be smart in the two or three places where smart is the product, and fast and cheap everywhere else. If nobody on your team has drawn that line, it's been drawn for you by whoever typed the first API call.