The customer paid to build the product herself

Jesus moo — Sun, 17 May 2026 20:26:25 +0000

Marta opened a laptop on her clinic's front desk and turned the screen toward me. The interface wasn't QVET. It wasn't Panther. It wasn't anything I had researched the week before. She had paid a developer to build it from scratch, because nothing on the market did what she needed.

I'm a software engineer based in Guadalajara, and for the last two sprints I've been trying to validate a B2B SaaS for independent veterinary clinics, one to three doctors, sometimes with a groomer in the back, sometimes with a small hospital, often all three under one roof. I started with cold DMs on Instagram and WhatsApp. Seven sent, zero answered. So I switched to physical visits: walk in, ask to speak to the owner or lead vet for ten minutes, no pitch because I have nothing to pitch. In two weeks I visited 16 clinics, had 8 to 10 real conversations, and 3 vets agreed to follow-up calls. My starting hypothesis was that small clinics handle appointment reminders manually and that a meaningful fraction of returning patients miss their scheduled date. That turned out to be partially right, Marta's clinic runs at a 20% cancellation rate, the only hard no-show number i have, but it was wrong about which problem the software should solve first.

Marta runs the clinic with one doctor (herself), a receptionist, and a manager who handles operations. She tried QVET, the Spanish veterinary PIMS that has become dominant in Latin American chains and hospitals and abandoned it. Then she paid a developer to build her own system. When I asked her why, she gave four reasons specific enough that I want to write them down before I forget them.

First, commissions. In Mexico, when a vet treats a patient, that vet often earns a commission paid out at the end of the month or end of a cycle. The clinic's payroll model depends on it. QVET has no native concept of per-doctor commissions because the European labor structure doesn't work that way. Marta would have had to track them in a separate spreadsheet, which defeated the point of the software.

Second, the payment flow is reversed. The systems assume you generate the invoice before the service and cancel or amend it if the procedure doesn't happen. In Mexico the norm is the opposite perform the service first, charge after. Marta said the QVET flow felt backwards from day one and her staff kept making mistakes.

Third, no integration across clinic, grooming, and hospital. Mexican vet operations frequently combine these under one roof and customers care about a unified record per pet. QVET treats them as separate verticals.

Fourth, legal consent. Each procedure requires the animal's owner to sign consent before it happens. Marta's custom system automates the signature flow. QVET, in her experience, did not.

Marta was the most articulate case, but she wasn't an outlier. Three of the other clinics had also paid for software QVET, Panther, or something one owner called "Cubet" (which I couldn't verify as a real product; my best guess is QVET misremembered) and abandoned it within months or years. The complaints repeated: too many features they didn't need, reminder emails that bounced because their clients live on WhatsApp and don't read email, inventory entry one item at a time. One clinic had paid 6,000 MXN a year for the Spanish PIMS before quitting. Another had paid 20,000 MXN upfront for a Panther license, used it for one month, and abandoned it because everything was stored in uppercase and there was no way to search. They went back to Excel. One vet said it plainly: "I'd rather pay more once than keep paying monthly. I want the software to be mine."

Two products dominate this segment. QVET, a Spanish cloud SaaS, owns the chains and the larger clinics and Panther. Both miss the same gap: small clinics with one to three doctors, mixed services under one roof, commission-based labor. The clinics sophisticated enough to notice the gap solve it by building custom internal systems. Someone in the segment spent real money to build the product because no one would sell it to them. I don't know what a stronger validation signal looks like at N=16.

I'm not building anything yet. I want to get more vets before I commit to a wedge what exactly to start with, what to leave out, whether the right entry point is the commission engine, the payment flow, or something I haven't seen yet. The question I find more interesting right now isn't even about vets. It's this: if you're building B2B SaaS for non-US markets, where else have you seen this gap dominant international software at the top, local desktop software at the bottom, and a layer of small operators in the middle that nobody has actually built for?

The AI didn't break our backend. It just stopped lying for us.

Jesus moo — Fri, 24 Apr 2026 01:31:10 +0000

Our internal AI agent does in one prompt what used to take ten minutes of clicking through the UI. Users describe an outbound job in natural language, the agent talks to our MCPs, and the job gets built without anyone touching the UI. Jobs have a lifecycle: drafts are inert and editable, published jobs run, the whole point of draft is that nothing happens.

We were running a bug bash on it. The plan was hostile: prompt injection, role hijacking, capability probing, Break it. Find the edges, we wanted to know its limits better than anyone outside the team, that's how we'd figure out what was missing and where the product really stood.

After an hour of nothing, we flipped the question. Instead of trying to break it, why not just ask it to do its job? Someone typed: create a job with these settings. Nothing else. No publish step, just create.

The job landed in draft. We kept poking, then a log line said a task had executed against it. Tasks aren't supposed to execute on drafts, that's the whole point of the state. Probably noise, I thought, then a delivery from that job landed in my inbox, a real send to a real recipient. That's when "weird log" became "this is live in production."

A high-priority ticket landed on me. My first instinct was the one everyone has when something strange happens near an LLM: the AI did something it shouldn't. The UI version had been in customer hands for a long time without incidents. The only new variable was the model, so I went hunting there. RAG misconfiguration. MCP boundaries. Prompt injection. Roles and permissions. Tool encapsulation. Everything was clean. Nothing the agent touched should have been able to reach the queue that fired deliveries.

I burned about an hour before I ran out of hypotheses. Not a eureka, exhaustion. So I changed the question: what does the AI do differently from the UI? I diffed both payloads. One key was different: dispatch: { primary: true, secondary: true }. The UI never sent it on draft. The agent did, because it was reading the schema honestly. Downstream, a priority queue was watching that field, decided the job looked overdue, and fired it. Immediately. From a draft.

The fix was one line in the queue handler:

if (status === 'draft') return;

A guard that should have existed since day one. The bug had been dormant for a long time, waiting for any client other than our own UI to call the create endpoint with a schema-honest payload. The agent was the first one to do it. One conditional. That was the entire patch.

The agent didn't introduce the bug. It was the first client of our API that respected the schema instead of the unwritten rules our UI followed. Every API your frontend consumes is held together by conventions the backend doesn't enforce. State guards belong in the handler, not in the discipline of the caller. Trusting the frontend to keep quiet isn't a contract, it's a bet. How many other endpoints in your backend are still making it?

DEV Community: Jesus moo

The customer paid to build the product herself

The AI didn't break our backend. It just stopped lying for us.