That is not because large teams cannot build good software. They have shipped important foundations: languages, runtimes, databases, browsers, and operating systems. The difference is the feedback loop. A small team often feels one sharp annoyance directly and can decide to fix it without moving through a large product map.

My longer essay, Big Tech Owns the Web. So Why Do the Best Ideas Still Come From Lone Devs?, is a personal argument about that gap. It is not a measured ranking of every company or independent project.

Pain is a useful specification

When a developer is also the user, small problems are hard to ignore:

• a build that takes too long;
• a configuration file that explains nothing;
• an API that needs five wrappers before it is pleasant;
• a tool that is powerful but makes the first step feel ceremonial.

The fix does not need a committee to be valid. It needs to make the next use better.

That is why small tools can feel unusually direct. They are often built around one clear promise instead of ten product lines and several layers of compatibility.

The newer tool wave

Bun is an example of a project selling a simpler runtime and toolchain story. Elysia focuses on a clean TypeScript server experience. Effect tries to make difficult application concerns explicit instead of scattering them across libraries.

These projects have different goals and trade-offs. I do not treat them as proof that every older tool is obsolete. I see them as signals: developers keep building new layers because the base experience still leaves room for improvement.

The same pattern appears in open-source editors, database tools, terminal programs, and small deployment utilities. A project can be technically modest and still change how a person works every day.

What big teams are good at

Large companies bring resources that small projects do not: compatibility work, security teams, documentation staff, infrastructure, and long maintenance horizons. That work is less visible than a clever new tool, but it matters.

The problem is that scale can also make friction harder to remove. A change that helps one developer may conflict with a platform promise, a partner, an older version, or a business metric. The system becomes stable, but not always pleasant.

Small teams can move faster because they have fewer promises to preserve. They can also break more easily because fewer people are checking the edges.

The craft is the point

I am drawn to projects that make a narrow workflow feel considered. Fast startup, a readable error, one fewer configuration step, a command that tells the truth—these details compound.

The lesson is not “always choose the solo project.” It is to notice where the best feedback is coming from. The person closest to the pain may have the clearest idea of what to remove.

Big Tech can build the foundation. A lone developer can still show what the front door should feel like.

This is a short companion to the full developer-experience essay. Edited with AI assistance.

In an AI-assisted workflow, the same surfaces can become useful handles. An agent can inspect a file, call a command, read a service status, compare a configuration, and explain the result without trying to recognize a changing screen.

My full essay, Linux Might Finally Have Found Its Moment, is an opinion piece, not a claim that Linux has suddenly become the best desktop for everyone. The narrower idea is that readable system state is valuable when software has to inspect and repair a machine.

Text is an API-shaped surface

Suppose the question is “what changed?” A GUI may require opening a settings panel, finding the right page, and remembering which value was there before. A text surface can answer with a file diff or a command result.

These are ordinary examples:

cat /etc/os-release
systemctl --user status
journalctl --user -n 30
wpctl status

The exact commands depend on the distribution and services installed. They are not magic universal controls. They are readable entry points that an agent can call, parse, and check.

The useful loop is:

inspect → change one thing → check the result → explain what happened

That loop is easier to audit when the system gives you text instead of only a visual state.

The old weakness becomes a design choice

Linux did not become approachable because every GUI was rebuilt. Its strength is that many important layers remain scriptable. An agent does not need a perfect settings panel if it can read the state and use a documented command.

That does not mean text is always better. A person may prefer a clear panel for a one-time action. An agent can also make a wrong change very quickly. Good automation needs permissions, a small scope, confirmation for risky operations, and a way to show what changed.

The best interface may be both: a human-friendly control and a text path underneath it.

Gaming made the platform less abstract

SteamOS, Proton, and the Steam Deck helped Linux reach people who did not arrive for an operating-system philosophy. They arrived to play a game.

That matters because a platform becomes useful when it meets a real task. The same hidden-system pattern can help with local development, automation, and AI-assisted computing. A readable service file is not exciting, but it is a good place to start when something needs inspection.

Linux is not a universal answer

The text-first path can be frustrating. Hardware support, audio stacks, desktop defaults, and distribution differences still make Linux work uneven. Agents do not remove those differences; they need to understand them.

What changed is the value of the underlying handles. Files, logs, commands, and services are not only things a human expert can memorize. They are also data an assistant can inspect and discuss.

That is why I think Linux may have a useful moment in the agent era: not because every GUI is perfect, but because the system underneath has been exposed for a long time.

This is a short companion to the full Linux essay. Edited with AI assistance.

1. Take a backup.
2. See the data quickly.
3. Follow one record across related tables.
4. Run a small query.

I kept opening large tools such as DBeaver or MySQL Workbench, then used one small corner of them. A five-year-old laptop made the mismatch hard to ignore. I wanted something that opened quickly, stayed keyboard-friendly, and did the useful part without a long ceremony.

That became dbterm, a Go database workbench. The source is on GitHub, and the full Why I Built dbterm log has the interactive demo.

The useful loop comes first

The first version was read-focused, not read-only. I wanted to scan a table, sort it, refresh it, copy a key, and move to related rows without losing my place.

That sounds small, but it covers a surprising amount of daily work. A customer row can lead to orders. An order can lead to payments. The important action is often not a large query; it is moving through the data with enough context to ask the next question.

Queries and broader data workflows still matter. The point is to keep the everyday loop small even when the product grows.

Why Go fit the project

Go kept the development loop short. Builds were fast, tests were plain, and a single binary made it easier to try the tool on another machine.

The big feature flows came first. Then hundreds of smaller requirements arrived: keyboard paths, empty states, refresh behavior, error messages, backup details, and regression checks. The rhythm was simple:

build the path → test the real behavior → merge a small change → repeat

AI helped with parts of the implementation and editing, but the product still needed actual builds and tests. A generated suggestion is not evidence that a database operation is safe.

The backup agent grew beside the TUI

The backup side follows a careful pipeline:

source → verify → compress → encrypt → publish

The source and destination stay independent. dbterm supports PostgreSQL, MySQL and MariaDB, SQLite, Turso, and Cloudflare D1. Backups can move local-to-local, local-to-remote, remote-to-local, or remote-to-remote through the supported destinations.

Restore is deliberately narrower than backup today: PostgreSQL, MySQL and MariaDB, plus local SQLite. dbterm is useful, but it is not a claim that every path is finished or bug-free.

A small tool should tell the truth

The goal is not to replace every database client. It is to make the repeated read-and-check work feel lighter, especially on modest hardware.

That also means keeping the limits visible. A terminal UI is not automatically faster for every person. A backup is not complete until its copy and verification path are understood. A small binary is not a guarantee of small queries or fast networks.

I built dbterm because I wanted a calmer database loop. Open it, inspect the data, follow the useful relationship, run the small query, and leave with a backup I can explain.

This is a short companion to the full dbterm article. Edited with AI assistance.

My desktop might have VS Code or Cursor, Discord, WhatsApp, a database client, a music player, and the browser itself. Each app can make a sensible case for its memory and processes. The computer still has one memory pool, one battery, and one fan.

My original essay, I just wanted a small desktop app, compares Electron, Tauri, Wails, Electrobun, Flutter, and native toolkits. The practical point is simpler: measure the whole app before deciding that one framework is light or heavy.

One window can mean several processes

Electron ships Chromium and Node with the application. A system-WebView app avoids shipping the same browser distribution, but it still needs a web engine. On Windows, WebView2 uses Chromium. On macOS, a normal system path uses WKWebView. On Linux, Tauri commonly uses WebKitGTK.

The host executable is only one part of the picture. A WebView2 group can include a browser process, renderer processes, and helpers such as GPU or audio processes. The exact group depends on the app, the workload, and what else is running on the machine.

That is why a single Task Manager row can mislead. It may undercount the app, while adding every msedgewebview2.exe process on the computer may overcount it.

A small measurement routine

Use the same app version and the same workload each time. Let startup settle before recording a number. Compare an idle window, normal work, and the state after quitting.

On Windows, Process Explorer makes the parent-child tree visible. For a WebView2 app, follow the parentage and command line to identify only the helpers belonging to that app. Record both Private Bytes and Working Set; they answer different questions.

On macOS, Activity Monitor can show all processes hierarchically. Check Memory Pressure and Swap Used as well as the app rows.

On Linux, start with a process tree:

ps -eo pid,ppid,rss,comm --forest

RSS includes shared resident pages. For a more useful comparison, inspect proportional set size for each identified process:

awk '/^Pss:/ {print $2 " KiB"}' /proc/1234/smaps_rollup

Replace 1234 with the process ID. PSS apportions shared resident pages, so it is better than blindly adding RSS. It is still a snapshot, not a complete GPU-memory or peak-usage measurement.

What the numbers can and cannot say

A smaller installer is a real benefit. A small host process can also be real. Neither number alone tells me what the user pays while the app is open.

The same warning applies to native, Rust, or Go hosts: any of them can do unnecessary work. The useful comparison is the product with its real workload, not a framework slogan.

I still want a small desktop app to open quickly, behave like the rest of the operating system, and leave room for the other nine apps on my screen. Until the perfect answer exists, following the whole process group is a better starting point than arguing from one executable size.

This is a focused companion to the full desktop-framework essay and the accepted HackerNoon version. Edited with AI assistance.