Project Learning Blog

5/5 (1) When we first started working on Assignment 1, we came up with several interesting ideas, but we ended up spending quite some time brainstorming and discussing our interests and what we actually enjoyed doing. We wanted to find something that we all liked, could improve with AI, and would be fun to work on while also fitting the assignment requirements. Eventually, we came up with MacroTable, which started as a relatively broad idea and slowly evolved as we added more elements to it.
One interesting part of this project was the team itself. It was my first time having to coordinate and communicate with a team where I hadn’t even met half of the members in person until Demo Day. This made planning and communication a bit more interesting, especially when trying to agree on certain decisions. Nevertheless, I think we managed pretty well, and everyone contributed their own ideas and perspectives.
For Assignment 2, I was in charge of creating the working application prototype and evaluating it through user testing. This was probably the part I enjoyed the most. Developing applications and prototypes is nothing new to me, as I have been working with startups for a while now and was already familiar with planning, implementing, and testing ideas with users.
The first version of the application prototype turned out pretty well, but as it is possible to happen when working on an idea with multiple people, we all had slightly different perspectives on our idea and what the final product should look like. Although we had agreed on the general concept, there were still some of the details that were still unclear. After discussing our ideas and agreeing on a direction, I continued with the development of the prototype until we reached something closer to a final demo version.
My teammates were really happy with the app, but I wanted to push it further. This is something that happens to me quite often when developing applications. Even when something is already working and meets the requirements, I tend to keep working on it and adding features that aren’t necessarily needed. Although this might not be the most efficient approach, I believe that experimenting and seeing how far you can take an idea is very fun.
I ended up integrating Gemini into the application, allowing users to interact with an actual LLM instead of just having predefined responses. I also spent quite some time improving the UI and making the application feel more complete.
Interestingly enough, this was also the first time I used my own money to purchase API credits for a project, although I think I was a bit too conservative with how I used them. I could probably have used a much better model without spending significantly more. However, I was quite impressed by how well and consistently the application performed with inexpensive models, using Gemini 3.8 as the main model and a Gemini 3.7 as a backup, which was actually pulled back only 2 days after demo day. Learning that well structured applications can have great results without using advanced models might be my most important lesson from this project. In our case, the LLM wasn’t responsible for every decision but only for understanding user requests and communicating with the users. The application handled the nutrition calculations and meal configurations.
During user testing, we received very positive feedback. All 15 participants reported that the application was usable. We also received positive feedback on the UI. Also, 14/15 completed the ordering process and one participant, despite being told that this was only a demo and that they should pretend to be in a certain situation, genuinely believed that the application was going to order food for them, making for a pretty funny moment.
This was quite interesting because it showed that the application felt realistic, but it also showed that something obvious to developers might not be so obvious to users and that we hadn’t made it clear enough that no actual order would be placed. Thus, I made some changes to make the ordering process and payment clearer. My teammates also provided feedback and suggested additional features throughout development, which helped improve the final application.
Demo Day was very enjoyable. We got to present what we had been working on and see everyone else’s ideas. To be honest, I was genuinely surprised when we didn’t receive one of the top three places. Both my teammates and I thought we had a pretty good pitch, and we felt that quite a few people had voted for us. Perhaps we overestimated how much the working application would influence the ratings, but I am still proud of how far we took the prototype.
Seeing the other projects was also really interesting. I enjoyed seeing how everyone came up with completely different ideas based on their team’s interests or problems they believed were worth solving. I really hope some of them decide to take their ideas further and actually implement them.
Overall, I wouldn’t say we had any major failures, nor that the project fundamentally changed my understanding of AI or business strategy. Having worked with startups before, many parts of the process were already familiar to me.
However, it did reinforce the difference between building a working application and having a validated business idea. Although our prototype worked well and received positive feedback, we still hadn’t validated the idea in terms of real restaurant adoption, performance compared to existing alternatives, or actual kitchen operations.
If I had the chance to do the project again, I would try to establish a clearer shared vision earlier and spend a bit more time on evaluation rather than continuously adding features.
To conclude, I really enjoyed the project. Our idea might not have been the most revolutionary, but it was fun to develop and a good opportunity to work with new people.