We are going to show you something most consultancies would never share: exactly how we build franchise automation systems, what tools we use, and why we can deliver in weeks what used to take development teams months.

The short answer is Claude Code.

Here is the long answer.

What Building a Franchise System Used to Look Like

Two years ago, building a custom franchise management system meant hiring a development team, scoping a project over two to three months, building over six to twelve months, and paying somewhere between $50,000 and $150,000.

The result was usually a system that was already outdated by the time it launched, because the requirements changed during development. The brand added fifteen units. The sales process shifted. The ops director who wrote the original spec left. By month nine, you were paying change-order rates to fix a system that had not gone live yet.

That is why most emerging franchise brands never built anything. They bought enterprise software designed for a brand three times their size, adapted their operations around it, and lived with the gaps. Or they ran on spreadsheets and email and told themselves they would fix it after the next ten units.

We do not build that way anymore. Neither should you.

A Representative Build

What follows is a representative scenario, not a named client account. It is a composite of the franchise builds we run, and the numbers in it are the targets we scope against rather than one brand's audited results. We would rather show you the method honestly than dress up a case study.

So: a franchise brand at roughly 35 units. Their situation will sound familiar if you are anywhere near this size.

Sales leads were sitting in an inbox for 24 to 48 hours before anyone touched them. Franchisee onboarding was tracked on a shared Google Sheet that three people edited and nobody trusted. Support questions from franchisees went into a group email chain, where the same question got answered by a different person every month with a slightly different answer. Monthly reporting was done by hand in Excel by their ops director, who lost two full days to it every single month.

None of this was a technology problem yet. It was an operations problem that technology had stopped keeping up with. At eight units, an inbox works. At 35, it does not, and everyone knows it about six months before anyone says it out loud.

They did not want a platform. They wanted their operation to run the way they already knew it should.

Phase 1: Discovery (Week 1)

We spent one week understanding their operations. Not their tech stack. Their operations.

How do leads come in? Who touches them first, and what do they do with them? What happens in the seventy-two hours after a franchise agreement is signed? Where does a franchisee go when they have a question at 10pm on a Sunday because the walk-in went down? What reports does the founder actually look at on Monday morning, and what does he do differently based on what he sees?

That last question matters more than people expect. A lot of reporting exists because someone once asked for it, not because anyone acts on it. We found three recurring reports nobody had read in a year, and one number the founder tracked in his head that had never been written down anywhere.

We mapped every workflow before we opened Claude Code once.

This is the part that cannot be compressed, and it is the part that determines whether the build is worth anything. If you get the operations wrong, AI will help you build the wrong system very quickly.

Phase 2: Architecture (Week 2)

We designed the system on paper first.

Four core modules:

Franchise sales pipeline with AI qualification. Every inbound lead gets a response in under a minute, gets qualified through an actual conversation rather than a form, and gets routed based on what that conversation reveals.

Franchisee onboarding workflow with automated task sequences. The signed agreement triggers a sequence. Corporate tasks, franchisee tasks, vendor handoffs, and deadlines, all visible to both sides.

Support hub with AI-powered FAQ. Franchisees ask a question in plain language and get the brand's actual answer, sourced from the operations manual, at whatever hour they ask it.

Reporting dashboard that pulls from all three. One view, delivered rather than requested.

We also decided what we were not building. No custom royalty engine, because their accountant already handled it and handled it well. No field audit tooling, because at this size the field team's process was working. Deciding what not to build is most of architecture. It is also where a lot of six-figure projects go wrong, because a development shop paid by the hour has no incentive to talk you out of a module.

Then we opened Claude Code.

Phase 3: Build (Weeks 3 to 5)

This is the part people want to see.

Claude Code read our existing codebase, understood the GoHighLevel API structure, and started building.

Day 1: the entire lead response automation. A form submission triggers an AI qualification conversation over SMS. The system asks about liquid capital, target market, timeline, and franchise experience the way a good development rep would ask, one question at a time, adapting to the answers. It scores the lead against the brand's own criteria. Hot leads get routed straight onto the sales director's calendar with the full conversation transcript attached. Warm leads drop into a nurture sequence. Unqualified leads get a genuinely useful response instead of silence.

What would have taken a developer two to three weeks took an afternoon.

Days 2 to 4: the onboarding workflow. Every task sequence from the discovery map, built as automated pipelines with owners, dependencies, and deadlines. Site selection, lease review, equipment ordering, training scheduling, marketing launch, opening day. When a task completes, the next one fires. When one goes past due, it escalates to a human rather than sitting silently.

The nuance here was not technical, it was operational: which delays are normal and which are real problems. Lease negotiation running three weeks long is Tuesday. Training not scheduled two weeks before opening is an emergency. We told Claude Code the rules, and it built the escalation logic to match.

Days 5 to 8: the support hub. We fed it their operations manual, their vendor documentation, and eighteen months of the group email chain. That email chain turned out to be the most valuable asset they had, and nobody had ever treated it as one. It was a record of every question franchisees actually ask, in the words they actually use.

The result answers questions in the brand's own voice, cites the source document, and routes anything it cannot answer confidently to a human with the context attached. It does not guess. That constraint was a deliberate build decision, and it is the one we would fight hardest to keep.

Days 9 to 12: the reporting layer. Custom queries pulling from the pipeline, the onboarding workflows, and the support hub, plus n8n workflows routing data between systems that were never designed to talk to each other. The output is a Monday morning report that answers the founder's actual questions, including the one he had been tracking in his head.

Three weeks of build. For a system that, priced traditionally, was a nine-month project.

The Stack We Actually Use

People assume a build like this means a bespoke application sitting on its own servers. It almost never does, and it should not.

GoHighLevel is the spine for most of our franchise builds. It handles the CRM, the pipelines, the SMS and email, the calendars, and the sub-account structure that lets corporate see everything while each franchisee sees only their own. It is not franchise software, and it needs real configuration before it fits a brand, but the underlying architecture matches how franchising works better than anything else at its price.

n8n handles the routing between systems. Data moving from a form to the pipeline, from the pipeline to the reporting layer, from the support hub back into the CRM as a logged interaction. This is the connective tissue that used to be the single most expensive part of any custom build.

Claude sits inside the workflows themselves, doing the qualification conversations and the support answers.

Claude Code is what builds and maintains all of it. It writes the API integrations, configures the workflows, generates the reporting queries, and produces the documentation the client's team needs to run it without us.

The client owns every piece. No proprietary layer they cannot leave, no data we hold, no license that scales against them per unit. If they fired us tomorrow, the system keeps running and their own ops director can maintain it, because the documentation was built alongside the code rather than promised for later.

That last part is not a technical decision. It is a positioning decision, and it is the one we would defend hardest.

What Claude Code Is Genuinely Good At

We want to be specific here, because a lot of AI coverage is either breathless or dismissive and neither helps you make a decision.

Claude Code is very good at reading an existing codebase and extending it. It does not need everything explained. It reads what is there and builds in the same patterns.

It is very good at API integrations. Connecting GoHighLevel to a reporting layer, or a form to a scoring engine, or a scheduling tool to a task sequence, is exactly the kind of work that used to eat developer weeks and now takes hours.

It is very good at building n8n workflows for data routing, at writing custom reporting queries against messy data, and at producing support documentation that reads like a person wrote it.

And it is very good at revision. The traditional development cycle punishes changed requirements. This one does not. When the client saw the onboarding module and said the equipment ordering step needed to split into two, that was a conversation, not a change order.

If you want a fuller explanation of what the tool actually is, we wrote a franchise operator's guide to Claude Code that assumes no technical background.

Where Humans Still Drive

Claude Code does not decide what to build.

It does not understand why a franchise brand with 35 units has different needs than one with eight. It does not sit on a discovery call and hear the frustration in a franchisor's voice when he describes his broken onboarding process, or notice that he mentioned the same vendor problem three times in an hour and never once called it a problem.

It does not know that the report nobody reads should be killed rather than automated. It does not know which franchisee complaints are signal and which are one loud operator. It does not know that the real reason onboarding stalls is that the field team is stretched, and no amount of task automation fixes a staffing gap.

Strategy, architecture, and franchise expertise are human. Execution speed is where Claude Code changes everything.

That distinction is the whole business. Anyone can now build fast. Building the right thing fast still requires knowing how franchise systems work, which is why we spend a week on operations before we write a line of anything.

Phase 4: Testing and Refinement (Week 6)

We tested every workflow with real scenarios, not happy paths.

A lead submission at 2am on a Saturday. A lead who answers the qualification questions out of order. A simulated franchisee question about equipment ordering, phrased the way a frustrated operator phrases it at closing time. A franchise agreement signed the day before a holiday week. A month-end report generation with incomplete data in one of the three sources.

Things broke. A lead who replied with a voice memo instead of text broke the qualification flow. The support hub answered a question about a vendor the brand had switched away from four months earlier, because the old documentation was still in the source set. The onboarding escalation fired on a task that was legitimately blocked by the landlord.

Every one of those got fixed in minutes rather than days. That is not a small difference. In a traditional cycle, a testing week produces a defect list that comes back as a two-week fix sprint, and half of it ships wrong because the developer never saw the actual scenario. Here, we found it, described it, and watched the fix work before moving on.

Phase 5: Launch and What We Scope Against

Here is where we have to be careful, because this is the part of a post like this that usually gets inflated.

Some of what a build like this delivers is mechanical. It is a property of the system, not an outcome we are claiming on a brand's behalf:

Lead response drops to under 60 seconds. Not because anyone got faster, but because the first touch is no longer waiting on a person to open an inbox. If the automation is running, the response happens. There is no version of this where it takes 24 hours.

Reporting arrives Monday at 7am. The two days a month the ops director spent assembling it in Excel are simply gone, because the assembly step no longer exists. That is roughly 24 working days a year handed back to someone whose job is operations.

Onboarding status is visible to both sides in real time. The shared sheet nobody trusted is replaced by a sequence with owners and dates.

Then there are the numbers we treat as targets, not promises. These are what we scope a build against and what we would hold ourselves to reviewing at 90 days:

  • Onboarding tasks completed on schedule: 90 percent or better. Most brands at this size are somewhere in the 60s when they start measuring, largely because nobody was measuring.
  • Inbound franchisee support questions reaching the ops team: down by half or more. The ceiling depends entirely on how good the brand's documentation is going in. A well-maintained operations manual gets you a much better number than eighteen months of email threads.
  • Total build time: six weeks. This one we hold to, because it is a function of our process rather than the client's situation.

Whether a specific brand hits the target range depends on things outside the system: whether the field team adopts it, whether the documentation was any good, whether the franchisor enforces the process. We would be lying if we told you the software determines that.

What we will say plainly is the cost comparison, because it is structural rather than situational. A build like this costs a fraction of what enterprise franchise software charges for a less customized result, and it carries no per-unit licensing that scales against you as you grow.

And the outcome we actually care about is not a percentage at all. It is whether the system is still in use a year later. Most franchise software gets bought, rolled out, and quietly abandoned by the field, because it was built for a workflow nobody has. A system built from the brand's own workflow has nothing to adopt. That is the whole argument for building this way.

Why This Matters for the Franchise Industry

The economics of custom software just changed, and the franchise industry has not caught up to it yet.

For twenty years, emerging brands had two options: enterprise platforms priced and designed for 500-unit systems, or spreadsheets. The middle option, software built for how your brand actually runs, was priced out of reach for anyone under 100 units. So the 10 to 75 unit brands, which is most of franchising, ran on tools that almost fit and absorbed the gap with human effort.

That gap was where ops directors burned out. It was where franchisee frustration started. It was where good brands stalled at 40 units because the operation could not carry more.

It does not have to be there anymore. If you want a broader view of what is worth using, we keep a running assessment of the AI tools that actually work for franchise operations.

Every franchise brand deserves infrastructure built for how they actually operate, not a template designed for a brand three times their size.

Claude Code does not make that possible. Franchise expertise makes it possible.

Claude Code makes it fast.


Thinking About a System Build?

If you are running 10 to 100 units and your operation has outgrown the tools holding it together, we should talk. We will walk your workflows the same way we walked theirs, tell you honestly which parts are worth building and which parts you should leave alone, and give you a real scope and timeline before you commit to anything.

Talk to us about a system build