Small tools, done well

October 16, 2026 · Apal Notes

There are two ways to build software. One is the suite: a heavy application with forty tabs, a tutorial, and an upsell screen. The other is the small tool: it does one thing, in one screen, in about three seconds, and then gets out of your way.

Apal is built on the second path. Our first product is a PDF toolkit, and the rule for every feature inside it is the same: the user's goal should be reachable in under three clicks.

What "done well" means here

• Sensible defaults. You shouldn't need to read documentation to watermark a document. Open the tool, pick a file, done. Every extra option is optional, never required.
• Honest errors. If a PDF is encrypted, the tool says so instead of failing silently. If a password is wrong, it says that too. Error messages are written for humans.
• Respect for the file. Page order you typed is the order you get. Content stays selectable, not rasterized into a screenshot — unless compression genuinely requires it, and then we tell you.
• Speed as a feature. The site itself must load fast, in any language, on any device. A slow tool page is a broken promise before the tool even runs.

Why this makes business sense

Big suites win on checklists; small tools win on trust. A person who merges one PDF successfully in five seconds comes back the next time they need to split one — and tells a colleague. We would rather be a bookmark than an app you tolerate.

So the roadmap stays deliberately boring: more small tools, each polished, each local-first, each free. That's the whole strategy.