SwipePlate — Project Story
Inspiration
The inspiration behind SwipePlate came from a simple frustration we all shared: choosing what to cook often takes longer than cooking itself. Traditional recipe platforms overwhelm users with filters, long lists, and decision fatigue. At the same time, swipe-based interfaces (popularized by dating apps) have proven extremely effective at reducing cognitive load and speeding up decision-making.
We wanted to combine these two ideas food discovery and swipe-based interaction to create a more intuitive, engaging way to find meals. Our goal was to turn meal planning into something fast, visual, and even fun, instead of a chore.
How We Built the Project
SwipePlate is a full-stack web application built with a modern JavaScript stack.
On the frontend, we used React with functional components and hooks to manage state, routing, and UI behavior. The core feature—the swipe interaction—is powered by react-tinder-card, which allowed us to implement gesture-based swiping while maintaining full control over application state. Recipes are displayed as cards that users can swipe left or right to dislike or like meals, respectively.
On the backend, we built a REST API using Node.js and Express. This API handles authentication, user profile management, and data persistence. Authentication supports both email/password login and Google OAuth, with additional profile completion when users sign in through Google for the first time.
Recipe data is fetched from an external API and normalized before being sent to the frontend. We also implemented local caching and fallback logic to ensure the app remains usable even when API limits are reached.
Finally, liked recipes are stored and synchronized so users can:
- revisit their saved meals,
- manage preferences,
- and generate a consolidated shopping list automatically.
Challenges We Faced
One of the biggest technical challenges was implementing a reliable swipe mechanism. Initially, rapid swipes or button presses could cause race conditions where the wrong recipe was saved or a swipe was registered multiple times. This happened because state updates in React are asynchronous, meaning that relying directly on the current index could lead to inconsistencies.
To solve this, we redesigned the swipe logic around explicit locks and references:
- Each swipe is temporarily locked until the card fully leaves the screen.
- The exact recipe being swiped is captured at the moment of interaction.
- State updates occur only once per card, ensuring correctness.
From a conceptual standpoint, this reinforced the importance of thinking in terms of state transitions, not just UI events.
Another challenge was handling authentication edge cases, especially with Google OAuth. Tokens can expire or users may partially complete registration, so we had to carefully manage session storage, validation, and redirects to ensure a smooth onboarding experience.
What We Learned
This project significantly deepened our understanding of:
- React state management and avoiding stale closures
- Handling asynchronous events safely in UI-heavy applications
- Designing user flows that feel smooth and intentional
- Integrating third-party services (OAuth, external APIs) in a robust way
More importantly, we learned how small UX issues—like an unreliable swipe—can dramatically affect user trust. Fixing those details required thinking beyond “does it work?” and instead asking “does it feel right?”
Conclusion
SwipePlate is more than a recipe app—it’s an experiment in reducing friction through thoughtful interface design. By combining swipe-based interactions, personalized preferences, and smart state handling, the project demonstrates how technical decisions directly shape user experience. This project pushed us to think holistically about frontend behavior, backend reliability, and the subtle details that make an application feel polished.
Log in or sign up for Devpost to join the conversation.