DineFlash

DineFlash Landing page
Restaurant owner page
Patron groups page
Patron home page

Inspiration

While at a conference, I met up with a group of colleagues and decided to go for lunch. We spent about 20 minutes trying to decide on a local restaurant, with each of us having specific requirements based on dietary and other constraints. When we finally selected a restaurant and went in, the wait times were much longer than usual due to back of house issues and the lunch crowd rush. When our order arrived, it was inaccurate and we had to rush through eating because we did not want to miss the session in the conference track. I had to abandon my dessert part-way, which made me think about how we could have optimized this entire process so that we could have had a better outcome. Thus DineFlash was conceptualized and born.

What it does

DineFlash allows restaurant owners to list their restaurant and pertinent details in the directory. The menu items, pricing and wait times are expected to be updated whenever a significant change occurs. Diners can then create a dining group and vote on restaurants that should be considered, and then the group creator can finalize the restaurant selected. The group can then pre-order the dishes in the app and automatically place the order as soon as they arrive at the restaurant. This saves time as they don't have to peruse the menu and make poor food choices in a hurry based on incomplete information, as all details (allergens, dietary, etc.) are captured upfront in the application.

How we built it

I already had the concept and design of the app in mind. I then heard of the Bolt hackathon and signed up for the challenge. I used the AI tooling in Bolt to build the entire application from the scratch, and then continued to refine the app using other AI agents in conjunction with Bolt's AI. I made some architectural choices to use Supabase as the backend and host the app on Netlify with a custom domain from IONOS.

Challenges we ran into

Once the codebase grew past a certain point, Bolt's AI became less efficient at development and debugging, and changes could break existing functionality as it would refactor code to focus on the current ask, ignoring everything else it had done before that. I had to become significantly more deliberate and detailed with my asks and thus had to use a myriad of AI agents (Gemini, Copilot and Claude to name a few) to ensure that my code changes were small and targeted. I also made sure that i could revert any changes made by agents in VSCode before pushing it up to my main repo.

Accomplishments that we're proud of

This is the first time i have used 'Vibe Coding' to develop a full application. I can now understand and appreciate the pros and cons of this approach to application development, and can envision how it will evolve in the future as the AI models and tools improve over time.

What we learned

I learned that real applications can be developed by using AI models and tooling, but the rigor of software engineering remains. I made this project without writing any unit tests early on, so this was not TDD. I still have a lot to learn about agentic coding and how to combine strong software engineering principles with this new paradigm shift in coding. The 80/20 principle is very strongly felt here. The AI will take you 80% of the way, but the other 20% is your direct responsibility, and the complexity lies firmly in the 20%.

What's next for DineFlash

I would like to build this application into a proper commercial offering. I will have to conduct some real world testing, launch in beta and then figure out fair pricing to make this more sustainable. Currently the application is functional, but I have no idea of scalability based on user load etc. I will probably need to optimize many of the compute resources to match the workload when DineFlash goes into commercial use. I would like to build an MCP for DineFlash so that a user's personal AI Agent can access this app and make optimal selections for the user based on their knowledge of the user.