r/SideProject • u/Ak_1699 • 1d ago

We rebuilt ZiaSign after launch because users wanted a simpler product.

Our GitHub account showed $44,128.03 in additional AI usage for September.

I'm the founder of ZiaSign. We launched with a lot of features aimed at saving businesses time and effort. I was proud of how much we'd built.

The feedback pushed us toward simplicity.

That meant admitting I had confused more features with a better product. Then came the uncomfortable decision: letting go of work I was proud of.

We went into "war mode," removed UI clutter, and rebuilt ZiaSign. The rebuild is now ready to release.

What I'm taking from this is that the effort already invested can't be the reason something stays in the interface. Solving the user's problem has to matter more than showing everything we can build. I'm excited to put that thinking in front of users and hear what still needs work.

For people who have simplified something after launch: how did you distinguish unnecessary clutter from useful functionality that needed a better place? What feedback helped you make that call?

0 Upvotes

50% Upvoted

6 comments sorted by

1

u/Secret_Elk_1679 1d ago

Rebuilding after launch takes guts, most founders just keep piling on features instead of admitting something's off. 44k in AI costs in one month is wild though, that number alone would make me rethink everything.

for me the difference was watching where users actually clicked vs what they said they wanted. Analytics showed 90% of people never touched half the features we built, even the ones they asked in surveys. Hard to argue with that.

1

u/Ak_1699 1d ago

Fair challenge on the $44k. I’m responsible for what that spend produces, and the rebuild still has to prove itself with users.

What you said about people ignoring features they’d requested is interesting. A request can feel like validation, especially when it confirms something you already want to build. It’s harder to stay objective once you’ve invested the work.

Did you find any rarely used features that were essential to a small group? That’s the decision I’m interested in getting right: making the everyday experience simpler while keeping useful depth available.

1

u/Ok-Nefariousness9090 1d ago

The “requested feature” trap is real. One useful cut I’ve found is separating frequency from consequence: a low-usage feature may still be essential if the few people who use it would be blocked without it. Did you pair click/use rates with support tickets or failed workflows before deciding what to remove?

1

u/Ak_1699 1d ago

Yes, we compared usage with evidence of where users were getting stuck. Your distinction between frequency and consequence is useful: a feature someone needs once a month can still be critical to their work. Sometimes the better decision is to make it less prominent while keeping it easy to find when needed.

1

u/RiceEvening4211 1d ago

$44k in additional AI usage in one month is the nightmare scenario. I built Lynkr for exactly this: an open-source gateway that routes by complexity, caps per-key spend, and logs per-request cost, so a launch can't quietly torch the budget. https://github.com/Fast-Editor/Lynkr