This year I turned 30. I’ve been designing for nearly half my life, starting an internship at 16 with enough energy to make things, ship them, and see what sticks. The habit that shaped me most wasn’t taste, it was exposure: live with products long enough that their annoyances become intolerable, then fix the one that keeps poking you in the ribs.
So that habit, or rather, intolerance to adjust to one's solution has made me explore solutions and sort of made me push for iterating on my thing. That how and why my brother and I built WeatherKit.
Why build it yourself
Owning implementation forces taste to meet constraints; when code hits reality, opinions get priced and the fluff drains out. Shipping turns “nice-to-have” into “wasteful” and exposes the one interaction in each flow that actually earns its keep. Using your own product builds a kind of conviction you cannot outsource; it’s simply easier to defend decisions you’ve bled on.
Strategy that survives contact
There’s strategy that reads well and strategy that survives week three with real users. The first is pattern-matching; the second is taste under pressure. Building your own tools is how you stress-test that taste without hiding behind decks.
Feedback that matters
Building it first for you can shape better interfaces than any moodboard ever could. You are actually the user persona so that forces pragmatic scope and clarifies the product’s core. One bit to be careful for is knowing when saying no to good ideas, just so you can focus on getting things over the finish line.
The loop: design → implement → live with it
Sketch the narrowest path that solves a specific pain, implement it end-to-end, and then live with it until the papercuts are louder than your pride. Only then decide whether it deserves a v2 or a deletion.
Tools as taste elevators
AI is excellent at producing ten plausible options, but the work is to raise the bar on what “plausible” means once it touches a keyboard and a network. Use the speed to explore more directions, then judge harder, not softer, and ship the one that still makes sense after a bad day.
Constraints that help
Adopt a one-session rule: if it can’t be designed, built, and dogfooded in one focused sitting, cut scope until it can. Hold a daily-driver test: if it won’t replace an existing tool for you this week, it isn’t ready. Keep a kill switch: remove features that don’t earn weekly touches because clutter is expensive debt. Shipping your own work turns “users” into names, “flows” into rituals, and “edge cases” into your morning. You stop defending abstractions and start defending outcomes—faster, clearer, calmer—at the moment design becomes operational rather than ornamental.
The expensive part: belief
Belief is slow because it’s built by saying no: no to the clever variant, no to the pleasing flourish, no to the feature that dilutes the one promise your product must keep. You can automate options, but you can’t automate conviction; you earn it by living with your choices.
A simple commitment
Pick one annoyance you still tolerate, design the tiniest boringly fast fix, and build it. Use it for a week, then keep only what earns its slot on your home screen. Repeat until your taste is shaped by reality, not rhetoric. I know this has been more abstract, but I found it applies to a much broader scope.