Most technology audits begin in the wrong place.
Someone exports the list of software subscriptions. Every application gets put into a spreadsheet. Cost, owner and usage are recorded. The team looks for duplicates, unused licenses and obvious opportunities to consolidate.
That exercise can save money.
But it does not necessarily tell you whether the growth infrastructure works.
A company can remove five SaaS subscriptions and still have contradictory customer records, unreliable lifecycle automation, weak instrumentation and a CRM that nobody trusts.
The reverse is also true. A business with 25 tools might have a coherent architecture in which every system has a clear responsibility and every important piece of customer state has an identifiable owner.
The more useful question is not:
What software are we using?
It is:
How does the business actually acquire, convert, activate and retain customers; what information makes that possible; and which systems are responsible for maintaining that information?
That is the starting point for a useful growth tech stack audit.
In Your Business Has Outgrown Its Tech Stack. Now What?, we introduced the idea of 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.
A good audit should make that debt visible.
That means looking beneath the software.
At the customer journey.
At customer state.
At where authoritative information lives.
At how that information moves.
At what happens automatically.
At where humans are holding the system together.
At what can fail.
And only after that at what technology might need replacing.
A practical sequence is:
Journey → State → Ownership → Flow → Observability → Resilience → Economics → Governance → Action
The sequence matters.
Starting with software encourages you to think about applications.
Starting with the customer journey forces you to think about the system.
1. Map the journey before you map the stack
Begin with a simplified view of how someone moves through the business:
TRAFFIC
↓
CAPTURE
↓
QUALIFICATION
↓
CRM / CUSTOMER DATA
↓
CONVERSION / PAYMENT
↓
ONBOARDING / ACTIVATION
↓
LIFECYCLE
↓
RETENTION / EXPANSION
Across the architecture:
ANALYTICS | EXPERIMENTATION | AUTOMATION | AIYour version may look different.
That is the point.
Do not map the funnel as it appears in the strategy deck. Follow what actually happens.
Take a real customer.
Where did they first appear?
What happened when they submitted their details?
Which system created the record?
What identified them?
What made them qualified?
What happened when they purchased?
How did the rest of the stack learn about the purchase?
What started onboarding?
What established activation?
What determined which lifecycle communication they subsequently received?
What happens if they cancel?
At every meaningful transition, identify the systems involved, the data created, the state changed, the automation triggered, any manual work performed and the measurement generated.
You should eventually be able to draw the business as a system.
That picture will usually tell you more than a SaaS invoice list.
2. Define the customer states that matter
The next layer is customer state.
A contact record tells you someone exists.
Customer state tells the business what should happen next.
Depending on the business, states might include:
Visitor
↓
Lead
↓
Qualified
↓
Buyer
↓
Onboarding
↓
Activated
↓
Active
↓
At risk
↓
Expanded / Cancelled / ChurnedDo not copy that model automatically.
Customer states should correspond to meaningful decisions.
If reaching “Activated” changes onboarding communication, product intervention or account management, it matters.
If “Qualified” determines whether Sales should engage, it matters.
If the difference between “Cancelled” and “Active” determines whether somebody should retain access to a service, it matters enormously.
For each important state ask:
- What creates it?
- What ends it?
- Which event proves the change happened?
- Which system knows first?
- Which system is authoritative?
- Which other systems need to know?
- Which communications depend on it?
- Which automations depend on it?
- What happens if synchronization fails?
Then ask the uncomfortable question:
Can two systems simultaneously disagree about this customer?
If the answer is yes, you have probably found Stack Debt.
The point is not to create a perfect taxonomy.
The point is to make important business state explicit enough that systems can act on it reliably.
3. Establish who owns what
“Build a single source of truth” sounds attractive.
Real architectures are usually more nuanced.
Your payment platform may be authoritative for whether a transaction succeeded.
The product may be authoritative for whether someone completed activation.
The CRM may own sales opportunity state.
A warehouse may contain a consolidated analytical representation of all of those facts without becoming the operational owner of any of them.
The more useful rule is:
Every important business fact should have an identifiable authoritative owner.
Create a simple Source of Truth Matrix:
| Business fact | Authoritative system | Downstream consumers | Update mechanism | Owner |
|---|---|---|---|---|
| Payment succeeded | Billing | CRM, product, analytics | Webhook | Finance / Product |
| Account activated | Product | CRM, lifecycle, analytics | Event / API | Product |
| Sales opportunity | CRM | Reporting, forecasting | Native | Sales |
| Cancellation | Billing | Product, CRM, lifecycle | Webhook | RevOps |
Then test it.
When the CRM says Sarah is active but billing says she cancelled yesterday, which system wins?
If everyone has a different answer, software replacement is premature.
You first have an ownership problem.
The same principle applies to functions as well as data.
Which system owns:
- lifecycle communication?
- lead qualification?
- billing?
- experimentation?
- product usage?
- support state?
- consent?
- customer identity?
Overlap can be legitimate.
Ambiguous authority is the problem.
4. Map how state moves
Once ownership is clear, inspect the connections.
Growth systems move information through several mechanisms:
APIs.
Webhooks.
Native integrations.
Automation platforms.
Scheduled synchronization.
Imports.
Exports.
Spreadsheets.
Sometimes a person copying a value from one screen into another.
Do not dismiss the last category. Humans frequently operate as undocumented middleware.
For every meaningful integration, document:
SOURCE
↓
TRIGGER
↓
TRANSFORMATION
↓
DESTINATION
↓
BUSINESS CONSEQUENCEThen inspect the failure conditions.
Can this operation happen twice?
Can it arrive late?
Can another integration overwrite it?
Can partial failure leave the customer in contradictory states?
Can the integration fail without anybody noticing?
Can the integration still authenticate if the employee who originally created it leaves?
Can someone explain why it exists?
This is where a simple-looking stack often turns out to be complicated.
One application may have three direct integrations, two automations, a weekly CSV export and a spreadsheet that someone manually reconciles every Monday.
The application itself is not the architecture.
The dependency network around it is.
5. Audit the automations, not just the integrations
An integration moves information.
Automation makes something happen because of it.
That makes automation especially important around customer-facing processes.
For every important workflow ask:
What triggers this?
What state does it assume?
What systems does it read?
What can it change?
What customer consequence does it create?
What happens if it runs twice?
What happens if half the workflow succeeds?
Who sees failures?
Who owns it?
Is it documented?
And perhaps most importantly:
Does this automation still need to exist?
Automation can conceal bad process design.
A 16-step workflow solving a problem that should no longer exist is not sophisticated infrastructure.
It is automated complexity.
This is one of the most important distinctions in a stack audit.
Do not ask only:
Can we automate this?
Ask:
Should this process exist in its current form at all?
Sometimes the best automation project is deleting three steps.
6. Ask what the business actually needs to know
Analytics audits often begin with installed tracking.
Start instead with questions.
Identify the questions your growth system actually has to answer.
For example:
Where do valuable customers come from?
What percentage of buyers activate?
How long does activation take?
Where does onboarding fail?
Which behaviors correlate with retention?
Which customers are becoming at risk?
Which experiments actually changed outcomes?
Then work backwards.
What data is required?
Which events represent those behaviors?
How are users identified?
Who defines those events?
Which system emits them?
Can you trust them?
This exposes an important distinction.
When analytics is weak, the problem may be:
collection — the data never arrives;
definition — teams mean different things by the metric;
identity — one customer is represented inconsistently;
ownership — nobody controls the definition;
analysis — the data exists but is interpreted badly;
decision-making — the analysis exists but nobody acts on it.
“We need better analytics” can describe six different problems.
Only some require different software.
A useful test is simple:
Can the company reliably answer the 10 most important growth questions it needs to make decisions?
If not, identify why before changing tools.
7. Find the humans holding the system together
Now inspect manual work.
Look for:
- repeated copy and paste;
- recurring CSV imports;
- spreadsheet reconciliation;
- manual lifecycle updates;
- manually triggered onboarding;
- duplicate data entry;
- weekly reporting assembly;
- repetitive exception handling;
- people routinely checking whether automations succeeded.
Do not automatically automate these processes.
Some manual work is valuable.
A human deciding whether an enterprise lead is genuinely qualified may be exactly what the business wants.
A human downloading customer records every Friday and copying subscription status into another system probably represents something different.
The useful question is:
Is this manual because human judgment creates value, or because the infrastructure was never finished?
That distinction prevents automation from becoming an ideology.
It also reveals where people have quietly become part of the technical architecture.
If a process stops when one operator is on holiday, document it.
If a spreadsheet exists only because two systems cannot agree, document it.
If someone manually fixes the same class of automation error every week, document it.
These are often architectural clues.
8. Inspect what happens when things fail
Most diagrams show successful journeys.
Audits should examine unsuccessful ones.
What happens if:
a payment succeeds but the CRM never learns about it?
a customer cancels but the email platform still considers them active?
a webhook arrives twice?
an analytics event disappears?
a CRM field is renamed?
an automation account belongs to an employee who leaves?
an API credential expires?
the automation platform is unavailable for several hours?
A useful question here is:
If this component changes or fails, how much of the customer system can it affect?
That is its dependency blast radius.
A tool can be technically reliable while occupying a dangerously coupled position in the architecture.
If replacing one system risks breaking onboarding, lifecycle email, attribution, billing reconciliation and customer support, the problem is not simply vendor lock-in.
It is architectural coupling.
Professional infrastructure tries to make those dependencies visible and manageable.
9. Determine whether you can see failure
Failure is significantly more dangerous when invisible.
Ask whether important integrations and automations have:
- logs;
- alerts;
- failure queues;
- retries;
- owners;
- reconciliation processes;
- ways to identify affected customers.
Then ask:
If something important broke yesterday, how would you know?
If the answer is “eventually a customer would probably tell us,” observability is weak.
Observability is not only an engineering concern.
For growth teams, it means being able to understand what happened to a customer and why.
Why did this person receive this email?
Why were they placed in this segment?
Why did their subscription state not change?
Why are two dashboards reporting different numbers?
If the business cannot reconstruct those events, parts of the growth system are effectively opaque.
10. Audit the economics of complexity
Only now return to the software inventory.
For each application calculate more than the subscription price.
Consider:
Software cost
What do you actually pay?
Implementation cost
What did it take to establish?
Maintenance cost
How much ongoing technical or operational work does it create?
Operator time
How much manual work exists because of it?
Failure cost
What happens when it behaves incorrectly?
Migration cost
How difficult would replacement really be?
Opportunity cost
Does the architecture prevent something valuable from being done?
That is closer to Total Cost of Ownership than looking at annual SaaS spend.
It also explains why tool count is not synonymous with complexity.
One additional application that removes five manual processes might simplify the system.
One “all-in-one” platform requiring elaborate workarounds may increase complexity.
The better question is:
Does this component earn the complexity it introduces?
This is where “zombie SaaS” becomes visible.
Not simply software nobody uses.
Software nobody can confidently remove because nobody knows what still depends on it.
That is a stronger warning sign than a low login count.
11. Audit access and governance
Governance should scale with risk.
Identify:
who has administrator access;
which accounts are shared;
which integrations have write permissions;
who can export customer data;
which credentials belong to former employees;
which systems can delete records;
whether sensitive changes are logged;
whether service accounts have broader access than necessary.
For smaller businesses, this does not need to become a bureaucracy.
It does need to become explicit.
A 15-person business handling sensitive customer data may require stronger governance than a much larger but simpler publishing company.
Infrastructure maturity is not a revenue threshold.
Ask three basic questions:
Who can see this?
Who can change this?
Who would know if they did?
Those questions expose a surprising amount.
12. Treat AI as an execution layer, not another software category
AI deserves a separate audit because increasingly it does not merely observe the system.
It acts.
An agent might:
read CRM state;
segment customers;
draft lifecycle communication;
change records;
issue offers;
interact with support systems;
call internal tools;
trigger workflows.
Before giving AI those capabilities, audit what it will be allowed to believe and change.
Does it have trustworthy state?
Are definitions clear?
Are its tools understandable?
Are permissions constrained?
Are actions visible?
Can important actions be reversed?
Can uncertain cases escalate to a human?
This leads to a useful principle:
AI readiness is partly architecture readiness.
And another:
Automation amplifies architecture.
With coherent underlying systems, greater automation can create leverage.
With contradictory state and ambiguous ownership, greater automation can increase the speed at which errors become actions.
AI does not make architecture less important.
It raises the cost of getting it wrong.
Turn the audit into decisions
A stack audit that produces a large document but no decisions has failed.
For every issue choose one of four outcomes.
Fix now
The problem creates material customer, revenue, reliability, security or data-integrity risk.
Examples:
payment succeeds but entitlement sometimes fails;
cancelled customers remain in active lifecycle messaging;
business-critical integration failures are invisible;
former employees retain privileged access.
Design next
The weakness is structural, but remediation needs deliberate redesign rather than an immediate patch.
Examples:
three systems compete for lifecycle authority;
CRM taxonomy needs redesign;
onboarding automation has become overly coupled.
Monitor
The problem is real, but intervention would currently cost more than the problem.
Leave alone
The system is imperfect and good enough.
That fourth category deserves protection.
Professionalization does not mean eliminating every odd field, spreadsheet, manual process and aging application.
It means understanding which imperfections matter.
An architecture can be imperfect and still be appropriate for the next stage of growth.
When should a tool actually be replaced?
Software replacement should follow diagnosis.
A system usually deserves replacement because of an identifiable deficit.
Capability deficit
It genuinely cannot support a requirement the business now has.
Reliability deficit
It cannot reliably support the volume or operational importance of the process.
Integration deficit
Maintaining trustworthy state between it and the rest of the architecture has become disproportionately difficult.
Governance deficit
Its permissions, security, auditability or compliance capabilities are inadequate for the business.
Economic deficit
Its total cost of ownership no longer justifies the role it performs.
Operability deficit
The system can technically perform the required job, but the organization can no longer maintain, understand or safely operate it.
That final category matters.
A tool may be “capable” on paper while requiring obscure workarounds, specialist knowledge and fragile manual procedures in practice.
If none of these deficits exists, replacement deserves skepticism.
A new CRM containing the same ambiguous lifecycle model, contradictory fields and undocumented integrations is not necessarily modernization.
It may simply relocate the Stack Debt.
The point of the audit
The purpose of a growth tech stack audit is not to produce a prettier architecture diagram.
It is to restore comprehension.
By the end, you should be able to explain:
how customers move through the business;
which states matter;
which systems own those states;
how information moves;
which automations act on it;
how the business measures what happens;
where humans compensate for missing infrastructure;
what happens when components fail;
what the architecture actually costs;
who can control it;
and which problems genuinely deserve intervention.
Only then should the conversation become:
What technology do we need?
Because professionalizing growth infrastructure is not primarily the process of adding professional-grade software.
It is the process of making a growing business understandable, reliable and changeable again.
Once you have mapped your growth stack, the next question is ownership: when your CRM, billing, product and analytics systems disagree about a customer, which one should win? What Should Be the Source of Truth for Customer Data? explains how to establish clear authority over the customer facts that matter.
Leave a Reply