Why Humanly: software that knows when to stop

Humanly is a small software studio, and this is the first post in our journal. We make focused, humane software: desktop apps for macOS, Windows and Linux, a few mobile apps, and security tools. We also build software for other people. The idea that ties it together is simple to say and surprisingly hard to do. A good tool does its job, and then it stops.

That sounds obvious. Look at the apps on your own computer, though, and count how many of them are still trying to do something after you have finished with them. Showing a tip. Asking for a rating. Suggesting a feature you did not ask about. Syncing something you did not know was being synced. Most software is built by people who are measured on how much you use it, so it grows in the direction of more use, not better use.

We would like to build the other kind, and to write down why as we go.

What we mean by humanly

The name is a bit of a joke and a bit of a promise. We use it as a test when we are designing something. Would a thoughtful person, doing this job for you by hand, behave like this? A good assistant does not interrupt you to announce that they have new capabilities. They do the work, tell you when it is done, and leave you alone.

In practice that turns into a handful of rules we try to hold ourselves to:

• One job per app. If a tool needs a second paragraph to explain what it is for, it is probably two tools.
• Attention is the scarce resource. No badges, no streaks, no notifications about the app itself. If we notify you, it is because something you started has finished or failed.
• Local first. Your files and your data stay on your machine unless there is a clear reason to send them somewhere, and you get to see that reason.
• Quiet by default. Sensible defaults, few settings, nothing that phones home for no reason.

None of these are new ideas. Unix people have been saying "do one thing well" for decades. What is new is how far most software has drifted from it, and how much people seem to want it back.

Small apps, on purpose

The hero drawing at the top of this post is the picture we keep in our heads. On the left is the usual app: one real task in the middle, surrounded by features that each have a reason to exist and each ask for a bit of your time. Feeds, chat, badges, a shop, an assistant, an invite screen. On the right is one window with one input and one button.

We are not claiming the left side is always wrong. Some jobs really are big. A photo editor or an IDE needs a lot of surface area, and trying to squeeze that into one button would be silly. But plenty of everyday jobs are small, and they end up wrapped in big software because that is how the business around them works.

Our own apps are deliberately small. Among our desktop apps, serve shares a folder over HTTP or HTTPS with one command. Exif AI writes AI-generated titles, descriptions and tags into your photos' metadata. dskcopy writes disk images to drives and verifies them. Grabbr, still being built, will download video and audio without the clutter. idNX, one of our security tools, maps your local network. Each one has a sentence that says what it does, and we try hard not to let any of them grow past that sentence.

Small has practical benefits too. A small app is quicker to start, easier to test and easier to keep secure, because there is less of it. It is also easier to finish. We like finishing things. A tool that is done, and gets small fixes when the operating system changes, is a better thing to own than one that changes shape every few months.

Respecting attention is a design decision

It is tempting to treat attention as a matter of tone, as if a friendlier notification were a more respectful one. We think it is structural. The questions that matter are about when software is allowed to speak, not how politely it speaks.

A few examples of what that looks like in our work. An app that runs a long job should tell you once, when the job finishes, and not show a progress toast every thirty seconds. Settings should be few enough that you can read all of them in one screen. Updates should be quiet and should never move buttons around for the sake of it. And an app should be happy to be closed. Nothing on our side is counting how many minutes you spend in it.

We sometimes get this wrong. Every extra option starts with someone asking for it, and saying no is harder than it sounds. We would rather say no and explain why than build a settings page nobody can use.

Local-first, and why it matters to us

Most of our tools work on files that are already on your computer: a folder you want to share, photos you want to describe and tag, a disk image you want to write to a USB stick. Sending those files to a server and back would be slower, more fragile and less private, and for most of these jobs it would add nothing.

So our default is to do the work locally. No account to create, no upload, no waiting on a network. When a tool genuinely needs the internet, as a downloader does, it should be clear about what it contacts and why. We will go into the trade-offs of this approach in a separate post on the case for local-first tools, because it is not free. Backups, multiple devices and collaboration all get harder when there is no central server holding everything.

Building for other people too

Alongside our own apps, we do custom development: desktop apps, mobile apps and SaaS products for clients who want the same kind of care applied to their own idea. Often that means a company with a clear internal job, such as a tool for a field team or a desktop utility that has to run on three operating systems, and no appetite for a sprawling platform to do it.

The same rules apply there, adjusted for the fact that it is someone else's product. We will push back on features that do not earn their place, and we will say so early, when it is cheap to change course. A smaller first version almost always ships sooner and breaks less.

What this journal will cover

We are going to write here roughly every week or two. Three kinds of posts, mostly:

Concepts. Drawings and write-ups of products we think should exist, even if we are not the ones who will make them. The first is a very thin, very calm phone, the Humanly Phone concept. It is not for sale and not in production. Designing hardware on paper is a good way to test whether our ideas about software hold up once battery, space and cost are involved.

Build notes. How we actually make things. Shipping one codebase to macOS, Windows and Linux. Why a local server should bind to localhost by default. How we choose file formats, handle updates and test on machines we do not own. These will be practical, with commands and numbers where we can be honest about them.

Security. We make security tools, and a lot of everyday software is less safe than it looks. We will write about threat models for small apps, signing and distribution, and the unglamorous parts of keeping software trustworthy.

We will also be honest about what we do not know. Some posts will end with open questions rather than answers. That seems better than pretending.

Where to start

If you want to see what we mean in practice, the desktop apps page is the best place. Each app has one sentence at the top, and that sentence is the whole brief we work from.

If you have a tool you wish existed, or a piece of software you think has grown too big for its job, we would like to hear about it. Next week we publish the phone drawings. Later this month, a longer piece on keeping data on your own machine, including the parts of it we find hard.