Tools are leverage. The right one removes a whole category of work; the wrong one quietly becomes a part-time job. This topic covers the technology we reach for at tbskit — and, just as often, the tools we decide not to add.
How we choose a tool
Before anything joins the stack, it answers four questions:
- Does it remove work, or move it around? A tool that saves an hour a week is an investment. A tool that only moves the same hour from one person to another is a cost with a login page.
- Can we leave it? Every tool needs an exit: an export, an open format, or at least a copy of our data we can read without the vendor. If leaving means losing work, we have not bought a tool, we have rented our workflow.
- Who maintains it, and what happens if they stop? Small teams building a useful thing are welcome — as long as the risk of them disappearing is proportional to what we put inside.
- What does it cost at our real size? Per-seat, per-project, and per-month, multiplied by every project we keep alive. The number that matters is the total, not the entry price.
If two of the answers are uncomfortable, we do not adopt the tool. The cost of saying no is a small annoyance; the cost of saying yes is permanent.
The short list we actually use
Not a catalogue — just the tools that survived the questions above and are now muscle memory.
Building and shipping
Astro with TypeScript for the sites themselves, Git and GitHub for versioning and review, Docker Compose so a local environment can be rebuilt instead of remembered, and sharp for image processing in the build.
Running and serving
Cloudflare Pages for hosting and delivery, R2 for media behind a custom asset domain, Cloudflare for DNS and TLS, and a hosted form service for contact forms — so there is no server to maintain just to receive a message.
Designing and writing
Design files for structure and tokens, plain Markdown for documentation, and the repository as the single source of truth. If a decision is not written where the code lives, it will be re-litigated in six months.
What we deliberately leave out
- A client-side framework for a content site. Most pages do not need one.
- Page builders that store copy somewhere it cannot be diffed, reviewed, or rolled back.
- Analytics that collect more than the question requires. A visit count does not need a fingerprint of the visitor.
- A different tool for every small need. Twenty subscriptions and twenty places to look is not a stack, it is a burden with a dashboard.
Trying something new without betting the project
Curiosity is part of the job, so new tools get a fair test — on a short leash:
- Spike in a branch. A trial never touches production and never happens in a hurry. If a tool cannot be tried safely, that itself is information.
- Time-box it. One afternoon, or one week for something structural. A trial without an end date becomes an unowned dependency.
- Do the boring path first. Import real data, run it on a slow connection, and try the unglamorous task — the export, the migration, the undo. Demos are always fast.
- Two weeks of muscle memory. If after two weeks we still need a reminder to use it, we were sold a habit we did not have.
- Write the verdict down. One paragraph: what we tried, what it replaced, why we kept or dropped it. The next person asking the same question starts from that paragraph instead of another trial.
Grading a tool after three months
Few decisions are permanent, so we re-check the ones that matter with four plain questions:
- Did it reduce work, measured in something we can point at?
- Was it adopted without being reminded every week?
- Is the cost still proportional to what we get?
- Would we choose it again today, knowing what we know now?
Two “no” answers mean the tool either gets a narrower role or gets retired. Keeping a tool out of politeness is how stacks grow without getting better.
Retiring tools without leaving a mess
Removing a tool is a small project, and skipping these steps is how a project accumulates zombies:
- Export the data first, in a format we can open without the vendor, and store it with the project.
- Turn off billing and access, then revoke API keys and integrations so nothing keeps talking to a service nobody watches.
- Update the documentation with one paragraph: what it did, why we left, what replaced it.
- Check what still references it — a build script, a DNS record, an automation — and remove the leftover.
- Then delete the account. An unused service is both a forgotten subscription and a forgotten attack surface.
What we publish under Tech & Tools
Articles in this topic are concrete and tested: editor and local setup that makes a project pleasant to work in, Git workflows for small teams, image pipelines that do not bloat a repository, forms and search without a backend, analytics that respect visitors, and honest notes after using a tool on a real project for a few months.
Related reading: our code standards, how we host what we build, and the ops habits that keep it running.
Curious what we would use for your project — or paying for a tool you are no longer sure about? Tell us about it.