Mirror

Which Software Can You Cancel? A Dependency Test for Small Teams

Before cancelling team software, check exports, shared access and fallback workflows. Use a dependency worksheet to separate real savings from hidden work.

A software bill tells you what a tool costs. It does not tell you what would break if you stopped paying. Before cancelling, identify the work that depends on it, try a reversible substitute on a small sample, and record the cost of that substitute. Keep the original service available until the test is complete.

This is a proposed method for a small team’s software review, not a report of a completed experiment. It follows a quarterly stack audit: once you have the bills and owners, use this worksheet for the lines whose value remains unclear.

Correction, September 24, 2026: the earlier version described an unsupported fourteen-tool experiment, including personal predictions, failures and savings. Those claims have been removed. The procedure and hypothetical calculations below are not measured customer results.

Fourteen light switches illustrating separate software dependencies

Illustration only; this does not depict a tested software stack.

Start with the task, not the application

“Can we work without Notion?” is too broad to answer. “Can another teammate find the current client brief, edit its checklist, and hand it back without losing the attachments?” gives you an observable task. Write down the input, the expected output, the person who needs access and the deadline. A tool may be replaceable for one workflow and essential for another.

Choose a routine task that can be repeated without changing a live customer record. For a scheduling service, that could be arranging a test appointment between colleagues. For a document service, use a copy of a non-sensitive project folder. For a reporting tool, reproduce an old report whose expected result is already known.

Define the pass condition before trying the substitute. For example: the colleague can find all three specified attachments, identify the latest version and return a usable edit. “It seemed fine” leaves too much room to overlook missing work. A successful trial establishes that this task worked under these conditions; it does not establish that the entire service can be removed.

Three documented constraints worth checking

Vendor documentation checked September 24, 2026. These are examples of limits to investigate, not a ranking of products. The last column contains our proposed checks, not vendor promises.

Service and official source Documented capability or limit What to check before relying on a substitute
Notion export A workspace export omits pages the exporter cannot access; some content may be excluded by teamspace settings. Reuploading the export cannot instantly recreate the workspace. Ask each content owner to check coverage. Open a representative exported project in the intended destination.
Google Docs offline Desktop offline setup requires an internet connection initially, Chrome or Edge, the offline extension and local space; private browsing is excluded. An administrator can disable offline access. Verify the required files are marked ready, then try the copied task offline on the actual device.
GitHub repository backup A mirror clone preserves the Git repository and revision history; LFS objects require a separate fetch. Migration archives omit some data and have no supported, documented GitHub restore method. Separate source history from the surrounding hosted workflow. Name every item needed for recovery rather than treating one archive as a full replacement.

These distinctions matter because downloading something, reading it and continuing work from it are different outcomes. Offline access also depends on the existing product: it is not evidence that cancelling the account preserves access. Treat each as a separate question in the review.

Fill in the dependency worksheet

Use one row per workflow rather than one row per subscription. A single subscription can support several rows. Leave unknowns visibly unresolved instead of scoring them as zero risk.

Field What to record
Workflow and owner The task, who completes it, and who accepts its output
Required material Files, history, attachments, settings and integrations needed
Substitute The existing tool or manual process you propose to use
Access check Whether a second authorised person can complete the task
Pass condition The specific output and acceptable completion time
Stop condition The missing item, error or delay that ends the trial
Restoration plan Who returns work to the original tool and reconciles changes
Decision date A date before the actual cancellation cutoff, verified from the account

For shared work, the second-person check is important. A founder’s successful export does not establish that a colleague has permission to use the destination. Nor does a copy on one laptop establish that the team can recover it if that person is away.

Start with a bounded sample: one completed project and one routine task. If both work, widen the sample to a less frequent workflow, such as a monthly report. Keep the result attached to the row so the eventual spending decision can be explained without relying on memory.

Keep the trial reversible

Do not begin by cancelling the subscription, removing users or disconnecting production integrations. First verify the data retention terms and the restoration path. A cancellation that removes useful history can turn a small evaluation into an unplanned migration.

During the trial, designate one place as the authoritative record. If people edit the original and the replacement independently, the work of merging their changes belongs in the trial’s cost. Note every manual copy, permission repair and missing notification. Otherwise a substitute can appear cheap because its maintenance has been distributed across the team.

Stop when a pre-agreed condition is met: an attachment cannot be recovered, a recipient cannot access the output, or the task would miss its deadline. Restore the normal workflow and record why. A stopped trial is useful evidence. It may point to a missing preparation step rather than a permanently irreplaceable product.

Compare the savings with the replacement work

The following is a hypothetical example, not a vendor quote or a measured result. Suppose a cancellable tool costs $30 per month, its replacement adds 45 minutes of work per month, and the team assigns that work a planning value of $40 per hour.

Item Calculation Illustrative amount
Subscription avoided $30 × 12 $360 per year
Recurring replacement work 0.75 hours × $40 × 12 $360 per year
Initial transition work 2 hours × $40 $80 once
First-year difference $360 − $360 − $80 −$80

On these assumptions, cancelling reduces cash outflow but consumes more valued work than it saves in the first year. That is not an $80 cash loss unless the time creates an actual additional payment. Keep the bank-account effect and the capacity effect separate.

With the same assumptions but only 15 extra minutes per month, replacement work is $120 per year and the first-year difference becomes $160. The input that changes the decision is the recurring effort, so measure it in your trial rather than borrowing either number from this example. Include any new paid service in the cash calculation, and use only avoidable charges: a prepaid non-refundable term does not disappear when you stop using it.

A quiet week cannot test every dependency

Do not disable backups, account protection or required records to see whether anyone complains. Their value can depend on an infrequent event that your observation window never contains. For these services, review requirements and practise recovery using a non-production copy while normal protection stays active.

A weekly workflow also cannot tell you whether a quarterly close, annual export or former client’s request will work. Write down which situations the sample excluded. Where a needed capability remains untested, the decision should remain pending, with an owner and a next step, rather than becoming an automatic cancellation.

Use three possible outcomes: keep at the present tier, test a smaller tier, or prepare an exit. A failed sample may support keeping one feature without justifying every paid seat. A successful sample may support a migration without justifying immediate cancellation. Once an exit is supported, use a migration checklist to handle the actual move and confirm the final billing state.

The useful output is a decision with evidence: what was tried, what worked, what is still unknown and what changes financially. There is no universal list of four tools every team must keep, and no week-long test that can prove one.