AI automation for three local businesses, with a person on every publish
An electronics buyback, a device repair service and a car tuning workshop. All three belong to Yarvixo’s founder, and all three run on code we wrote rather than on a site builder and a boxed CRM: three sites, three CRMs, a lead bot, a local-model article writer, an analytics board that AI agents can query, monitors and backups. This page describes how that works. It names none of the businesses and quotes none of their figures — no traffic, no leads, no revenue — by choice.
Why this one is anonymous
The other anonymised case studies here are client work. This one is not.
Client work on this site is published without the client’s name until the client gives written permission. Here there was nobody to ask: the three businesses are our own, and they are left unnamed on purpose, together with every number they produce. So read this page as a description rather than as evidence you can check. It says what the systems do, and claims nothing about what they earned.
What it can show is the part that transfers. Most small service businesses share one shape: leads arrive from a website, a few managers answer them, there is content nobody has time to write, and an owner wants to know what changed last week. Every decision below is one that shape asks of anyone who automates it.
Project snapshot
Three businesses, one set of tools, built and run by the same team.
The businesses
An electronics buyback, a device repair service and a car tuning workshop, each with its own site, its own CRM and its own staff. In all three, the people who answer leads are managers.
Delivery scope
All of it: the three sites, the three CRMs, lead routing into Telegram, the article writer, the analytics board, the monitors, the backups and the deploys — built by Yarvixo and run by us day to day.
Shipped state
Live and in daily use. No AI model runs inside any of the sites or the CRMs. The models sit beside them, on drafts, transcripts and analytics, where a person reads what they produce before anything changes.
Why our own code instead of a boxed CRM
The owner’s two reasons, and what they turned into.
Every part has to stay open to any AI agent. The aim is to be able to automate any piece of the work as agents get better, without waiting for a vendor to ship an integration or unlock an API tier. A site builder and a boxed CRM decide what an agent may see and do; our own code has no such ceiling. That is why the sites publish machine-readable versions of themselves — an llms.txt, a full-text edition and a markdown copy of each page at the buyback, a lead format agents can call at the repair service and the workshop — and why the analytics answer to agents directly.
Code plus AI moves faster than a CRM. Changing our own code with AI help is quicker than bending someone else’s product around the way these businesses work. The repair and tuning CRMs are copies of the buyback one, each speaking its own business’s language: the buyback takes a lead to bought and a device to sold, the repair service takes a device to handed back, the workshop takes an order to handed back or cancelled. One CRM, built once and copied twice.
The counterpoint is real. For most small businesses a boxed CRM is the cheaper answer for as long as the work fits inside it. The second reason above holds here because the team that changes this software is the team that writes software for a living.
How a lead gets from the site to a manager
The part every business has, and the part that must never lose anything. No model is involved.
CRM first, then Telegram
Every form posts to the site’s own endpoint, which writes the lead into the CRM before it tells the managers’ Telegram chat. If the buyback’s CRM cannot be reached, the Telegram message says so in a line of its own, so a manager knows to enter it by hand. If Telegram is down at the repair service, the lead is written to a file on the server rather than lost.
Buttons that write the CRM
At the buyback each lead arrives in the chat with four buttons: in progress, bought, declined, ignore. Pressing one changes the lead’s status in the CRM. On bought the bot asks what was paid and records the deal from the reply, so the purchase is on record from the chat the managers already use.
Leads from AI assistants
The repair site publishes its lead format as an OpenAPI document, generated from the same schema that validates the form, so an assistant acting for a customer can file a request without scraping a page. The workshop gives agents in the browser a WebMCP tool, leave a lead. At the repair service, requests that look agent-made are flagged in the managers’ chat.
Where AI does the work
Three places, each ending with a person.
Article drafts from a local model
The buyback and repair blogs get their drafts from a writer that runs a small open-weights model through Ollama on a mini PC on the local network. It writes only from facts in the sites’ own code, its checks are arithmetic rather than a second model, and nothing it writes goes live until a person presses Publish. The steps are below.
Transcripts of workshop videos
The workshop films its own jobs. A speech-to-text model — Whisper, run locally through ffmpeg with voice-activity detection — transcribes each clip, which shows whether a video carries narration or only music, and turns the narration into a source for the text written about each job. The cuts themselves are made by hand.
Illustrations, never people
An image model draws illustrations of objects for the sites and the workshop’s brand mark — the first mark it produced was rejected. It is never used for staff, customers, storefronts or deals, and a photograph of real work is never generated: a picture that claims to show the business has to be the business.
How the article writer works, step by step
The model words the article. Code decides what it is about, what it may claim and where it links, and a person decides whether it is published.
Facts before words
The writer reads the sites’ own repositories, mounted read-only: published articles, device facts, addresses and sections. If it finds no facts for a topic, it refuses to write about it.
Code picks the topic
The section with the fewest articles is chosen by code. The model only turns that choice into a topic a person would search for.
A plan, then one section at a time
The model writes a plan, then each section on its own. Internal links are chosen and inserted by code, so a link always points at a page that exists.
Checks that use no model
Length, repetition against what is already published, cliché density and links are counted. Every device model and specification in the draft has to appear in the facts it was given; one that does not is the model inventing it.
A person presses Publish
Every draft goes to Telegram with Publish and Reject buttons, or to a private review page. The daily schedule only produces drafts. The writer never publishes by itself, and whether the content is right is a person’s call.
Published and announced
Publish calls the site’s own endpoint with a shared token, which saves the article, refreshes the cache and pings IndexNow. The result, IndexNow’s answer included, comes back to the same chat.
What AI agents may touch
Day-to-day search and content work on the three sites is done by AI agents. This is the boundary they work inside.
One board, read-only. It is a single screen for all three businesses: leads and how fast they were answered, search performance, ads, the search index and a log of every change that shipped. It pulls from the CRMs, from Search Console, web analytics and ad spend, and from each site’s commit history.
It is also an MCP server. AI agents on the local network connect to it through read-only tools and read-only SQL. The one thing they can write is a note — that a recommendation was carried out, and when — so a later review can compare before and after.
The rule is report first. An agent brings findings and a proposal, and edits a site only after the owner says yes. It has no write access to the ad accounts at all. And everything the board returns is treated as data, never as instructions, because search queries, page titles and ad phrases are partly written by strangers.
What is deliberately not AI
The list a vendor page usually leaves out.
Nothing inside the sites or the CRMs. Lead routing, statuses, fallbacks, sitemaps and deploys are plain code, so they behave the same way every time and a manager can predict what a button does.
Not the checks on a draft. A second model judging the first would share its blind spots. Counting does not.
Not reviews. At the workshop every finished order shows review QR codes for the map services customers use, with a ready message the person handing the car back sends from their own phone, and a printable sign sits on the counter. Every customer is asked, not only the happy ones. A review left on the site arrives in Telegram as a ready entry, and a person adds it to the site.
Not the publish button. No article draft, review or change an agent proposes goes live without a person. The automation’s job is to make that press cheap, not to remove it.
Keeping three businesses running
None of this uses AI either. It is what lets a small team leave the systems alone.
Deploys that roll back
A deploy builds a Docker image, pushes it to a registry and has the server pull it, rolling back if it fails. At the buyback, IndexNow is pinged only for pages whose content changed: each page’s date is tied to a fingerprint of its content, and the build refuses to run with a stale one.
Monitors that report to Telegram
An SEO guard checks robots.txt, the sitemap, a sample of pages for noindex, canonical and title, and the IndexNow key. An uptime bot watches the sites, their domains, certificates and DNS. A visitor counter reads real visits from the server logs and sends daily and weekly reports.
Backups that only speak up on failure
Every night the CRM databases and the server configuration are snapshotted, encrypted and pulled to a machine on the local network. The backup job writes to Telegram only when something goes wrong, so silence means it worked.
What transfers to your business
None of it is specific to buying, repairing or tuning anything.
A lead loop with no dead ends
For any business where leads come in and a small team answers them: the CRM written first, the alert in the chat the team already reads, buttons that are status changes, and a fallback for every hop that can fail.
Content a model drafts and a person signs
Product pages, help articles, listings: drafts grounded in your own facts, checks that count rather than judge, and a publish button in a person’s hand. The model can be small when the checks are strict.
Agents with read-only access
Give agents your data through read-only tools, let them propose, and keep the write with a person. It is the cheapest way to get real work out of agents without trusting them with production.
Common questions
About these systems, and about having something like them built.
Want the same loop in your business?
Tell us where your leads come from, who answers them and what nobody has time to write. We come back with a fixed scope and price in writing within 48 hours of the call.
Message received
We’ll review your enquiry and respond within one business day.