What Building for 6,000 Locations Taught Me About Platform Thinking | AI PM Portfolio

What Building for 6,000 Locations Taught Me About Platform Thinking

January 20, 2022 · 14 min read · Framework

Platform thinking means designing systems where shared capabilities serve 80% of needs, configurable layers handle 15% of variation, and local extensions address the remaining 5%. When I moved from a logistics platform to a national tax services company with 6,000 franchise locations, each with different capabilities, internet speeds, and staff expertise, I learned that real platform thinking is not about building everything centrally. It is about deciding what to centralize, what to make configurable, and what to leave local.

What is the difference between platform thinking and product thinking?

Before joining a national tax services company, I had built products at an enterprise logistics platform and a field operations intelligence startup. Those are scale challenges, but uniform scale: the same product serves the same use case, just more of it.

Six thousand franchise locations is different. According to the International Franchise Association, the franchise business model contributes approximately $787 billion to the U.S. economy annually. Each location is an independent business under a shared brand. They share some needs (compliance, core workflows) but differ wildly in others (staff capabilities, technology infrastructure).

The first week, I visited five locations. One was a flagship office with gigabit internet and 12 tax professionals. Another was a seasonal storefront with DSL internet and two part-time preparers whose owner handled "IT" by restarting the router. Both needed the same platform. That gap is where platform thinking lives.

How do you design a platform for wildly different capabilities?

We developed a three-tier architecture that I now use as a framework for any platform decision. The principle is that every capability in a platform falls into one of three categories: shared, configurable, or local.

The shared tier: what must be identical everywhere

Tax calculations, compliance rules, and data security are non-negotiable. Every location must produce identical results for the same inputs. According to IRS data, approximately 1 in 20 tax returns contain errors, and errors due to software inconsistency are the fastest way to generate regulatory scrutiny across an entire franchise network. We centralized all tax logic, all data handling, and all security controls. No location could modify these. No regional manager could override them.

This sounds obvious, but the pressure to make exceptions was constant. "Our region handles a special state tax credit differently." "Our location needs to process this form type that the platform doesn't support." Every exception request was a test of platform discipline. We said no to roughly 70% of exception requests, and each no required explaining why consistency mattered more than local convenience.

The configurable tier: where 80/20 meets franchise reality

The configurable tier is where most platform teams either over-engineer or under-invest. Over-engineering means building a visual workflow editor with 200 parameters that no one uses. Under-investing means forcing every location into the same rigid workflow regardless of their circumstances.

We identified 14 configuration dimensions that covered 95% of location-level variation. Some examples:

• Bandwidth mode: High, medium, or low. This controlled image quality, prefetching behavior, and whether heavy analytics loaded by default or on demand. Roughly 22% of locations operated in low-bandwidth mode.
• Staff experience level: Expert, intermediate, or guided. This controlled how much inline help, validation, and review steps appeared in the workflow. New seasonal locations used "guided" mode; veteran offices used "expert" mode.
• Service mix: Which tax services the location offered. Not every location handled business returns, audit defense, or financial planning. The platform only showed UI and workflows for services the location was configured to provide.
• Peak season scaling: Whether the location needed to handle 50 or 500 clients per week during tax season. This affected queue management, appointment scheduling, and workload distribution features.

According to Salesforce's State of the Connected Customer report, 73% of customers expect companies to understand their unique needs. In a franchise model, each location's customers have expectations shaped by the location's capabilities. A platform that forces a two-person rural office to display the same workflow as a 12-person metro office frustrates both.

The local tier: what to leave alone

The hardest platform decision is what not to build. We explicitly chose not to centralize local marketing, appointment booking aesthetics, and community-specific communications. These were areas where local knowledge outperformed central planning every time.

We provided an API layer and a basic extension framework that allowed locations or certified partners to build local capabilities. About 8% of locations used this extensibility, mostly larger multi-location franchisees with their own technical resources. For the other 92%, the shared + configurable tiers were sufficient.

How do you handle the long tail of edge cases at franchise scale?

Six thousand locations generate an extraordinary volume of edge cases. In any given week, we would receive 40-60 support tickets that described scenarios the platform did not handle well. Most product teams treat edge cases as bugs to fix. At franchise scale, edge cases are data. They tell you where your platform model is wrong.

We categorized edge cases into four types:

1. True platform gaps (15% of cases): The platform genuinely could not handle a legitimate scenario. These became backlog items prioritized by frequency and impact.
2. Configuration errors (35% of cases): The platform could handle the scenario, but the location's configuration was wrong. These became training issues.
3. Process violations (30% of cases): The user was trying to do something the platform intentionally prevented. These were usually compliance-related and required explanation, not a fix.
4. Genuine outliers (20% of cases): Scenarios so rare that building platform support was not justified. These received manual workarounds and documentation.

The 80/20 rule at franchise scale means something specific: 80% of locations will use the platform exactly as designed. The other 20% will stress every assumption you made. According to our internal data, 1,200 locations (20%) generated 78% of all platform-related support tickets. But those same 1,200 locations also accounted for 34% of total revenue. You cannot ignore the long tail; you have to manage it strategically.

What does internet speed have to do with platform architecture?

When I joined, the platform assumed reliable broadband. That worked for 78% of locations. For the other 22%, it was borderline unusable during peak hours. According to FCC data, approximately 21 million Americans lacked broadband access, and many franchise locations were in that gap.

We implemented three architectural changes that transformed the experience for low-bandwidth locations:

1. Progressive loading: Core workflow loaded first (under 200KB). Analytics, dashboards, and non-essential UI loaded asynchronously. This reduced initial load time from 8.2 seconds to 1.4 seconds on slow connections.
2. Offline-capable core workflows: Tax preparation could continue even if the connection dropped. Data synced when connectivity resumed. This was critical during tax season peak hours when even adequate connections became congested.
3. Bandwidth-aware asset delivery: Images, help content, and training materials were served at quality levels matched to the connection speed. A 4MB training video became a 400KB compressed version with text transcript for low-bandwidth locations.

These changes improved NPS scores at low-bandwidth locations from 23 to 61, a 38-point increase. The flagship locations barely noticed the changes. That is platform thinking in action: the same system performing well across dramatically different environments, without requiring different codebases or separate products.

How do you decide what belongs in a platform vs a product?

The decision framework I use comes down to three questions:

1. Does this capability need to be consistent across all locations? If yes, it is shared tier. Tax calculations, compliance, security: these cannot vary.
2. Does this capability need to vary but within known parameters? If yes, it is configurable tier. Workflows, UI density, feature availability: these vary by location but within a defined set of options.
3. Is this capability inherently local? If yes, it is local tier. Marketing, community engagement, local partnerships: these should not be centralized because local context always wins.

We made a revealing mistake early on: we built an elaborate document template engine that allowed locations to customize every aspect of client-facing documents. Nobody used it. They wanted three pre-built templates, not infinite customizability. We replaced the engine with three templates and a "request a custom template" workflow. Usage went up 400%.

Configuration is not customization. Configuration means choosing from options the platform provides. Franchise operators want configuration; they do not want to become software developers. According to our usage data, features with the highest adoption (above 90%) were all "choose from 3-5 options" interfaces. Features with open-ended customization had adoption below 12%.

For more on how this platform thinking extended to building AI systems with human review layers at the same company, where the platform architecture had to support both automated and human workflows at massive scale, continue to the next post.

Frequently Asked Questions

When should you start thinking about platform architecture?

Not on day one. Build a product first. When you are copying and modifying code for different customers, that is the signal to abstract. Our transition started after approximately 500 locations.

How do you handle franchise owners who want unsupported features?

Track frequency. If 50+ locations ask, it belongs in the platform. If fewer than 10, provide a workaround. We held a monthly "feature council" with 8 franchise owners representing different segments to pressure-test these decisions.

How do you measure platform strategy success?

Three metrics: onboarding time (ours dropped from 14 to 3 days), support ticket volume per location, and feature adoption rate.

What is the biggest mistake in platform thinking?

Building too much configurability too early. We shipped 6 options and grew to 14 over 18 months. Teams that start with 50 options end up with a product nobody can figure out.

Last updated: January 20, 2022