Building Small Softwares for Specific Jobs

Alongside books and websites, Taciturn Studios builds small pieces of software: calculators, generators, checkers and dashboards that each do one job. None of them is a platform. Most of them could be described in a sentence. That's deliberate. For a small team, narrow tools that remove a specific, recurring pain are often more valuable, and far more maintainable, than ambitious products that try to do everything.

This post is about how we think about building those tools, and why "small" is a feature rather than a compromise.

The Unix idea, applied to products

In 1978, Doug McIlroy, one of the people behind the Unix operating system at Bell Labs, summarized part of its design philosophy in a foreword to the Bell System Technical Journal: make each program do one thing well, and expect the output of every program to become the input to another. Decades later, that idea still describes a lot of software people love: focused tools that compose with others instead of trying to own every step.

The same thinking works for products aimed at people rather than programmers. A tool that calculates a book's print cost and royalty across trim sizes is easy to understand, easy to test and easy to trust. A "complete author business platform" that also tracks ads, sends email, manages social posts and schedules launches is harder to build, harder to learn and much harder to keep working.

What makes a job worth a tool

We look for jobs with three characteristics.

It recurs

A task done once a year rarely justifies software. A task done every week, or every time a book is published, might. The comic xkcd has a well-known chart ("Is It Worth the Time?") that shows how much time you can afford to spend automating a task based on how often you do it and how much time it saves. It's a joke, but the arithmetic is real: frequent small savings add up quickly.

It's annoying in a specific way

The best tools come from a precise complaint: "I have to copy the same metadata into six forms," "I can never remember which keywords I've already tested," "I need to know what this meeting is costing in salary time." Vague dissatisfaction makes for vague products.

The result can be checked

Good small tools produce output the user can verify: a number, a file, a list, a clear yes or no. That makes them trustworthy and makes bugs obvious.

The under-a-minute test

A narrow tool earns its place when it turns a tedious task into something that takes under a minute. If someone has to read documentation, create an account and configure settings before getting value, the tool is competing with the old manual way, and the manual way often wins because it's familiar.

So we design for:

• No signup for the core job where possible. Let people try it immediately.
• Sensible defaults. Most people should be able to accept the defaults and get a useful answer.
• One screen. Inputs, then output. Advanced options can hide behind a toggle.
• Shareable or exportable results. A link, a copy button or a file download.

Keeping it small on purpose

Every successful small tool attracts feature requests. Some are good. Many would turn a sharp tool into a blunt one. We use a few rules to protect focus:

1. New features must serve the same job. If a request is for a different job, it might deserve a separate tool.
2. Each addition must earn its maintenance cost. Every option, integration and setting is something to test and fix later. We discuss this cost more fully in How Taciturn Studios Picks Which Products to Ship.
3. Removing is allowed. Features that few people use can be retired to keep the core simple.

Building and maintaining with a tiny team

Small tools fit a small studio because they're cheap to maintain if built carefully:

• Fewer dependencies. Each external library or service is something that can break or change. Narrow tools usually need fewer.
• Clear repositories. A good README, an example environment file and deploy notes mean anyone can pick a tool up months later. See Contractor-Friendly Repo Hygiene.
• Simple hosting. Many small tools can run on modest infrastructure with low monthly costs.
• Graceful degradation. If an external data source fails, the tool should say so clearly rather than produce wrong answers.

A worked example

Consider a meeting cost calculator. The job is narrow: show, in real time, roughly what a meeting costs in combined salary time, so teams think twice before booking another hour with eight people. The inputs are few (number of attendees, an average hourly rate, a start button), the output is a single running number anyone can sanity-check, and it takes seconds to use. There's no account, no integration with calendars and no analytics suite. Those could all be added, and each one would make the tool slower to use and more expensive to keep running. The version that does one thing is the one people actually open in a meeting.

How small tools support the rest of the studio

Narrow tools rarely make much money on their own. Their value often comes from what they connect to. A useful free calculator for authors introduces people to our books and guides. A tool we built for our own workflow saves hours every month even if nobody else ever uses it. A tool that answers a common question can become a reference page that people link to and return to.

That's why we judge them by usefulness first. If a tool reliably saves time for the people who use it, the other benefits tend to follow. You can see what we've built on our tools and apps pages.

When a small tool should die

Some tools stop being useful. The platform they supported changes, a better free alternative appears, or nobody uses them anymore. Narrow tools are easier to retire than large products: there's less to migrate and fewer users to notify. We describe how we do that responsibly in When to Kill a Side Project Cleanly.

If you're building your own

You don't need to be a software studio to apply this. Many authors and small publishers build small tools, from spreadsheet templates and scripts to simple web pages. The same questions apply: Does the job recur? Is the pain specific? Can you check the result? Does it take less than a minute once built? If the answer to all four is yes, a small piece of software may be one of the best investments you make this year.