margin16 lessons from building a productivity app on weekends
I've spent years being annoyed at notes and productivity apps. Too bloated, too slow, why is this button here. Now I'm a few months into building one myself.
I've spent years being annoyed at notes and productivity apps. Too bloated, too slow, why is this button here. Now I'm a few months into building one myself, on weekends only.
It's not finished and it has no users, so take this as notes from the workshop rather than wisdom from the mountain. But between this and products I've shipped in my day job, a lot has changed about how I look at every app I use.
What building it is teaching me
1. Typing is the whole product, and it's brutal to get right. I assumed the editor would be the easy part: drop in a solid open source component, 80% done in a weekend. The missing 20% is everything you'd actually notice as a user: paste without mangled formatting, undo that behaves, the cursor landing where your eyes expect. I'm months in and still on things I could never have named as a user but would have absolutely felt.
2. Building only on weekends changed what I build. Time comes in four-hour blocks with two-week gaps, so the enemy isn't lack of time, it's the cost of resuming. Small finishable changes, notes to my future self, features that survive being abandoned mid-way. This made the app better, not worse: anything too complicated to put down and pick up later was probably too complicated to ship anyway.
3. You can only really please a narrow range of workflows. Everyone wants their app simple and their own workflow fully supported, and everyone's workflow is different. Every feature in a bloated app is somebody's reasonable request; grant enough of them and the experience gets worse for everyone, including the people who asked. The apps I respect most decided who they're for and let everyone else leave.
4. Your own taste stops being trustworthy. After months of staring at it, I can't tell if something is intuitive or if I've just memorised it. I recently caught a keyboard shortcut that felt obvious to me and was completely undiscoverable to anyone opening the app cold.
5. Defaults are the product. Most users never open settings, so every default you pick is the app for them.
Making something configurable isn't a decision, it's refusing to make one.
6. Empty states are where apps die. The app looks great with my 200 test notes in it. A new user sees a blank screen and has no reason to type the first one. Designing for "nothing there yet" is a separate skill from designing the app.
7. Performance can't be retrofitted. When things feel sluggish, users don't file a bug, they drift away. Slowness creeps in one reasonable feature at a time, and you only notice when it's expensive to undo.
8. The last mile is invisible plumbing. Window restore, what happens on force-quit, the updater, the app icon at every size. None of it demos well, all of it decides whether the app feels trustworthy.
9. Cutting a feature you already built is harder than not building it. Sunk cost hits builders too. I've caught myself keeping things because they exist, not because they earn their place.
10. Users never mention the thing you're proudest of. They mention the icon, or a shortcut you added in an afternoon. I fully expect this to happen here too.
11. "Fast" means something different to every user. Launch time, search, how quickly you can capture a thought. You can't win them all, and picking which one to lose is the actual product decision.
12. Feedback tells you where it hurts, not what to build. Users are excellent at naming pain and terrible at prescribing cures. The requested feature is usually a clue, not a spec.
13. You compete with habits, not with other apps. The real rival of any notes app is Apple Notes, a text message to yourself, or a piece of paper. Nobody switches because your app is better. They switch when it's worth breaking a habit for, and that bar is far higher than "better".
14. Metrics lie politely on small numbers. Early on, every graph is noise with a trendline drawn on hope. One genuine conversation beats a dashboard.
15. Naming things matters more than you think. What you call a feature shapes how people perceive it.
16. Being a user of your own product doesn't make you the customer. I'm building it for myself, but "me" is a market of one. The discipline is figuring out which of my preferences generalise and which are just mine.
None of these are original. Most of them are things I'd read somewhere, nodded along to, and not actually believed until the app made me. That seems to be how this works.