Do not build apps!

Many developers have more ideas than free time. AI can now write a first version of a tool in one afternoon. This makes it tempting to skip thinking and go straight to a new repository.

But writing code was never the expensive part. The expensive part comes later:the dependencies, the bugs, and the unfinished project that keeps waiting for your attention.

So before you start, ask two questions.

1. What problem am I solving?

Answer in one plain sentence. “A tool that does X” is not a problem. “I want to log in without typing a password” is a problem. Writing the problem down often shows you that someone already solved it, or that it was not a real problem.

2. What already solves it, and where does it fail for me?

Most people skip this question. Search for existing solutions. For each one, name the specific reason it does not work for you. If you cannot name a real failure, you probably do not need to build anything.

An example from my own experience

I wanted to use my fingerprint reader for passkeys in Firefox on Linux. The idea seemed small, but the problem underneath was simple: I wanted to log in without typing a password.

First idea: extend pass with WebAuthn. Firefox on Linux can’t use a fingerprint reader as a passkey authenticator directly. The workaround was a software authenticator built on my pass store, which meant implementing CTAP2, a kernel HID interface, and CBOR encoding. That was far too much work for this problem, so I dropped it.

Second idea: pass-nostr. I wanted to store passwords on the Nostr network. Before writing any design, I asked whether something already existed. That’s when I found ngit, which extends git to work with Nostr. I already use it in my stack, and pass already runs on git, so the problem was already covered. I dropped that idea too.

These were two different ideas, left for two different reasons:

  • WebAuthn for pass: the cost was too high for the problem, and a hardware security key already solves it.
  • pass-nostr: the solution already existed in my own stack.

The lesson is simple: asking the question first saved me from the design work entirely.

Neither idea was bad. Both are interesting. They just didn’t solve my problem better than what I already had.

The habit

Next time you have an idea, spend ten minutes on the two questions before you create the repository. If the problem is clear, and no existing solution fails in a way you can name, go build it. You will probably build something better, and you will finish more of what you start.

References

Password and passkey tools

Passkeys and hardware keys

Linux fingerprint support

Nostr and git


Write a comment