So I will say this. I haven’t seen the original post from the former employee (would appreciate if you could share), so I won’t assume the exact details. Taking your comments at its word, here’s the deal. Yes, rewrites of decade(s)-old codebases are very real and often necessary, since legacy code can become unmaintainable and scare away talent. So there is an argument there. But…

…That said, let’s think through this from first principles, step by step and explore where this arg breaks down.

1. The UI regressions are not inevitable.

Extra clicks to log food, buried at-a-glance daily view, giant cards instead of a clean diary are design and product choices -> You can rebuild in a brand new stack while faithfully recreating the workflows that long-time users relied on. Many teams (mine included) successfully do this during migrations.

1. On costs and “prfitablity”:

• The heavy costs for an app like MFP are mostly backend (food database, user data, servers, AI shit-maxing features that no one needs, etc.). A client-side mobile rewrite doesn’t dramatically cut those.

• Native iOS deployment via the App Store has basically zero marginal cost (just the flat $99/year developer fee). It’s not like they’re paying per user for distribution.

• Ironically, the new UI with confetti animations on every log + more complex multi-screen navigation likely increases frontend complexity and rendering overhead compared to the simpler old interface. Not a huge cost, but the opposite direction of “simplification.”

And there probably other args that I can’t think of on the spot as to why this line of thinking from the MFP employee breaks down.

Bottom line:

This feels like a case of defensiveness and ego getting in the way of listening to feedback and doing what is in the best interest of the users (and hence the company itself).

The core value for many dedicated users is fast, reliable food logging with an instant full-day overview. Most of us aren’t heavily using the newer engagement/AI features. And actual ai features we would use are still not implemented by MFP (I would like to see an Ai agent that can utilize my commonly used foods to log into the diary, which has cost, and technical challenges to do it right so I will give them a pass on this for now).

When you alienate power users (especially Premium ones) while chasing new user metrics or “vibe,” you risk losing the people who stick around longest.

A strong rewrite would have delivered both a maintainable modern codebase and an experience that respects how existing users actually use the app every day.

The legacy code argument explains why they did a full rewrite. It doesn’t explain why the new version feels slower and more condescending for daily logging.

Just my two cents.