What AiRadics is
An analyst and a production line, in one system.
Three things, and the reason for putting them in one place is the interesting part.
It reads the market
Before a practice opens or changes hands: how many dentists per capita already compete for the same patients, and how fast the households nearby turn over — the renter and apartment ratios that cap patient lifetime value however well the place is run.
Then what the payer mix on the ground actually is, against what the practice’s own book assumes, and which clinical services the competition has left alone. A CPA can audit the books. None of this is in them.
It reads the money
Once the practice is running, every channel reports in — Analytics, Ads, Business Profile, Local Services, call tracking, mailers. The model works out what each one is actually producing, what a patient costs through each of them, and where the next dollar earns most.
Not five numbers on a dashboard. An answer about which channel to feed and which to starve, for this clinic, in this market, this month — and then the budget moves.
Sometimes the next dollar is not another click. A household that has just moved has left its old dentist and has to choose a new one — a buying moment nobody is bidding on. Routing budget to a moment like that is a call an agency paid a percentage of ad spend has no reason to make.
It makes the work
The website, the landing pages, the ads, the images, the video — all of it generated, and none of it going live until it has cleared the governance gate: FTC advertising rules, ADA guidance, the advertising requirements of the state dental board, and Google’s stricter standard for health content.
Ads get rewritten, budgets get moved, pages get rebuilt. None of it arrives as a change order, because producing an asset costs us a fraction of what it costs an agency to have a person make one.
Every clinic is a spoke. The learning happens at the hub.
A single practice cannot tell you much on its own. Eighteen months of steady spend across two channels gives a model almost nothing to learn from, which is the reason marketing mix modelling has historically been something only large advertisers could buy.
So the hub does the learning. It sits above every clinic on the platform and works out which patient segments and which market conditions actually pay — then pushes that down to the spokes. A clinic gets the benefit of every market the platform runs in. Its own numbers never leave it, and never inform a competitor’s plan.
All of it stays where it belongs. Raw data lands in the practice’s own cloud project; only aggregated, surrogate-keyed segments cross into ours. If a practice leaves, the project, the warehouse, the history and the website are already theirs.
That is not a feature that arrives once we are large. It is the reason the method works at a single small practice at all, and the reason a competitor with one clinic cannot copy it however good their software is.
Why all three, and not one of them
An agency has people who can make the work but cannot honestly measure it. An analytics tool can measure but cannot make anything. That split is why a dentist ends up paying either for a report they cannot act on or for spend they cannot account for. In one system the analysis decides what to make — and making it is nearly free.
The architecture
One engine. A vertical on top of it.
The engine does not know what a dentist is. Work arrives as an event, the event names its domain, and the engine loads the ontology for that domain and reasons over it. Dental is one ontology. Everything underneath — the consensus layer, the governance gate, the provenance log, the generation pipeline — is written once and does not change.
What carries over
More than the engine. The pipelines that pull channel data and land it in a client’s own warehouse, the aggregation into the hub, the governance gate, the provenance log, the generation and publishing path, the console shell, the deployment and monitoring. All of it is written against a domain interface rather than against dentistry.
A second vertical needs its own ontology, its own screens, its own compliance rules and its own market data. It does not need any of the above rebuilt.
And what does not
The engineering is the cheap half, and we would rather say so than imply otherwise. What does not carry over is everything outside the code: a sales motion into a profession that buys differently, someone with standing in it, a different regulator, and a market model built from scratch.
Medical is the near case because the ontology is an extension rather than a rebuild and we have a physician adviser who runs emergency centres. Take either of those away and it stops being cheap, whatever the code does.
First vertical, in build
Dental practices
The ontology, the interfaces, the catchment models. This is what the round funds and what has to work before anything else does.
Next, and the operator exists
Medical practices
The same problem shape with different vocabulary, and a physician adviser who runs emergency centres. That is why it is second rather than a market we like the look of.
Later
Further verticals
Any fragmented local service where the same three things hold: a decision made without data, a marketing spend nobody can measure, and someone who knows the profession.
We open a vertical when there is a person who knows it, not when the market looks attractive. That is the whole rule, and it is why the list is short. Dental first, and it has to work before the second one starts.
The product is being built against one live practice, chosen because it exercises every payer class a general dentist bills.