When Custom Work Stops Being Custom: How Repeated Clinic Requests Became Tin Marketer
By Alex Mastryukov · Last updated: August 18, 2026
Tin Marketer did not start as a product idea
It started as repetition.
Several clinics came to us with slightly different versions of the same problem: Google Ads were managed separately from Meta, the website was handled by someone else, reception answered WhatsApp manually, conversion tracking was incomplete, lead handling lived in another system, and the clinic owner had no clear view of which part of the funnel was actually working.
At first, these looked like separate custom-development or marketing requests.
Then the pattern became obvious. The clinics were different. Their services, cities, pricing, teams, and positioning were different. But the underlying work was mostly the same.
At that point, continuing to rebuild the same machinery as custom projects stopped making sense.
Tin Marketer became a separate product because enough of the problem was repetitive that the core could be built once, configured per clinic, and operated as a managed platform.
This is the same judgment call behind our Custom Clinic Automation work, just pointed in the opposite direction — most requests stay one-off projects. This one didn't.
The real hypothesis: do the basics properly
The easiest marketing claim would have been that AI replaces your marketing agency. That is not really the product we built.
There are excellent marketers and agencies whose strategic expertise is absolutely worth paying for. But most small clinics are not buying a world-class growth team. They are paying someone to execute the fundamentals.
A competent freelancer or small agency usually needs to understand the business, identify the services worth advertising, understand location and audience, build reasonable search campaigns, write decent ad copy, create useful landing pages, install tracking, respond to leads, check what is working, stop obvious waste, and keep everything up to date.
None of that is trivial. But most of it is also not magic.
The Tin Marketer hypothesis became: can software plus AI perform the routine work of a competent small-business marketer correctly enough, consistently enough, and cheaply enough that the clinic does not need to coordinate several people to do it?
The platform is not asked to be a genius CMO. It is asked to do ordinary work well, and to use humans where judgment still adds value.
How it's built
One structured clinic profile feeds the whole system
The first important design decision was to avoid letting every downstream component independently interpret the clinic.
Instead, onboarding builds one structured clinic profile containing business information, niche, location, advantages, services, team, media, and marketing preferences.
Service and team data can be entered manually, described in natural language, or uploaded from documents such as PDF, Word, or Excel. An LLM converts unstructured input into structured records for review before saving:
{
"service_name": "Botox — 2 areas",
"category": "Injectables",
"duration_minutes": 30,
"price": 350,
"currency": "USD",
"advertise": true
}That structured profile becomes the common source of truth for website generation, ad copy, campaign structure, lead handling, doctor/service questions, and future re-optimization. If multiple AI components each maintain their own implicit understanding of the business, the system eventually drifts. Shared state prevents that.
One source of truth. Every system reads from it.
Structured Clinic Profile
Business, niche, location, services, team, media, preferences
If every system kept its own copy of "who this clinic is," the copies would drift. This is why they don't.
AI should remove configuration work, not create more of it
A clinic owner should not need to understand keyword grouping, campaign hierarchy, tracking pixels, landing-page structure, prompt design, conversion events, campaign APIs, or vector retrieval.
They should be able to explain their business.
The current onboarding flow collects what the platform needs in seven guided steps. When onboarding is complete, background jobs automatically trigger the Google Ads builder, Meta Ads builder, and, where required, the website builder.
The translation between business-language input and marketing infrastructure is one of the places where AI is genuinely useful.
Build first, approve second
One of the core design principles is build first, approve second.
The platform creates the first version of a website or campaign automatically, but generated does not mean live.
Websites are deployed first to a preview environment. Campaigns are built as draft structures inside the platform database before anything is pushed into Google or Meta.
The Tin Marketer team reviews the generated output. Then the clinic approves. Only after approval does the asset go live.
Recognize this pattern from your own repeated client requests?
Let's talk about productizing it →The marketing stack itself
Website generation is part of the acquisition system
The website component exists because ad performance and landing-page performance cannot be treated independently.
The website builder loads the structured clinic profile and generates the site page by page: home, service pages, practitioner pages, contact, lead forms, WhatsApp, and booking CTAs. The page-by-page design is intentional — it makes individual failures easier to inspect and repair than one giant generation call.
The generator operates under explicit anti-invention rules. It may only use information supplied by the clinic and must not invent awards, certifications, patient counts, years in business, addresses, phone numbers, qualifications, or unsupported claims. If information is missing, it is omitted.
The website is instrumented from day one
A marketing website without conversion tracking is mostly a brochure.
Platform-generated sites include conversion instrumentation for Google and Meta. Lead-form submissions, WhatsApp clicks, and booking actions can be recorded as conversion events. This lets the platform move its measurement target further down the funnel: from clicks, to leads, to booked patients.
Advertising is generated as structured data before it touches Google or Meta
Campaign generation follows the same draft-first principle as website generation.
The AI first creates the campaign structure inside the Tin Marketer database: campaigns, ad groups, keywords, copy, targeting, and budgets. Only after review is the approved structure pushed to the clinic's advertising account.
This is effectively a staging environment for advertising: generate, inspect, approve, deploy.
The clinic owns the advertising infrastructure
Tin Marketer operates through the clinic's own Google Ads and Meta accounts.
The clinic keeps account ownership, historical campaign data, conversion history, domain, website assets, and WhatsApp number. Ad spend goes directly from the clinic to Google and Meta — Tin Marketer does not own or mark up media spend.
The product should earn retention by being useful, not by making it painful to leave.
Closing the loop on leads
The marketing problem does not end when somebody submits a form
A large number of marketing systems effectively stop at lead generated.
For the clinic, that is the beginning of another workflow. A lead can wait too long for a reply, receive a weak answer, disappear after asking about price, or signal booking intent without anybody completing the booking flow.
That is why Tin Marketer includes a WhatsApp closing layer using clinic-specific information, conversation state, historical conversational precedents, explicit escalation logic, and human oversight. The acquisition funnel therefore becomes campaign → click → landing page → lead → conversation → booking, rather than campaign → click → lead → somebody else's problem.
The communication layer uses behavioral precedent, not just static scripts
One reusable idea from our earlier clinic communication work is that generic scripts are insufficient.
A useful retrieval unit is a paired interaction: lead message + reply + metadata/outcome, rather than only the incoming message. At runtime, embeddings and vector search retrieve relevant historical conversational situations before the LLM generates the next response.
The model is not continuously retrained on those conversations. Historical data acts as external memory. This creates a clean separation: embeddings find precedent, the LLM adapts language, and application logic owns boundaries.
Conversation state is explicit
A sales conversation has progression. A lead may move from new to qualifying, nurturing, booking, and booked, or exit through escalated, lost, or closed.
The system therefore treats stage as explicit state rather than making every incoming message an isolated generation problem. Structured model output can include reply, intent, escalation decision, stage, and confidence so the rest of the application does not need to infer control state from free-form text.
The loop closes. It doesn't stop at "lead generated."
Most systems stop measuring at "lead." This one keeps going until it can attribute a booking back to the ad that paid for it — then feeds that back into the next round of campaign decisions.
Curious how the closing layer actually escalates and hands off?
See the AI Chat Agent solution →How this stays reliable at scale
Profile updates propagate through the system
A product like this becomes fragile if updating one business fact requires manual edits in five subsystems.
When a clinic adds a service, removes a practitioner, changes positioning, uploads media, or updates team information, the platform marks the client as needing re-optimization. One business fact should have one authoritative home. Downstream systems should refresh from that source rather than maintain divergent copies.
A lot of Tin Marketer is intentionally not AI
Tin Marketer uses LLMs heavily, but much of the platform is conventional software.
An LLM can read a price list and structure its contents. Normal code should verify that required records exist. An LLM can generate campaign copy. Normal code should handle campaign state. An LLM can generate website HTML. Normal code should deploy files, configure DNS, and obtain SSL certificates. An LLM can identify lead intent. Normal code should enforce whether a feature is enabled.
The product becomes more reliable when probabilistic components are surrounded by deterministic machinery.
if statement was replaced with an LLM.This is also why the economics work
Tin Marketer is not cheaper because AI knows a secret that human marketers do not. It is cheaper because software changes the cost structure of routine work.
For every new client, a traditional provider repeats much of the same process: collect business information, structure services, build campaigns, write ads, create pages, install tracking, wire lead capture, answer repetitive messages, build reports, and make routine updates. The specific content changes from clinic to clinic. The process changes much less.
Software lets us standardize the process while keeping the content clinic-specific. That converts the delivery model from new clinic → new project → lots of human construction → recurring manual operation into new clinic → structured onboarding → automated construction → human review → client approval → managed operation.
That is where the price difference comes from: reuse, automation, structured data, and standard workflows. Not magic.
Productization does not mean every clinic is identical
The reusable part is the machinery. The variable part is the business.
Two clinics can use the same platform while having completely different services, practitioners, pricing, geography, branding, competitive advantages, ad campaigns, landing pages, and communication style.
The product is standardized at the infrastructure level and personalized at the state and output level. That is a much more scalable form of customization than writing separate code for every customer.
Current status
Tin Marketer is currently operating with pilot clinics successfully. The public launch is planned for September 2026.
At this stage, there is not yet a large-scale benchmark that would justify broad performance claims across the market. The current result is narrower and more important for product development: multiple clinics can use the same core platform without rebuilding the underlying system for each one.
That proves the first productization hypothesis. The next stage is scale.
Lessons learned
Most marketing execution is less magical than the industry sometimes makes it sound
Good strategy and exceptional creative work exist. But a huge amount of small-business marketing is fundamentals. If those fundamentals can be decomposed clearly, software can perform much of the repetitive work.
Repeated custom requests are product research
One request is a project. Several unrelated clinics independently describing the same workflow are information. Eventually, rebuilding the same architecture becomes the wrong engineering decision.
Standardize process, personalize data
The system should have common infrastructure driven by explicit clinic-specific state rather than custom architecture for every customer.
Give AI messy work; give deterministic software deterministic work
Extracting services from an arbitrary PDF is a good LLM task. Checking whether onboarding is complete is not. Writing landing-page copy is a good LLM task. Provisioning SSL is not.
Human-in-the-loop does not mean human-powered
Campaigns can be machine-generated while humans review important decisions. The aim is not to remove every human, but to stop paying human rates for work machines can reliably prepare.
A lead is not the final metric
The long-term target should move further down the funnel: ad spend → lead → conversation → booking → commercial outcome.
What comes next
Public launch is planned for September. The immediate work is not to add AI for the sake of adding AI. It is to make the existing system perform ordinary work better: faster onboarding, better campaign generation, cleaner approvals, stronger landing pages, better historical-dialog retrieval, more reliable closing behavior, more booking integrations, better outcome attribution, and increasingly automatic re-optimization.
Tin Marketer began because several clinics kept asking us to solve what looked like separate marketing problems.
Eventually, it became clear that most of them were asking for the same machine.
That is when we stopped treating it as custom development.