A small team needs a model it trusts, somewhere to put the work, something to send with, and something to measure with. Most stacks fail from too many tools rather than too few, because every tool is an integration you now maintain and a potential second source of truth. The constraint is rarely output volume — it is distribution and specificity, and no tool supplies either.
The rule that keeps it small
A new tool has to replace an existing one, or remove a manual step you can name out loud.
“It looks useful” is how you arrive at eleven subscriptions, four places a contact record might live, and a weekly hour spent reconciling them. Every tool has a carrying cost that is invisible on the pricing page: an integration, an auth token that expires, a place for data to diverge.
Applied honestly this rule rejects most things, which is the point.
The categories that actually matter
| Job | What it replaces | Note |
|---|---|---|
| A model you trust | Blank pages, slow reading | One good one beats three |
| System of record | Spreadsheets and memory | The one place truth lives |
| Sending | Manual follow-up | Deliverability is the real feature |
| Measurement | Guessing | Must survive cookie loss |
| Automation glue | Copy-paste between the above | Only after the above exist |
Note what is missing: content calendars, scheduling suites, brand voice tools, dashboards that aggregate other dashboards. Not because they are bad, but because for a small team they usually add a step rather than remove one.
What I actually run
Rather than list vendors, here is what each slot does and why I chose that shape.
A model, used with real inputs. The model matters less than what I feed it. Most bad output is a missing-input problem, not a prompting problem — a model asked to write in my voice produces an approximation, and a model given three pieces I am proud of produces something usable. The patterns that carry production work are few.
A CRM I own. I built mine, which is not a recommendation for most people. The three conditions that justify building are narrow, and outside them buying is the better commercial decision.
Sending, with deliverability treated as the real feature. The provider matters less than the domain setup. A migration taught me that sending as the wrong hostname puts perfectly good mail in spam regardless of vendor — the specific trap is here.
First-party analytics. Cookieless, self-hosted. Third-party pixels are increasingly blocked, so a measurement layer that depends on them is measuring a shrinking sample and not telling you.
Automation glue, last. Deliberately last. Automating a process you have not run manually produces a fast wrong process.
What is overrated
Anything that generates volume without validation. Volume is not the constraint for a small team. I measured what unvalidated volume costs: in an enrichment run, 44% of contacts came back attached to the wrong employer, and sending to that list at machine speed damages your sending domain rather than wasting an hour.
Dashboards that aggregate dashboards. A dashboard nobody acts on is a subscription for a feeling. If you cannot name the decision a number changes, do not display it.
Brand voice tools. Three of your own pieces in context does the same job for free.
Scheduling everything. Scheduling helps consistency, but on platforms where every post is re-auditioned to strangers, cadence matters more than calendar hygiene. The platforms differ on this more than people assume.
Buy or build
Buy until a tool blocks something specific you can name.
Building is right in two cases: the AI step is your differentiator, or a per-use price scales with something you cannot control. Per-seat pricing that grows with headcount is fine. Per-contact or per-message pricing when volume is your model is a tax on success, and at some point the arithmetic decides for you.
Outside those cases, the build is a distraction from demand. The constraint on a small team is almost never tooling.
The order to assemble it
- System of record first. Everything else references it. Get this wrong and you will migrate later, which is painful.
- Then measurement. Before you optimise anything, be able to see it. Instrument before publishing, not after — data only accumulates once things are live.
- Then sending, with the domain and authentication set up properly on day one.
- Then a model, used with real inputs on real tasks.
- Then automation, only for processes you have run by hand and understand.
Most teams do this in reverse, starting with the exciting AI layer on top of no record and no measurement. That produces output nobody can attribute and a stack nobody can debug.
FAQ
What does a small team actually need?
A model, a system of record, sending, and measurement. Automation after those exist.
Buy or build?
Buy until something specific blocks you. Build when the AI step is your differentiator or per-use pricing scales with something uncontrolled.
What is most overrated?
Volume generation without validation. Volume is rarely the constraint; distribution and specificity are.
How do I stop sprawl?
A new tool must replace one or remove a nameable manual step. Nothing else qualifies.
Related: automating a CRM with AI, measuring AI’s impact, and how I build automations.