Stack Audit / Consolidation Worksheet for Solo Operators

Use this worksheet when the stack is already real enough that you need to document what each tool does before you change anything.

This is an execution asset, not a strategy page. It helps you turn stack decisions into a visible audit so you can consolidate with less guesswork and less duplicate admin.

Use this before migration sequencing. Once the tool inventory is visible, the next narrower question is usually ownership rules, not tool shopping.

This worksheet should not be your first entry point into stack design. Use it only after the broader stack model or comparison decision is already clear enough to audit against.

What this page is for

Use this page to turn an already-decided stack direction into a visible cleanup plan. It is for documenting the current operating reality before consolidation starts.

What this page is not for

Do not use this worksheet as your first stack-design page, a tool-shopping shortcut, or a substitute for choosing the system center. It does not decide what the stack should be. It only shows what the current stack is doing well enough to clean it up.

When to use this worksheet

Use it when:

• the current stack feels scattered or duplicated,
• you are not fully sure which tool should be authoritative for active client truth,
• migration feels necessary but the move is still too vague,
• you need one page that shows what stays, what moves, and what gets retired.

If you still need the broader stack model first, start with Software Stack Blueprint: Solo Freelancer (Lean Budget).

If you still have not decided whether the business should stay consolidated or split functions across a specialized stack, start with All-in-One Workspace vs Specialized Stack for Solo Operators.

If the main issue is not tool inventory but unclear data ownership between systems, use System-of-Record Rules Worksheet for Solo Operators before trying to plan the cleanup.

Safest next step after this worksheet

Once the current inventory is visible, move next to System-of-Record Rules Worksheet for Solo Operators if ownership is still fuzzy, or How to Migrate from Scattered Tools to One Workflow System if the cleanup sequence itself is the next blocker.

What this worksheet does not decide

This worksheet should not decide:

• whether CRM-first or PM-first is the right system center,
• whether the stack should stay all-in-one or become more specialized,
• whether a new tool deserves to be purchased,
• how the full migration sequence should run week by week.

Those decisions belong on the blueprint, comparison, and migration pages. This asset only helps you document the current stack clearly enough to act on those decisions.

How to use it

1. List every tool that touches live client work, not just the tools you pay for most.
2. Fill the worksheet from current operating reality, not from the stack you wish you had.
3. Mark only one system as authoritative for each live operating role.
4. Leave clear keep / replace / retire decisions, even if some rows stay provisional for a week.

Practical rule: if two tools both look like they hold current client truth, that is exactly the ambiguity this worksheet should expose.

What this worksheet assumes you already know

• the likely system center,
• whether the stack should stay more consolidated or become more specialized,
• whether the goal is cleanup rather than broad redesign.

If those decisions are still open, go back upstream before using this page.

Stack audit worksheet

Current tools inventory

Before making any decisions, capture:

• every paid app in the stack,
• every free tool still used for live work,
• every spreadsheet, doc, or shared folder that still carries operational truth,
• every workaround tool that only exists because the main system is weak.

If a tool is only used for archive or compliance reference, label it that way now. Archive tools should not be confused with live operating systems.

System-of-record identification

For each stage, write one answer only:

• Where does active client stage live?
• Where does the next action live?
• Where is deliverable approval logged?
• Where does invoice status stay visible?

If the answer changes by project without a clear rule, the system is more fragmented than it looks.

If this part is still unclear, go back to CRM vs Project Management Tool for Client Workflows before trying to optimize the stack.

Delivery / workspace role

Document which tool currently handles:

• active project status,
• milestone tracking,
• owner visibility,
• recurring delivery templates.

Add one note for the actual risk:

• too loose,
• too rigid,
• duplicated with another tool,
• missing key workflow visibility.

Client communication / review role

Document which tool currently handles:

• client communication history,
• review requests,
• approval records,
• final handoff notes.

Do not assume the inbox should also be the operating system. If the tool only carries messages, keep its role narrow.

Booking / intake role

Document which tool currently handles:

• inquiry capture,
• qualification notes,
• booking or call routing,
• proposal follow-up trigger points.

If intake still depends on manual memory more than visible stage tracking, the problem may be process design rather than missing software.

How to mark keep / replace / retire

Use Keep when:

• the tool has a clear role,
• the ownership boundary is understandable,
• it reduces real weekly coordination cost,
• replacing it now would create more disruption than value.

Use Replace when:

• the role is real, but the current tool is a poor fit,
• live work depends on awkward workarounds,
• a clearer replacement is already justified by workflow pressure.

Use Retire when:

• the tool duplicates truth that should live elsewhere,
• no one can explain why it is still part of live work,
• it mainly survives because nobody has closed it down yet.

Migration boundary notes

For every replace or retire decision, note:

• what must be preserved,
• what can be archived instead of migrated,
• what cutoff date should end new updates there,
• what should not move because it only adds history noise.

This matters because most cleanup projects fail by migrating too much low-value clutter.

Ownership / dependency notes

For each live tool, note:

• who updates it,
• who reads it,
• what stage depends on it,
• what breaks if it is wrong.

This is where hidden dependencies usually surface. A tool that looks minor can still be risky if invoicing, approvals, or kickoff timing silently depend on it.

Signs a tool should be removed rather than optimized

• it holds duplicate client status that someone has to mirror manually,
• it only exists because a stronger workflow rule was never written,
• it has been “temporary” for months,
• it adds one more place to check but not one clearer answer,
• nobody would rebuild it if starting fresh today.

What to do after completing the worksheet

• If the audit shows the stack is still too vague, return to Software Stack Blueprint: Solo Freelancer (Lean Budget).
• If the main issue is premature tool spend, return to How to Choose a Software Stack Without Overbuying Tools.
• If the target shape is clear and the problem is cleanup, move next to How to Migrate from Scattered Tools to One Workflow System.
• If the unresolved question is still stack shape, return to All-in-One Workspace vs Specialized Stack for Solo Operators.

Completion standard

This worksheet is complete when:

• each live tool has one explicit role,
• keep / replace / retire is marked on every live row,
• at least one system-of-record rule is clearer than before,
• the next page to open is obvious instead of vague.