**The Wisdom of Building Small, Single-Purpose Tools: A Maintenance-First Approach to Open Source**
In the world of software development, the allure of the “big framework” is powerful. It promises order, structure, and a place for everything. When faced with the challenge of regression-testing PHP runtime upgrades across seven teams’ services, the sensible-sounding move is often to build that very framework. However, as Mikhail Golikov, a Hove-based software engineer and sole QA on a backend team at a high-load e-commerce platform, discovered, the most sustainable path is frequently the deliberately humble one.
Golikov’s experience is a testament to the principle that small, focused tools outlast monolithic frameworks, especially for solo maintainers. Instead of creating a centralised testing framework with its own abstractions and house style, he chose to build a handful of small, single-purpose open-source Python tools—each doing one job and knowing nothing about the others. These tools, including `postman2pytest`, `secure-log2test`, `pytest-conversational`, `pytest-resilience-agent`, and `phoenix2pytest`, turn existing artefacts like collections, logs, and traces into runnable tests that integrate seamlessly into CI pipelines.
The brilliance of this approach lies in its deliberate “boredom.” Each tool is designed to be straightforward, with no shared core, plugin registry, or platform dependencies. This separation of concerns means that to get a Postman collection into CI, you install just one tool and nothing else. As Golikov notes, this distance to a first successful run is the single biggest factor in whether an open-source project gets adopted.
Composition without coupling is another key advantage. Because the tools share conventions rather than a codebase, they can be chained in user-defined pipelines—logs to tests here, traces to tests there—without any dependency on the others. This Unix-pipe philosophy of agreeing on formats while keeping components independent ensures flexibility and resilience.
Maintenance, Golikov reminds us, is the honest work. A framework fails as a unit; a bug in one small tool cannot bring down the entire testing ecosystem. For a maintainer working in the margins of a full-time job, this isolation is not just convenient—it’s essential. Each tool has its own release cadence, issue tracker, and blast radius, ensuring that failures are local and manageable.
Of course, small tools are not free from trade-offs. There is duplication of effort—each carries its own argument parsing, README, and release workflow. Discovery is harder across multiple repositories than a single marketed framework. But for Golikov, the costs land on the maintainer, while the benefits land on the user. This alignment of incentives is what makes the small-tool strategy the right one for open source.
The same instinct runs through the design of each tool: minimal dependencies, lean codebases, and a “do one thing” ethos. `pytest-conversational`, for example, ships with no runtime dependencies to avoid unnecessary trust and technical burden. The smaller the surface area, the longer a tool stays useful without its creator.
In the end, Golikov’s wisdom is simple yet profound: Build the smallest thing that stands on its own. Give it one job and one honest README, then let people compose the rest. The framework urge may promise tidiness, but for open source, it often creates fragility. The most practical advice for keeping projects alive when you are the only one maintaining them is to embrace the power of doing one thing well.
—
**Original Article:**
Golikov, M. (n.d.). *Building small, single-purpose tools: A maintenance-first approach to open source*. Retrieved from the original post content provided above.
