aitvini · journal

The pill nav, the scroll-driven walk-through, the language marquee, the timeline, the FAQ, the interactive chat demo at the top of §003 — all shipped. About got a deeper editorial pass. The favicon stopped being a Vercel triangle.

Two things drove the rebuild. First, the site needed to be the decisive place where a boutique business owner could read everything they need to know about aitvini in one sitting. Before, it required a follow-up conversation to fill the gaps. Now the page does the work itself.

Second, the chat preview in §003 was static — visitors read about how the chat worked but couldn't feel it. Now they can. Three suggestion chips, real Lumière responses streaming in character-by-character. No API call, no rate limiting; just a faithful demo of the felt experience.

The hardest call was what to do with “Their questions, by morning.” — it's a good line, but it doesn't tell a cold visitor what aitvini is. We moved it to the italic kicker below the new H1. Still on the page, just no longer the first ten words a stranger reads.

Next: this journal. So we can write down what we're doing as we do it. You're reading the first entry.

We thought about this a lot before changing it.

The old rule was reactive: if a customer asked whether they were talking to a bot, the chat would say yes. The new rule is the opposite. The first message of every conversation identifies the chat as the business's AI assistant, in whatever language the customer wrote in. The customer doesn't have to suspect anything to find out.

Three things forced the change. The realistic customer is a tourist scanning a QR code on a table; they've never seen a customer chat before; they assume they're talking to a server. They share what they'd share with a server — payment intent, dietary restrictions, sometimes more. Trust gets damaged when they later figure out it was a bot. Safety drops because they wouldn't have shared the same things with a bot they knew was a bot. And the EU AI Act mandates disclosure for commercial bots; California's SB-1001 already does. The QR code is in Batumi, not the EU, but the tourist is often an EU citizen protected by GDPR even when the operator is outside it.

So the chat says what it is. Plainly. In the customer's language. Before the conversation starts.

We thought we'd lose conversions. We didn't. Customers ask anyway, the way they always did. We just don't pretend they can't tell.

The chat handles the predictable, multilingual, after-hours questions that fill a receptionist's day without growing the business; the receptionist handles the in-person trust, the difficult conversations, the moments where being known matters more than being answered.

The temptation in 2026 is to make the chat pretend to be a person. We built it the opposite way — honest about being a chat from the first message — and the boutique businesses we work with prefer it that way.

The model literally cannot exceed it at the API layer.

250 fits about three sentences in any language we've tested — English, Russian, Georgian, Turkish — plus a markdown image URL on its own line, which we need because the chat sometimes recommends a catalog photo and a truncated URL is worse than no URL. Lower than 250, we risked breaking the URL mid-line. Higher, and the model started writing paragraphs. Paragraphs sound like an essay, not a conversation.

The companion rule in the system prompt: “Reply in 1–3 sentences. Never more than 3, in any language. This is a hard rule.” Sentence-based rules are language-neutral; the model counts boundaries (. ? !) regardless of whether it's writing in Russian or Georgian. We don't have to localize the rule per language.

Side effect: 774 tokens recovered from the old 1024 budget. That's a lot of conversation history a single reply no longer has to compete with.

You wouldn't think a number could be a design decision. This one is.

It's not a chatbot — chatbots are scripted. It's not a CRM — CRMs are databases. It's a customer surface plus an intelligence layer, built for businesses where every customer is supposed to feel like the only customer.

The owner sits with us; they tell us about the business in plain English — hours, prices, services, the things they specifically don't do, the things they wish people would stop asking; we turn that into the brain; we print the QR code; we put it on the front desk.

The chat is live the same afternoon. Anything we missed surfaces in the first day's customer conversations and lands in the next morning's brief.

The UI said “dish” and “menu” everywhere — because the first pilot was Lumière, a restaurant, and the product was shaped by the business we worked with day to day.

Then we onboarded the first clinic. A dermatology studio doesn't have a “dish.” It has a treatment. A hotel doesn't have a “menu.” It has a room list. The catalog still worked technically — the database doesn't care what we call a row — but the words in the interface lied to the owner. The dental practice opened the app and saw “Add a dish.” Nobody types that and feels at home.

We pulled the restaurant vocabulary out and made it configurable. Each business sets its own section name and item noun at setup. The dental clinic types “treatment.” The hotel types “room.” The restaurant still types “dish.” The product stops pretending to be a restaurant tool while staying native to a restaurant.

This is a small change that taught us a big rule. Build the abstraction at the moment the second customer asks for the wrong vocabulary, not the first. The first customer's words are not the product's words. The product's words emerge when the second customer's words refuse to match the first's.

We caught it at customer two. If we'd hardcoded another month, the cost of pulling “dish” out would have been doubled by every screen that learned to say it.

The city is. A customer at a restaurant writes in Russian; their friend writes the same restaurant in Georgian; the booking confirmation goes out in English because that's the lingua franca.

Most software made elsewhere assumes English-first with a Spanish toggle and breaks here. We built aitvini so the chat replies in whichever language the customer wrote in, on the first message, without configuration, without the owner switching modes, without “we also speak…” disclaimers on the placard.

It summarizes the previous day's customer conversations in twelve to twenty lines: the patterns, the gaps, the high-intent leads, the things the brain didn't know and now does.

A boutique restaurant owner reading their first brief messaged us back twenty minutes later: “Why didn't I know my customers were asking about Saperavi twice as much as my Italian whites?” That's the brief. Less a report than a research artifact. More a conversation than a dashboard.

Most owners we talk to imagine the product as a tool for their customers — a chat to answer questions, a calendar to take bookings, a way to follow up on leads. They're not wrong; that's what they see first. But the deeper feature is the one nobody describes until they have it: the owner can message their business directly and ask anything. How many bookings this week. Who hasn't paid. What was the busiest day last month. Who's the most loyal client.

The business answers in the voice it's been set up with. From its own data. Without the owner switching tabs, pulling reports, or asking another person.

This is hard to sell because nobody has a pre-formed need for it. You don't know you wanted to talk to your business until you do.

The first time an owner does it — really does it, casually, the way they'd text a colleague — they don't say “oh nice feature.” They say “wait, I can just ask?”

Yes. You can just ask.

It refuses to make things up.

Yesterday, a customer asked one of our pilots about a gluten-free option that the restaurant doesn't actually offer. The brain knew the menu. It also knew the menu didn't include the dish. So it said so — politely, with an offer to suggest something close.

The chat said “we don't have a dedicated gluten-free option, but the sea bass crudo and the roasted vegetables are naturally gluten-free.” Then it flagged the conversation. The owner saw the flag in the morning brief: “two customers asked about gluten-free options this week; consider adding one to the menu.” The next day they did.

This is the design pattern we keep returning to. The chat doesn't pretend the business knows things it doesn't. It surfaces gaps. The business decides what to do with them. The brain learns from the decision.

Wrong, in this system, is cheap to fix. That's the goal.

We replaced it with a rule that said replies should be under three sentences. The product got better.

Words are not equivalent across languages. A fifty-word reply in English becomes a thirty-word reply in Russian (more compact morphology) or a seventy-word reply in Georgian (longer inflectional endings). The same constraint behaves differently in each language — strict in one, loose in another. The owner notices when the chat is too short in Georgian and too long in English from the same rule.

Sentences are different. A sentence is a sentence in every language we tested. The model counts periods, question marks, exclamations; the count is the same whether the reply is in Tbilisi Russian or Black Sea Georgian. The constraint behaves identically. The owner stops noticing.

This is one of those tiny rewrites that hides a design insight. If you're building for a multilingual business, write your rules in units that survive translation. Sentences, not words. Items, not pages. Days, not hours.

The product is supposed to feel the same in every language. Our rules have to mean the same in every language first.

We use it deliberately and narrowly.

Boutique, for us, means a business where the owner knows most of their customers' first names. Where the average ticket is high enough that one lost lead matters. Where the customer is choosing this business because of a specific feeling — not the cheapest, not the closest, not the most convenient — but the right one.

That covers small clinics, premium hotels, fine restaurants, planners, jewellers, gallery shops, niche service businesses. It doesn't cover supermarkets, chain salons, big-box retail, or any business optimised for volume over relationship.

The line we ended up drawing: aitvini is for businesses where every customer is supposed to feel like the only customer. If that doesn't describe your business, the product is overkill. If it does, the product is exactly what we built.

They don't make accounts to ask a hotel about parking. They want to ask a question and get an answer, in the same fifteen-second window where the question crossed their mind.

That's why the chat lives at a QR code on the table, a link in the Instagram bio, a button at the bottom of the booking page. Three places customers are already looking. Zero downloads, zero accounts, zero friction between curiosity and answer.

The visible cost of this design is that the chat doesn't know who the customer is. Anonymous by default. The invisible benefit is that the customer is willing to actually use it.

We trade identity for usage. The boutique businesses we work for already know their customers another way — face-to-face, at the front desk, at the table. The chat fills the gap between those moments.

Once you have a chat that captures every conversation and a brain that knows the business, you're three sprints away from building a customer database, a notes-on-each-guest system, a “Sarah usually orders white wine” field, a quick re-engagement campaign tool. People asked for it.

We didn't build it. Not because the features wouldn't work but because the moment we became a CRM, we became the wrong product. CRMs are tools the business operates. aitvini is software the business reads. The owner spends thirty minutes a day on the brief, not eight hours a day in a dashboard.

There's a category trap here. Software that does many things badly is worse than software that does one thing well. We picked one thing — turn customer conversations into a daily brief — and committed to doing it at a level a boutique business can't do for itself.

Everything else, we don't build.

We had the idea, a domain, a Notion doc, and three pilot customers willing to try it. No code yet. No chat. No brain. Just a conviction that the conversations boutique businesses were already having — at the table, on Instagram, on the phone — contained more useful information than any survey ever would.

Six months later, the chat is live in three Batumi pilots, the brief has shipped forty-seven mornings, and the brain holds three businesses' worth of policy, tone, and menu detail. The site is up. The journal is starting. The hardest decisions are still in front of us. The interesting ones have already been made.

Boutique businesses are underserved by the software industry. We're building from Batumi for the businesses we know. The bet is that what works here works elsewhere too.