Check your subscriptions. Most people who have been paying attention to AI tools for a while find the same pattern: four or five active charges, two tools genuinely in the weekly workflow, one they forgot they were paying for, and a browser full of half-finished trial accounts.
The correction is a sequencing change: build the stack from your jobs, not from the tools. Write down the five to eight things you actually do every week, allow one tool per job, and keep the whole thing as a written list — in use, on trial, rejected and why. The list is the real artefact. Without it you re-evaluate the same tools every few months and never notice that two of them do the same thing.
Here's the method, end to end.
Step 1: Write the job list before you look at any tools
A job is a piece of work you repeat, described in your own words, with no product names in it. For a creator that might be:
- Turn a rough outline into a first draft
- Repurpose a long piece into short social posts
- Make thumbnails and simple graphics
- Research a topic and keep the sources
- Schedule and publish across platforms
- Track what performed
Five to eight jobs is the right size. Fewer and you're describing your role, not your week; more and you're listing tasks rather than jobs.
This step feels skippable and isn't. A job list written before you browse is the only defence against buying a tool because it was impressive rather than because it does something you need. Every purchase from here has to name the job it fills.
Step 2: Run the overlap audit
Now map the tools you already pay for onto that list. Two things usually surface immediately.
Jobs with no tool — the genuine gaps, and the only places new spending is justified.
Jobs with two or three tools — the accidental duplication. This is where most wasted subscription money sits, and it happens for a specific reason: general-purpose assistants keep absorbing jobs that used to need dedicated tools. A capability you bought a separate product for last year may now be a feature of something already in your stack. Check before renewing, not after.
Write the mapping down. A job list with tools beside it, on one page, is more clarity than most teams have about their software.
Step 3: Shortlist three candidates per gap — from curated sources
For each real gap, get to three candidates and stop. One gives you nothing to compare; six turns into a project you abandon halfway.
Where you look matters more than it used to. The discovery layer for tools is heavily promotional — launch posts, sponsored threads, and roundups written by people who never used the products. Filter with a few habits:
- Prefer sources that state their criteria. A shortlist that explains what it optimised for is usable even when you'd have weighted things differently. A ranked list with no visible reasoning is an advertisement.
- Look for the trade-off sentence. Any honest writeup says what a tool is bad at. If nothing in a recommendation is negative, it isn't a recommendation.
- Check the free tier's shape, not just its existence. What matters is which limit you'll hit first — volume, seats, export, or a feature that's core to your job.
- Note whether it's a product or a wrapper. Plenty of AI tools are a thin layer over a model you could prompt directly. Sometimes the layer is worth paying for because it holds context and workflow; sometimes it's a subscription for a prompt.
Save all three candidates as you go rather than keeping them in tabs. Tabs are where shortlists go to die.
Step 4: Trial one at a time, against the job
Run each candidate against the actual job with your own material — your outline, your brand, your data — not the sample project. And run one at a time: parallel trials produce a blur of impressions rather than a comparison, because you never give any of them a real week.
The structured version of this — what to test, what to record, and when to decide — is laid out in our guide to evaluating a new tool before you commit. The one thing worth repeating here is the decision rule: set the pass/fail criteria before the trial starts. Criteria written afterwards are just a description of whatever the tool happened to do well.
Step 5: Keep the stack as a saved list, with a note per entry
This is the step that compounds. For every tool that touches your shortlist, keep an entry with four things:
- The job it's for — in your own words, from step one.
- Status — in use, trialling, rejected, or watching.
- The reason, in one line. "Rejected: no export" is worth more in six months than any amount of remembered impression.
- Cost and renewal date, if you're paying.
The rejected entries are the sleeper value. Without them you will rediscover the same tool next year, feel intrigued, sign up, and rediscover the same dealbreaker. A one-line reason ends that loop permanently.
Organise the list by job rather than by category. Categories are how directories are structured; jobs are how you'll search. If you're using tags, tag by job and by status — the folders-versus-tags reasoning in our guide on why saved links become a graveyard applies exactly, because a tool stack is a saved-link collection with money attached. And like any collection, it needs the maintenance habits covered in our saving and organisation guide, or it silently goes stale.
Step 6: Share it
A stack list is unusually useful to other people, which is not true of most things you save.
- For a team, it's onboarding. A new hire's first question is which tool to use for what, and a list answers it in one link — including what was rejected, so they don't propose it in week two.
- For a creator, "my stack" is genuinely one of the most-requested things an audience asks for, and a maintained public list beats answering the question repeatedly.
- For a client or collaborator, it sets expectations about what you work in.
Share the read-only version and keep your private notes — cost, frustrations, renewal dates — separate from the public one.
Step 7: Audit quarterly, with one question
Put a recurring reminder in the calendar and apply a single test to each paid tool: would I buy this again today, at today's price, knowing what I now know?
Not "is it useful" — almost everything is somewhat useful. The re-buy question is harsher and gives clean answers. Anything that fails gets cancelled that day, before the next renewal. Anything that passes gets its renewal date confirmed in the list.
Two failure modes to watch for while you're in there. Tool-of-the-week churn: if a job's tool has changed three times in a year, the problem is probably the job definition, not the tools. And the one-user stack: a tool nobody but you opens isn't a stack component, it's a personal preference with a team invoice attached.
FAQ
How many AI tools does a small team actually need?
Fewer than the discourse implies. Most creators and small marketing teams run on a general assistant, one or two specialist tools where quality genuinely matters, and the platform tools they already had. If your list has a tool per task rather than a tool per job, it's too long.
Should I use one general AI tool or several specialised ones?
Start general, specialise where you feel real friction. A general assistant covers a surprising share of the job list at one subscription; specialised tools earn their place when they hold context, integrate with your workflow, or produce output quality the general tool can't. Let the friction tell you, rather than buying specialists pre-emptively.
How do I stop paying for things I don't use?
Keep the renewal date in the same list as the tool, and audit on a fixed schedule rather than when you happen to notice a charge. The re-buy question at each audit is the whole discipline. Cancelling one unused subscription a quarter typically pays for the tools you do use.
What should I check before committing to a tool I like?
Export, mainly. Whatever you create or store in it should come out in a standard format, because that's what makes leaving possible. After that: what happens on the free tier if you stop paying, whether your content is used to train models, and whether the pricing you signed up on is introductory.
Is it worth publishing my stack publicly?
If you have an audience that asks, yes — it's a genuinely useful page and it takes minutes to maintain if the list already exists. Keep the public version to tool, job, and a one-line reason, and leave your costs and complaints in the private copy.
Build the shortlist, then save it
Jobs first, one tool per job, three candidates, one trial at a time, and a written list that remembers your rejections. That's the whole method, and it takes less time than the two trials you'd otherwise abandon.
BookmarkDiscover keeps curated shortlists of real tools by category — AI writing, SEO, productivity, design, and no-code — with picks for creators, startups, and marketers, and you can save any listing straight into your own stack list.
Browse curated tool shortlists and build your stack on BookmarkDiscover →
