Choosing tools when you are five people
Search & Tooling · 2026-05-05 · 7 min read · 1500 words
By ESPYCRUX, Studio
Tool comparisons usually score features. For a small team the features are rarely what decides it — the deciding factors are who has to live in the tool, what it costs when you succeed, and whether anyone opens it in week three. Here are the criteria that have held up across four categories of tooling.
Note for review: this replaces four short "review" posts. Those posts contained specific measurements — migration times, script weights, session-count variances — presented as if the studio had run those tests. I have not reproduced them, because I cannot verify them and unverifiable numbers are exactly what we are trying to remove from this site. If you did run those evaluations, send me the real figures and I will put them back with the products named. What follows is the reasoning, which stands on its own.
There is a particular disappointment in tool evaluation. Everything demos beautifully. Every product in a category looks broadly the same during a trial, because trials are designed by the people selling them and they showcase the path that works.
The differences appear in week three, and they are almost never the features you compared.
Below are the criteria that have actually predicted outcomes for us, organised by the four categories a small product team usually has to decide on. The pattern across all four is the same, and it is worth stating up front: the deciding factor is usually a person, not a feature.
Content systems: weight editor autonomy above developer ergonomics
Headless content systems demo identically — clean editing interface, an API, some framework starters. The gap opens the first time a non-technical editor needs to add a section nobody modelled in advance.
Some systems let editors compose pages from reusable blocks without a deploy. Others require a schema change in code, which turns every small content request into an engineering ticket. That distinction does not appear in a feature matrix and it determines the entire experience of owning the thing.
The mistake is structural: engineers evaluate these tools, and editors live in them. The wrong choice quietly converts your developers into a publishing queue — and nobody notices for a month, because the first few requests feel like normal work.
Two other things worth checking before committing:
Migration is mostly rich text and assets. Rich text formats are proprietary in practice, so budget for a transformation script and accept that some formatting will be rebuilt by hand. This is the part that overruns.
Pricing punishes success in different ways. Per-seat costs make it expensive to give occasional contributors access — which pushes you back toward the engineering queue you were trying to escape. API call limits make a busy launch day expensive at exactly the wrong moment. Read the pricing page assuming things go well, not assuming they stay small.
Monitoring: alert quality beats detection speed
Small teams do not need an observability platform. They need to know within a couple of minutes that customers cannot do the important thing, with few enough false alarms that people still read the notifications at midnight.
Those are different requirements, and most tools are sold against the first one.
Simple availability checks catch the total outage and miss everything that actually hurts. A broken checkout while the homepage stays up. A queue silently backing up. An expired certificate on one subdomain. Those need transaction checks — a script that does the thing a customer does — not a ping that confirms the server answered.
Detection speed matters far less than alert quality. The difference between forty seconds and three minutes is real but small. The difference between an alarm people read and an alarm people have muted is total. A tool that pages twice for transient network blips gets muted within a week, and a muted alarm is worse than no alarm, because it feels like coverage.
The most valuable feature is the least discussed: status page integration. Automatically publishing an incident cuts support volume during a real outage, at the exact moment nobody has capacity to answer the same question forty times.
The shape of a good setup for a small team: a handful of realistic transaction checks, routed to phones. Everything else goes to a channel people read during working hours.
Design handoff: the tool is not the problem
Every handoff tool promises to end the back-and-forth between design and engineering. It does not, because the back-and-forth is caused by unstated decisions — what happens on error, what the empty state says, how this behaves at 320 pixels — and no exporter fixes an unasked question.
What separates the tools that help:
They live where the work already happens. A tool requiring a separate login and a separate URL gets checked at the start of a ticket and never again, so it is stale within days. Proximity beats capability here by a wide margin.
Token export is the genuinely useful feature. Colours, spacing and type scales pulled straight into code remove a whole class of small mismatches — and, more importantly, make the design file authoritative rather than advisory. That is a change in how the team works, not just a change in tooling.
Generated code remains a trap. It produces markup shaped like a picture rather than a component. Reviewing it takes longer than writing the real thing, and you inherit structure nobody chose.
The cheapest improvement in this category costs nothing and needs no tool: a short annotation on every screen covering loading, empty, error and the narrowest breakpoint. Teams that adopt that convention stop caring which tool they use, which is a strong hint about where the value was all along.
Analytics without cookies: agree on one definition and stop comparing
Cookieless analytics tools all promise the same thing — useful numbers without a consent banner — and then define a session differently. That is why two dashboards on the same site rarely agree, and why arguing about which is "right" is time you will not get back.
Script weight is a real cost, not a footnote. These scripts load on every page for every visitor. On a mid-range phone over a congested network, a heavy analytics script competes with your actual content for the same limited budget. Check the gzipped size before you check the dashboard.
Session definitions differ, and none of them is wrong. They draw the boundary of a visit at different idle thresholds. Pick one tool and stop comparing absolute numbers across tools — trends within one definition are meaningful, cross-tool comparisons are not.
Funnel support is the real differentiator. Some tools treat funnels as first-class and let you define steps from pageviews you already collect. Others require a custom event for every step, which pushes work back onto engineering — and engineering will deprioritise it, which means the funnel never gets built.
The shape that works: the lightest script that supports funnels defined retroactively, raw data exported periodically so you are not locked in, and an acceptance that trends matter and decimals do not.
The pattern across all four
| Category | What gets compared | What actually decides it |
|---|---|---|
| Content system | Editing features, API | Whether editors can work without a developer |
| Monitoring | Detection speed | Whether alerts stay unmuted |
| Design handoff | Export capability | Whether it lives where work happens |
| Analytics | Dashboard features | Script weight, and who has to add events |
In every row, the left column is what the vendor competes on and the right column is what determines whether the thing is still in use in six months.
The other pattern: three of the four are really questions about who is blocked on whom. Can the editor publish without an engineer? Can the designer specify without a meeting? Can the person who wants the funnel build it? A tool that removes a dependency between two people is worth more than one with a better feature list, because dependencies are what a small team runs out of first.
A short evaluation procedure
- Identify who will live in this tool daily — not who is evaluating it
- Have that person do one real task in the trial, unaided
- Read the pricing page assuming you succeed: more seats, more traffic, more usage
- Ask what happens when you leave — can you export, and in what format
- For anything that alerts: ask what makes it noisy, not what makes it fast
- For anything client-side: check the payload it adds to every page
- Prefer the tool that removes a dependency between two people
- Assume the trial showed you the good path, and go looking for the other one
What we are not telling you
We are not going to name a winner in each category, and it is worth being clear why rather than leaving it as an omission.
The honest reason is that we have not run controlled evaluations across these categories, and the version of this article that ranked named products would be inventing authority we do not have. There is a lot of that in this genre — comparison posts with confident numbers that nobody measured — and it is not something we want to add to.
The criteria above are transferable and, we think, more durable than any specific recommendation would be. Products change. The question of whether your editors can publish without a developer does not.
Tags: tooling, evaluation, small teams
ESPYCRUX — ESPYCRUX is a small product studio based in India, building focused web applications and writing about the engineering behind them. Articles are written by whoever did the work, and published under the studio name. Reach the studio at admin@espycrux.com.