I Built a Bowl Builder Tool for Nawtch, and the Save Button Was Harder Than It Sounds

I designed a tool called Bowl Builder for Nawtch, a platform that helps users calculate calorie and macro numbers for meal-prep style bowls and plates. The tool allows users to add finished bowls to their food log or save bowls locally for later editing, providing flexibility for users who want to adjust recipes over time. The challenge lay in deciding how to save bowls - as individual components or as a single food entry - because editing a saved bowl should not retroactively change previously logged days.

To address this, I treated saved bowls and food entries as separate entities in the data model, ensuring that editing a bowl did not affect previously logged days. This approach was reminiscent of Nawtch's existing system for daily calorie targets, where historical data remains unaffected by later changes to the target range. I placed the Bowl Builder in the Tools section of the app, as it functioned as a standalone tool that could be used independently of food tracking data.

The Bowl Builder operates locally, stored in the browser's IndexedDB, just like other Nawtch features. This means no account is required, and data is not sent anywhere, with the understanding that clearing browser data would result in the loss of saved bowls. Moving forward, I plan to apply a similar design principle to a grocery cost planning tool I am currently developing, recognizing that this tool will also require determining what data should be permanent versus what should remain editable.