The TechBobby Stack: Minimalist Developer Tools, Automation & Digital Goods for Modern Builders

Dark developer workstation with floating code editors, a terminal and a circuit diagram

Every developer’s setup is a small act of self-definition. Some people build theirs deliberately; most inherit it from a stack overflow answer in 2019 and never look back. The difference between those two approaches compounds for years.

This is the stack we actually run at TechBobby — four layers, no subscriptions we do not use, and a hard rule that every tool must either save an hour a week or make us money. Nothing here is exotic. Everything here is boring on purpose, because boring infrastructure is the only kind that survives a busy quarter.

Why minimalism wins

Tool sprawl feels like progress. A new notes app, a new terminal emulator, a new AI wrapper every other week — each one promises a small lift and quietly charges a switching tax. The tax is real: every context switch costs attention you can’t bill for, and every half-configured integration is a future afternoon of debugging.

Three rules keep the stack small:

  • One tool per job. If two tools overlap, one of them is leaving this month.
  • Plain text is the API. Markdown, CSV, JSON, shell scripts. Anything a human can read survives the vendor.
  • Automate the third time. Do it twice by hand, template it the third time, and never think about it again.

Layer 1 — The editor and the shell

The editor is where the thinking happens, so it deserves real setup time and then silence. VS Code with settings sync is the pragmatic default: one profile, one set of keybindings, working identically on a laptop and a remote box. The only extensions that earn their startup cost are a linter per language, a test runner, and a Git client that does not hide the diff.

The shell is where the real speed lives. A minimal trio covers almost everything:

  • ripgrep — search a whole monorepo in milliseconds instead of debating which folder the config lives in.
  • fzf — fuzzy-find files, branches, and history, then act on the selection without retyping a path.
  • make and a Makefile — every recurring command becomes make test, make ship, make clean. New contributors read the Makefile instead of asking you.

If you have to remember a command with more than two flags, it belongs in a script.

Layer 2 — Automation glue

Automation is not about replacing judgement. It is about deleting the twenty minutes of copy-paste that happen before judgement can start. Python is the right glue language for one reason: it is already installed on the machine of whoever inherits your work.

A pattern we reuse constantly: read messy input, normalise it once, write a clean artefact nobody has to open by hand. The script below turns a folder of exported CSVs into a single formatted Excel workbook — the kind of thing that used to eat an afternoon every month.

from pathlib import Path
import pandas as pd

def build_report(source: Path, target: Path) -> None:
    sheets = {}
    for csv_path in sorted(source.glob("*.csv")):
        frame = pd.read_csv(csv_path)
        sheets[csv_path.stem[:31]] = frame.dropna(how="all")

    with pd.ExcelWriter(target, engine="openpyxl") as writer:
        for name, frame in sheets.items():
            frame.to_excel(writer, sheet_name=name, index=False)
            sheet = writer.sheets[name]
            for column_cells in sheet.columns:
                width = max(len(str(cell.value or "")) for cell in column_cells)
                sheet.column_dimensions[column_cells[0].column_letter].width = min(width + 2, 60)

if __name__ == "__main__":
    build_report(Path("exports"), Path("report.xlsx"))

Two details matter more than the code: every worksheet name is trimmed to Excel’s 31-character limit, and column widths are capped so the output is readable without a single macro. Automation that produces something ugly just relocates the work.

Layer 3 — Digital goods as leverage

The fastest way to find out whether your automation is worth anything is to sell it. Digital goods are the cheapest experiment available: no inventory, no shipping, and the marginal cost of the hundredth copy is zero.

  • Code packs — the scripts you already wrote, documented, with a licence. Price them at the value of the hour they save, not the minutes they took to write.
  • Written explainers — one well-structured essay outperforms ten hot takes and keeps earning for years.
  • Merch as a billboard — a developer joke on a shirt costs nothing to produce and finds your audience in the physical world.

The distribution rule that took us longest to learn: publish where the audience already is, and link every asset back to one place you control. That place is this site.

Layer 4 — Quiet infrastructure

The infrastructure layer should be invisible. What matters is that it is yours: a domain you own, a database you can export, HTML that renders without a JavaScript bundle. Our site runs on a conventional managed stack with HTTPS forced everywhere and a caching layer in front of it, because the fastest page is the one nobody has to optimise twice.

Backups, a TLS certificate, and a monitoring ping are not glamorous; they are the difference between an asset and a hobby. Three items, checked once, then forgotten:

  1. Automated weekly backup, restored at least once so you know it works.
  2. HTTPS with a redirect from http and from www, verified in a private window.
  3. An uptime check that pings from outside your network.

A weekly operating rhythm

Tools do not ship anything; rhythm does. The version that has survived contact with real weeks:

  1. Monday — build. One improvement to the stack, merged and documented.
  2. Wednesday — publish. One digital good or product update goes live, no exceptions.
  3. Friday — measure. Twenty minutes on numbers that change decisions: installs, downloads, subscribers, revenue.
  4. Sunday — automate. Whatever you did twice by hand this week becomes a script.

Where to find the goods

Everything we publish is in one of these places. Start with the free ones — they cost nothing and they are the honest test of whether this stack is useful to you.

The point of a stack

A good stack is not the one with the most tools. It is the one you stop thinking about, so the thinking can go into the work. Four layers, a fixed weekly rhythm, and a place you own to publish from — that is enough to turn scattered files into something that compounds.

If you only take one thing from this page, take the third-time rule. It is the cheapest habit in software and the one almost nobody keeps.


Keep reading

Get the next essay and every new code pack before anyone else — subscribe to the weekly letter. Free tier first, always.