--- title: "Anyone can buy the model. Knowing which work to remove is rare." url: "https://simonebova.com/en/writing/il-modello-e-una-commodity" lang: "en" updated: "2026-09-29" author: Simone Bova alternates: it: "https://simonebova.com/md/it/writing/il-modello-e-una-commodity" en: "https://simonebova.com/md/en/writing/il-modello-e-una-commodity" pl: "https://simonebova.com/md/pl/writing/il-modello-e-una-commodity" --- # Anyone can buy the model. Knowing which work to remove is rare. 2026-09-29 · Method Anyone can use a frontier model. The edge is knowing which work to remove, which judgment to leave with the expert, and how to prove the result. Cases from Lia and CVing. In an earlier version of this piece I wrote that model quality is a non-issue and that when an agent fails, the flaw is always in the design. That went too far. I spend my days deciding which model does what, so I can't stand behind it. The version I stand behind now is narrower: anyone can get access to a frontier model, and the rare part is knowing which work to take off a person's plate, which judgment to leave with them, and how to prove the result holds up over time. I learned it in discovery with condominium administrators for Lia, Yempik's product for property management offices, and while building CVing's WhatsApp agent. ## People asking for completeness often want a different job gone Lia shipped without accounting, on purpose. The objection kept coming back, and once we wrote it down word for word: “se io uso un gestionale senza la parte contabile, lo uso a metà”. If I use a management system without the accounting part, I'm only using half of it. Read that way, it looked like a clear roadmap instruction. So we asked the question differently, to two administrators who don't know each other, in different cities: what makes you swear in the morning? Both put accounting last, and both explained why without being asked. The first: “Non è la parte contabile. Il problema è la parte pratica, quindi tutti gli interventi.” It's not the accounting, it's the practical side, all the interventions. The second: once invoices are recorded properly, any software can do the accounting. The objection was about features. It predicts well what a buyer says when comparing two products on paper, and badly what they'd pay to have fixed. We decided operations before accounting: cases and suppliers, email, WhatsApp, and spotting owners in arrears with approved reminders. The most-wanted value sat next to a huge subsystem, and delivering it didn't require rebuilding that subsystem. Two conversations don't make a market law. They're enough to avoid building the wrong part first. ## The most useful question is the one about the impossible Experts ask for the features they think they can have. The big value usually sits in what they don't say, because they're so used to the old system that some things are no longer up for discussion. That's why I ask the same question at every first meeting, written like this in my notes: > what's the one thing that would be so cool to have/that would change your life but that we did not even mention because it is impossible? I ask it before showing what my stack can do, because after a demo the answers shrink to whatever you just showed. Then I investigate the answer properly, and at the table I promise nothing. ## Before looking for a better model, look for an input that carries its own context In a Lia discovery session we were talking about suppliers who send photos of their jobs over WhatsApp. The idea on the table was as AI-native as it gets: the AI looks at the photo and works out which building and which job it's about. I proposed the opposite route, far less sexy: send the supplier a link tied to that job, where they upload the photos, which land straight in the right case. “Senza che il fornitore debba imparare a utilizzare il gestionale”, without the supplier having to learn the management software. The link removes the problem instead of asking the model to solve it. It's still a proposal, with open details on how it expires and how it's protected. It applies everywhere: before improving extraction or reasoning, ask whether the request can be born already tied to the right record. ## Some human gates stay even when the model is right When we described automatic payment reminders, one administrator stopped us. With some owners he has unwritten agreements on when and how they pay. An automatic reminder, accurate and on time, sent to one of those people can end a relationship worth far more than the reminder. In my notes from that call I wrote: “fare solleciti alla gente giusta, non sbagliata”, send reminders to the right people, not the wrong ones. The other administrator wanted the same confirmation screen for the opposite reason: his payment collection system sometimes loses payments, so the data can be wrong. His gate depends on data quality, and it can loosen as the data improves. The first depends on a relationship, and it stays, because that agreement will never live in a database field. The ones protecting a relationship should be made fast: a ready list and one confirmation per row. ## Keep the expert's standard and change the steps An expert's established practices are two things at once: habits, and the way they guarantee quality today. Automate them as they are and you copy the org chart. Throw them out and you lose the quality. I redesign from scratch in what I call “ignorant mode”: I ignore the existing process and start from one constraint, “this must be done by a single person with these AI tools”. The expert's standard stays the bar I accept the result against. The expert matters more than before this way, in a different role. They sign off on the standards, bring accepted examples and unacceptable failures, and update everything when the domain changes. That signature is what separates a reproducible deliverable from winning the token lottery. If your human in the loop is someone correcting every output, you have a review queue dressed up as a system. Collect examples and criteria, build evals, and measure how often the result repeats. Code works the same way: a person reading every diff is a review queue too ([here](https://simonebova.com/en/writing/nessuno-legge-ogni-riga)). ## The minimum product is a closed loop, even outside your product We defined Lia's first unit of value step by step: import a real building, receive an email, work out who's writing and about which building, open or update the case, draft the reply, ask for approval, record the outcome. There's one adoption test: does the office want to move the other buildings it manages onto Lia too? An office working with Lia on its real data pointed out a problem no demo would have shown. An email handled inside Lia still sat unread in Gmail. Their line: “o lavoriamo su CRM o lavoriamo su Gmail. Non puoi lavorare su entrambi”, either we work in the CRM or we work in Gmail, you can't work in both. The replies were fine, but the product had created a second inbox to watch: more work, the opposite of the promise. “Done” has to be defined in the system the operator still relies on, and tested along the whole flow. The same loop has to survive migration. Whoever switches software moves buildings one at a time, retrains colleagues and works with partial exports. Map how a customer moves before assuming everything changes in a day. ## The objection: so the model doesn't matter The strongest objection targets my old version: if the model is a commodity, take the cheapest and be done with it. Model capability is still a constraint to test. CVing's WhatsApp agent started on a small, cheap model, and the following month it ran on a more capable one. It swaps without touching the code, and that swap point is the right part of the commodity argument. I didn't measure before and after in isolation, so I credit no improvement to that switch. My order: first check data, tools, state and instructions; then test whether the model can carry the task; keep the provider swappable and ask for evidence before accepting a swap. ## From Monday - Ask customers to rank their concrete frustrations, and separate “I expect it to be there” from “I need this solved”. - Ask the question about the impossible before the demo. - Before improving extraction, try tying the input to the record. - For every human gate, write down why it exists: uncertain data or a relationship. Shrink the first kind, make the second fast. - Define “done” in the system the operator still uses, and test it along the whole flow. - Keep the model swappable and test every switch on the real task. [simone@yempik.ai](mailto:simone@yempik.ai) · [Book a call](https://calendar.app.google/LKDrQPKGV2EAFCMN9)