What we learned putting three AI products into production

We did not wait for a client to buy an AI feature. We shipped three of our own: HindaAI, HaljasVaade and CmdBrief. The prompts were the easy part. The parts that decided whether the products stayed on were evaluation, cost ceilings, and an honest sentence about what the output is not.

This is the note we would have wanted to read before building the first one.

Three products, three different jobs

HindaAI takes an Estonian address and returns a property snapshot: a score, a matched building, and the first signals an owner or buyer can act on. It is a statistical estimate, not a certified appraisal.

HaljasVaade takes a photo of a garden, terrace or balcony and generates restyles you can compare and save. It is sold as prepaid design packs on iOS and Android, without a subscription.

CmdBrief is a native macOS workspace for technical founders running Claude Code and Codex across several products. Repositories stay on the Mac. The product's job is to show which agent is working, blocked, or waiting — and to keep privileged actions visible.

None of these is a chatbot bolted onto a brochure site. Each one has users who will notice if the model is slow, wrong, or expensive.

HindaAI: the model is not allowed to run first

Estonia publishes a lot of property data. The problem is not scarcity. It is that the data lives in different registers, in different shapes, and none of them is a prompt.

The product therefore starts with an address match against the building register. If the building is not confirmed, there is no score. That is the evaluation gate. Running a model against the wrong object is not a quality problem you can fix later with a nicer prompt. It is a wrong product.

The public methodology exists for the same reason. The score is a five-part figure from 0 to 100, assembled from official and open sources — cadastre, the building register, energy labels, environmental layers, transport. Users can see what went into it. They can also see the limit: this is not an EVS 875 appraisal, not legal advice, and not a document a bank will accept instead of a certified valuer.

That sentence is a product feature. A property tool that pretends to replace the formal process will be distrusted the first time someone takes it to a lender. A tool that says it is a filter — useful before you spend money on the next step — can stay in production.

Cost follows the same rule. You do not want to discover the invoice after a weekend of unmatched addresses. The expensive work is gated on a confirmed building, and the guest flow is one snapshot, not an open tab against every listing in the country.

HaljasVaade: a picture that looks finished is not a garden

Image generation is easy to demo and easy to over-promise. A photorealistic terrace on a Tuesday afternoon will look like a finished project. It is not. It is a visualisation of a photo the user already had.

Two constraints had to ship with the first version, not after launch.

The first is cost. HaljasVaade sells prepaid packs. Unused designs do not expire. That is a cost ceiling the user can see: each generation is one credit, not a surprise on a subscription. It is also a cost ceiling for us. Unlimited "just one more style" is how image products quietly lose money.

The second is the data boundary. The photo is the user's. The product has to treat it as such — store it because the project needs it, delete it when they ask, and not train a public story on someone else's backyard. Garden photos are still personal data.

The copy on the store listing has to stay as conservative as the HindaAI methodology page. Nordic calm, natural planting, modern minimalism: those are styles. They are not a bill of quantities, a plant list that will survive an Estonian winter, or a contractor's drawing. If the product forgets that, people will plant from a generated image and blame the app when the soil is wrong.

CmdBrief: the product is the permission boundary

CmdBrief exists because agent work made building faster and made context worse. A founder running several products does not have a single coding session. They have one agent waiting for approval, another writing docs, a third sitting on a failed test, and a browser tab that belongs to a different product.

The wrong design would have been to send the repositories to a cloud IDE and call it supervision. CmdBrief is local-first: a Rust app with a real terminal underneath, no analytics, no telemetry. It contacts cmdbrief.com to check the subscription. Agent CLIs reach their providers only when the user runs them.

What the product actually sells is the boundary. Shared workspaces demote auto-run commands so an imported layout cannot silently execute. Privileged actions wait for confirmation in the app. Session browsing uses local metadata and short previews, not full transcripts uploaded somewhere else.

That is the same scaffolding we insist on in client work, applied to our own agent stack: fallbacks (a terminal that still works if an agent dies), cost (provider usage windows, visible, not discovered on a card), and evaluation (status that comes from hooks and process liveness, not from guessing at a spinner).

What we now treat as policy

Three rules survived contact with production.

1. The data boundary is decided before the model runs. HindaAI will not score an unmatched building. CmdBrief will not become a cloud copy of your git history. HaljasVaade will not treat a garden photo as training material by default.

2. The cost ceiling is in the product. Prepaid credits, a guest snapshot, a usage meter next to the agent — not an invoice two weeks later.

3. Say what the output is not. A statistical property estimate is not an appraisal. A generated garden is not a construction drawing. An agent workspace is not a replacement for judgement. Products that skip this sentence get switched off, or worse.

We still start client work with a written assessment, and we still say no when a deterministic system is cheaper. Shipping our own products did not weaken that. It made the reasons specific.

If you are deciding whether to put a language-model feature in front of paying users, the question is not which model is currently winning a leaderboard. It is whether you can tell, in writing, what happens when it is wrong.