How I built it
Miseo began with a simple question: could I help restaurants prepare closer to what customers will actually order without increasing the risk of running out of food?
I built the application around information restaurants already have—or can easily collect—including weekly sales, prepared inventory, weather conditions, weekends, holidays, promotions, and unusual events. Miseo analyzes these signals and turns them into a demand forecast and practical preparation recommendation.
I created two ways to experience the application. Visitors can explore a working example using representative restaurant data or enter their own weekly figures in a separate testing workspace. The application checks the submitted data, identifies demand patterns, considers the expected conditions for the coming week, and produces a recommended preparation target.
I also added an accuracy and engineering section because I did not want the forecast to feel like a mysterious number generated by AI. Miseo explains the factors influencing each recommendation, displays historical model performance, separates the demand forecast from the manager’s safety buffer, and keeps the final decision in human hands.
I built the interface as a responsive web application using React, Next.js, interactive charts, browser-based data handling, and an explainable forecasting process. Throughout development, I simplified the design, added guided explanations, created an animated cover experience, and developed the Miseo identity so the finished product would feel approachable to restaurant owners—not only technical reviewers.
Challenges I ran into
My biggest challenge was balancing two risks that pull restaurants in opposite directions. Preparing too much creates waste, while preparing too little can cause stockouts, lost sales, and disappointed customers. I realized that a useful recommendation could not simply tell a kitchen to reduce inventory. It needed to recognize uncertainty and allow the manager to add a safety buffer based on experience.
Another challenge was translating forecasting concepts into language that would make sense during a busy restaurant week. Terms such as model validation, holdout testing, error rates, and feature importance are valuable to technical reviewers, but they can easily overwhelm someone who only wants to know how much food to prepare. I spent significant time simplifying the main interface while keeping advanced information available for anyone who wants to inspect the engineering process.
Access to real restaurant data was another limitation. Sales and inventory records are often private, inconsistent, or stored across different systems. For this prototype, I used representative coastal restaurant data and clearly labeled environmental estimates rather than presenting them as exact measurements. I then created the testing workspace so restaurant owners and hackathon judges could evaluate the same process with their own weekly information.
I also learned that making the forecasting model work was only one part of the challenge. The application needed clear validation, responsive behavior, understandable instructions, reliable input checking, and a visual identity that made the product feel credible.
Accomplishments that I’m proud of
I am proud that Miseo became more than a forecasting demonstration. It is a working application that connects restaurant operations, artificial intelligence, and environmental impact through one decision a kitchen makes every week.
I made AI central to the product rather than adding it as a chatbot or decorative feature. The forecasting process performs the project’s main task: learning from demand-related signals and producing a recommendation that can improve preparation decisions.
At the same time, I did not want users to trust the result blindly. I designed the application to show what influenced the recommendation, how forecasting accuracy is evaluated, and where human judgment still belongs.
I am especially proud of the restaurant testing workspace. Anyone can enter recent sales, prepared inventory, weather, promotions, and unusual events without needing technical knowledge. Miseo then converts that information into a forecast, preparation target, and accuracy explanation.
I also built the application around responsible decision support. Data entered in the current prototype stays in the user’s browser, recommendations do not automatically place orders, and the restaurant manager remains responsible for the final quantity. I believe this balance between useful automation and human control makes the idea more practical and trustworthy.
Most importantly, I completed and published a usable experience. Miseo now has a clear brand, an approachable two-part interface, a working sample model, custom-data testing, environmental impact estimates, technical documentation, and a clear explanation of why the problem matters.
What I learned
I learned that food waste is not only a consumer behavior problem. A significant amount of waste begins earlier, when a restaurant must decide how much food to purchase, prepare, and hold before knowing exactly how many customers will arrive.
I also learned that accuracy alone does not make an AI system useful. A restaurant manager needs to understand the recommendation, recognize its uncertainty, and adjust it when local knowledge suggests that the coming week will be different. Explainability and human control are therefore not optional additions; they are part of the forecasting system itself.
Another important lesson was that sustainability technology must also make business sense. Asking restaurants to reduce waste only because it is environmentally responsible may not be enough to change daily operations. Miseo connects sustainability to outcomes restaurants already care about: protecting margins, reducing unnecessary purchases, preventing stockouts, and making weekly preparation easier.
Finally, I learned how much product design matters. Earlier versions contained valuable information but felt too complex. By simplifying the language, separating the introductory story from the working application, and revealing advanced details only when requested, I made the project more convincing and easier to use.
What’s next for Miseo
My next step is to move Miseo from a strong prototype into a real restaurant pilot.
I want to partner with a small group of independent restaurants and use their actual sales, inventory, waste, promotion, and weather records over several months. This would allow me to compare Miseo’s recommendations with each restaurant’s existing preparation process and measure changes in over-preparation, stockouts, food costs, and discarded inventory.
I also plan to add secure accounts, saved restaurant histories, automatic weather data, and integrations with point-of-sale and inventory systems. Instead of manually entering information every week, a restaurant could eventually connect its existing tools and receive an updated recommendation before ordering or preparing ingredients.
Future versions could support multiple locations, menu categories, confidence ranges, changing prices, local events, seasonal tourism, and alerts when demand patterns shift. I also want to strengthen the environmental calculations using verified ingredient-level lifecycle data so restaurants can track avoided waste, carbon emissions, and embedded water more precisely.
My long-term vision is for Miseo to become a practical sustainability assistant for independent restaurants: affordable, understandable, and useful enough to become part of their weekly preparation routine.
My goal is not to replace the experience of restaurant owners and kitchen managers. I want to give them better evidence, earlier warnings, and a clearer understanding of the environmental impact behind each preparation decision.
Built With
- chatgpt
- css
- javascript
- jsx
- lucidereact
- next.js
- react
- recharts
- typescript
- vinext