Most digital businesses do not design their growth infrastructure.
They accumulate it.
A founder needs a landing page, so they choose a landing-page builder. Then they need forms. Email. Payments. A CRM. Automation. Analytics. Support. Maybe a data warehouse. Then AI tools start appearing.
Each decision may have been perfectly sensible.
The problem is what happens when those decisions begin interacting.
A payment event updates the CRM. The CRM triggers an automation. That automation changes a field in another system. That field determines which lifecycle campaign someone enters. Analytics records a different version of the same event. A spreadsheet is used to reconcile the numbers. An AI workflow is eventually added on top.
Nobody deliberately designed the resulting architecture.
It emerged.
At some point, a business that once felt nimble starts to feel fragile. Reports disagree. Automations become dangerous to touch. Customers receive messages that do not match their actual state. Changing one tool risks breaking several others. The founder still understands parts of the system, but no longer understands all of it.
The usual diagnosis is:
We need a better tech stack.
Sometimes that is true.
More often, the business has not simply outgrown its software. It has outgrown the assumptions, ownership model and architecture that accumulated around it.
That distinction matters because better software does not automatically produce better infrastructure.
The founder stack is usually rational
The first version of a digital business should not look like the hundredth.
Early on, the priorities are speed, flexibility, low cost and the ability to experiment without turning every change into an implementation project.
That produces what we can call the Founder Stack.
Its defining characteristic is not cheap software or no-code tools. It is that much of the architecture can remain implicit.
One or two people know how everything connects.
They know which form sends leads into which list. They know what happens after a purchase. They know why an oddly named CRM field really means “active customer.” If something breaks, they know where to look.
For a while, this works extremely well.
The founder is effectively part of the infrastructure.
Problems begin when the business becomes too large, too important or too distributed for one person’s memory to remain a reliable systems layer.
At that point, what was implicit has to become explicit.
Data teams already treat this principle as normal. Platforms such as Segment, Amplitude and Snowplow all recommend formal tracking plans so that important events and properties are defined rather than allowed to emerge arbitrarily. Snowplow goes further by attaching ownership and data-contract concepts to those definitions.
The same logic applies across the whole growth system.
Eventually a business has to define deliberately what had previously been understood informally:
What is a lead?
What makes someone qualified?
When exactly do they become a customer?
What constitutes activation?
Which system owns payment status?
What counts as churn?
What happens if a payment succeeds but an integration fails?
Which systems are allowed to change customer state?
Professionalizing a growth stack begins with questions like these, not with a software comparison page.
Stack Debt: when sensible decisions stop working together
Technical debt describes the future cost created by past technical compromises.
Growing digital businesses accumulate something similar across their commercial systems.
Call it Stack Debt:
Stack Debt is the accumulated operational cost and change risk created when locally rational technology decisions are never reconciled into a coherent system.
Tool count is a poor measure of Stack Debt.
A company might use 25 applications with clear ownership, stable interfaces and good documentation.
Another might use eight systems connected by brittle two-way synchronizations that nobody wants to touch.
The second business may have the worse architecture.
This distinction matters because early compromises are not necessarily mistakes. Technical architecture guidance from Google and others explicitly recognizes that business pressure can rationally create debt. The problem is not that shortcuts happen. It is that temporary decisions are allowed to become permanent without reassessment.
The landing-page builder was probably not the mistake.
Leaving an undocumented four-year-old automation in control of a critical lifecycle transition might be.
Founder Stack → Growth Stack → Scale Infrastructure
There is a useful maturity model here, but it should not be mistaken for a revenue ladder.
Stage 1: Founder Stack
The system is optimized mainly for local speed.
Typical priorities include:
- experimentation
- flexibility
- affordability
- reversibility
- founder control
Architecture can remain informal because the number of critical dependencies is still limited.
Stage 2: Growth Stack
The optimization target changes.
The business can no longer treat each tool as an isolated solution. It has to optimize the customer system.
The priorities increasingly become:
- coherent customer journeys
- trustworthy customer state
- reliable lifecycle management
- measurement
- automation
- experimentation
- repeatability
- maintainability
This is the awkward middle.
The business is too complex to run safely from founder memory, but usually not complex enough to justify enterprise architecture everywhere.
This transition is the core territory of growth infrastructure.
Stage 3: Scale Infrastructure
As customer volume, operational importance and organizational complexity increase, the priorities change again.
Reliability, governance, security, permissions, data architecture, resilience and ownership boundaries become increasingly important.
At this stage, infrastructure has to support teams as much as it supports customers.
But companies do not move through these stages neatly.
A regulated business may need governance and permission controls very early. A high-volume self-serve company may need robust event infrastructure before it has a large team. A content business may reach substantial revenue while remaining well served by a relatively simple stack.
The progression is therefore better understood as:
local optimization → system coherence → organizational governance
rather than:
small company → medium company → large company.
Stop evaluating tools. Map the customer system.
A growth stack becomes much easier to reason about when you stop looking at applications and instead follow the customer through the business.
A simplified architecture might look like this:
TRAFFIC
↓
CAPTURE
↓
QUALIFICATION
↓
CRM / CUSTOMER DATA
↓
CONVERSION / PAYMENT
↓
ONBOARDING / ACTIVATION
↓
LIFECYCLE
↓
RETENTION / EXPANSIONAcross that architecture sit:
Analytics | Experimentation | Automation | AI
This view changes the questions.
Instead of asking:
Is our email platform sophisticated enough?
Ask:
What does the email system need to know about customer state to communicate correctly?
Instead of:
Do we need a better CRM?
Ask:
Which commercial facts should the CRM actually own?
Instead of:
Do we need a CDP?
Ask:
Which customer data currently cannot move reliably enough to support a real business requirement?
Instead of:
Can an AI agent automate lifecycle marketing?
Ask:
Which trusted states, permissions and actions would the agent operate on?
That turns a shopping problem into an architecture problem.
There may be several sources of truth
“Create a single source of truth” is common advice, but it is often oversimplified.
A growing business does not necessarily need one universal system that owns everything.
The more useful principle is:
Every important piece of customer state should have an identifiable authoritative owner.
Payment status may belong to the billing system.
Product usage may belong to the product database.
Sales opportunity state may belong to the CRM.
Entitlement may be derived from billing and product rules.
A warehouse may contain the best analytical representation of all of them without becoming the transactional owner of any of them.
Mature customer-data architectures regularly separate source systems from harmonized analytical layers.
The important question is not:
Where can we find this field?
It is:
Which system should we believe when two systems disagree?
If nobody can answer that, you have found an architectural problem.
Customer state matters more than customer records
A contact record tells you that someone exists.
A useful growth system tells you what is true about them now.
For example:
visitor
→ lead
→ qualified lead
→ buyer
→ onboarding
→ activated customer
→ active customer
→ at-risk customer
→ retained / expanded / churnedThe exact states differ by business.
What matters is that important states exist somewhere in a machine-readable form if systems are expected to act on them.
If a lifecycle team cannot reliably identify:
customers who paid seven days ago but have not activated
then the company may not primarily have an email problem.
It may have a customer-state problem.
That distinction is fundamental.
10 signs you have outgrown your Founder Stack
No single symptom proves that the architecture needs redesign.
Taken together, however, these are strong indicators.
1. Nobody can identify the authoritative customer state
Different systems disagree about who has purchased, subscribed, churned, qualified or activated, and there is no clear rule for resolving the conflict.
2. Important automations have become institutional folklore
People know certain workflows should not be touched, but nobody can confidently explain every trigger, branch, dependency and side effect.
3. One person’s absence materially reduces system reliability
The problem is not just key-person dependency.
That person’s memory has become part of the architecture.
4. Customers receive communications inconsistent with their actual state
Existing customers receive acquisition emails.
Cancelled subscribers receive onboarding messages.
Unactivated customers receive expansion offers.
These are often data and state problems expressed through messaging.
5. Basic lifecycle questions are unexpectedly hard to answer
How many customers activated last month?
What percentage purchased but never onboarded?
Which acquisition channels produce retained customers?
If simple questions require manual reconstruction, measurement architecture is probably weak.
6. Reporting depends on recurring spreadsheet archaeology
Spreadsheets are not the problem.
Repeated manual reconciliation of contradictory system outputs is.
7. Changing one tool has an unknown blast radius
A platform cannot be replaced because nobody knows every workflow, webhook, form, field mapping, dashboard and downstream system that depends on it.
That is a coupling problem.
8. Several tools appear to own the same function
Three systems contain lifecycle stage.
Two systems send onboarding.
Four systems enrich customer data.
Overlap can be intentional. Accidental overlap creates ambiguity.
9. Nobody knows why some software is still being paid for
A recurring SaaS bill survives because someone thinks an old funnel may still depend on it.
This is a sign that system ownership and dependency knowledge have degraded.
10. AI is being layered onto processes the company cannot already explain
This may become one of the most important new indicators.
AI can operate across fragmented systems. It cannot magically resolve contradictory definitions of “customer,” “active,” “qualified” or “churned.”
Giving AI more authority can increase the operational consequences of those contradictions.
What to audit before buying anything
Once these symptoms appear, resist the instinct to start with vendor research.
Start by mapping the system.
1. The customer journey
Document how someone actually moves from first interaction through acquisition, purchase, onboarding, activation, lifecycle and retention.
Not how the funnel is supposed to work.
How it actually works.
Look for handoffs between tools, teams and manual processes.
2. Customer state
Define the states that materially change what the business should do.
Purchase confirmed.
Subscription active.
Qualified.
Activated.
At risk.
Cancelled.
Then identify the event that creates or changes each state.
3. Sources of truth
For each important business fact, identify the authoritative owner.
Not where the data is visible.
Where it is owned.
4. Integrations and automations
Map what sends data where.
What triggers the movement?
What happens if it fails?
What happens if it happens twice?
Who notices?
Who owns the integration?
Payment systems illustrate why this matters. Stripe, for example, recommends server-side webhooks for reliable fulfilment and idempotency protection where duplicate operations could otherwise occur.
A professional system is designed around state transitions and failure modes, not only the happy path.
5. Measurement
Start with business questions.
Then define the events and properties needed to answer them.
Snowplow and Amplitude both recommend beginning with business objectives and important decisions before designing instrumentation.
That sequence matters.
Collecting more data does not fix undefined metrics.
What not to do
The most tempting response to Stack Debt is often:
Let’s rebuild everything properly.
That can be dangerous.
The old system may be messy, but it contains years of accumulated business logic. Replacing it wholesale risks losing undocumented behavior that nobody realizes matters until customers start complaining.
The safer approach is usually progressive replacement.
Martin Fowler’s Strangler Fig pattern describes gradually replacing legacy capabilities rather than attempting a high-risk big-bang rewrite.
The same logic applies to growth infrastructure.
Establish the new state model.
Replace one workflow.
Validate it.
Move the dependencies.
Retire the old component.
Repeat.
Professionalization does not require a dramatic migration event.
It requires reducing ambiguity systematically.
When should software actually be replaced?
A tool should usually be replaced because of a diagnosed deficit.
Capability deficit
The business now requires something the system genuinely cannot support.
Reliability deficit
The platform cannot meet the operational importance or volume of the process.
Integration deficit
Maintaining accurate state across the architecture has become unreasonably difficult.
Governance deficit
Permissions, security, auditability or regulatory requirements cannot be supported appropriately.
Economic deficit
The total cost of keeping the tool is no longer justified by the role it performs.
Without one of these deficits, migration deserves skepticism.
A new CRM connected to the same undefined lifecycle, contradictory fields and undocumented integrations can simply become a newer home for the old problem.
Principles for the next-stage architecture
There is no universal growth stack.
The right architecture depends on the business model, customer journey, operating model, transaction volume and regulatory requirements.
But several principles generalize well.
Prefer explicit ownership over duplicated authority.
Prefer defined customer state over inferred customer state.
Prefer stable interfaces over uncontrolled point-to-point synchronization.
Prefer observable automation over invisible automation.
Prefer intentional instrumentation over collecting every event because storage is cheap.
Prefer incremental migration over unnecessary rebuilds.
Prefer reversible decisions while uncertainty remains high.
And make complexity earn its place.
The objective is not architectural elegance.
It is operational comprehension.
AI makes architecture more important, not less
AI is increasingly being introduced into growth operations as an execution layer.
An agent may identify a customer, interpret their state, draft a response, change a CRM field, trigger an offer or interact with another system.
That makes trustworthy context more important.
Anthropic’s guidance on agent systems emphasizes simple architectures and clear tool interfaces rather than automatically escalating to elaborate frameworks. Analytics vendors preparing data for AI similarly emphasize consistent definitions and governed tracking.
The broader conclusion is partly operator judgement, but it follows from those constraints:
Automation amplifies architecture.
If the underlying state is reliable, automation can increase leverage.
If the underlying state is contradictory, automation can increase the speed at which contradictions become actions.
AI readiness is therefore partly architecture readiness.
Before asking what an agent can do, establish what it can safely know, which systems it should trust and which actions it is allowed to take.
The least complex architecture that supports the next stage
There is a predictable moment in the development of a digital business when the stack stops feeling empowering.
Changes become slower.
Reports acquire caveats.
Every integration adds another dependency.
Nobody is entirely certain what will break if something changes.
The instinct is to modernize by buying more sophisticated technology.
Sometimes that is exactly what the business needs.
Often the higher-leverage first move is less glamorous:
map the customer journey;
define customer state;
establish sources of truth;
remove redundant systems;
fix broken integrations;
simplify automation;
improve instrumentation;
document important workflows;
identify dependencies;
and decide which systems actually own which responsibilities.
Then evaluate technology.
Because the best growth stack is not the most sophisticated stack.
It is the least complex architecture capable of reliably supporting the company’s next stage of growth.
Sometimes the clearest sign that your infrastructure has matured is that you need less of it.
Leave a Reply