Table of Contents
One of the most important things you can do as a founder is get feedback from your users. In your mind, your product might be perfect. But to your users, they often have other thoughts.
Tally Budget has recently undergone fast iteration based on user feedback. Looking back, the first version looks completely different than the latest, and had way too many features.
The goal of Tally Budget was to be a simple budgeting app. You manually create your budget based on your needs and preferences, then input your transactions. That's it.
But as I built it, more and more ideas came to mind. And since code is cheap now, I just added them into the product. New views. New options. Edge cases I'd thought of in the shower. Technically on launch day, everything worked as I'd promised it would.
The problem was that technically doing everything and being usable turned out to be different things.
Users were confused
I shared the app with friends and family and they all came back with similar confusion. What I thought was straightforward, they found confusing.
Common feedback I'd get:
- Questions about how to do basic things
- Questions about where features lived
- A steady, depressing stream of bug reports
- Users asking what a button did
At first, I'd spend my time explaining how to use the app. Answer the question. Fix the bug. Walk someone through a flow. I treated each one as a separate issue.
Something felt off, but I hadn't named it yet.
Then I tried to ship version 2
Version 2 was a big refactor. It included a Liquid Glass redesign for iOS 26 and Penny, a new AI chat assistant. Both would have been substantial on their own. Layered on top of a product that already had too many features, the refactor touched more of the codebase than I expected, and broke things in places I didn't think to test.
The product was simply too big to hold in my head.
Within hours of release, users were finding bugs I'd somehow missed. Some were small. A few were the kind that made me close my laptop and walk around the block.
That's when it clicked.
The user confusion. The endless basic questions. The bug reports from v1. The fact that I couldn't make a single bigger change without things breaking in places I'd forgotten existed. These weren't separate problems. They were one problem, expressed in many different ways.
The product was doing too much, and users (and I) were drowning in it.
That was the real piece of feedback. And nobody had said it out loud.
I think this is something a lot of builders miss, me included. We wait for feedback to arrive in a clean, quotable form. "I wish it did X." Add X. Roadmap, validated.
But the most important feedback often shows up as a pattern, not a sentence. Confusion. Repeated questions. A codebase that fights back every time you touch it. Users quietly using the product less. If you're only listening to what people say, you're missing most of the signal.
You can't ship your way out of complexity
My instinct when something isn't working is to ship more. Add a feature. Polish a flow. Write better onboarding.
This was the wrong instinct. You can't add your way out of a product that's too big. You can only subtract.
So the next few iterations were focused on cleaning up what was there, before I let myself add anything new. Ship, dogfood, feedback, iterate. A continuous loop until each feature got to a good place.
Iteration speed is what saved me
The v2 bug fallout could have been catastrophic. The reason it wasn't was that I'd been tightening the iteration loop for months.
Bug reported → bug fixed → user notified → live. Sometimes within the hour.
You're not going to test your way to a perfect launch, especially not solo, and especially not on top of a product that already has too much in it. Real users use your product in ways you'd never think to, and they'll find the cracks faster than any process you could build on your own. What you can control is what happens after. If your loop is fast, bugs are a temporary embarrassment. If it's slow, every one of them compounds.
Dogfooding catches what users won't tell you
Customer feedback is the loud signal. Using your own product, every day, is the quiet one.
Users won't email you about the third click that should've been one click. They'll just quietly stop opening the app. You only catch that by sitting in their chair, doing the same thing they do.
Half the small improvements in Tally Budget came from me muttering "this is annoying" while doing my own budgeting on a Tuesday night.
Still far from perfect
Tally Budget isn't where I want it to be. It's not perfect. But thanks to feedback, and actually listening to what users were saying, including the things they weren't saying, it's in a much more usable state than where it started.
Each week, it's a little closer to what users actually need, instead of what I imagined they'd need on launch day.
If I had to compress the whole lesson into one line for other builders, it'd be this:
Your users are giving you feedback all the time. Most of it isn't in the words. It's in the confusion, the questions, the silence, and the things they stop doing. Learn to read that, and ship faster than you think you need to.
If you want to see where Tally Budget is today, give it a try at tallybudget.app. It's still far from perfect, but every week it gets a little closer. And if you do try it, send me your thoughts. The good, the confusing, the annoying. There's a real chance you'll see it in the product before the end of the month.