I wanted to build a small product that solved a problem people actually have, rather than another project that would only live in a GitHub repository.
That idea eventually became InviteVia, a digital invitation platform for weddings, birthdays, engagements, parties, and other events.
The initial idea sounded simple: let someone create an invitation, share it with their guests, and collect RSVPs.
The interesting part was everything that came after that.
Starting with a simple MVP
I decided to keep the first version as simple as possible.
The core flow was straightforward. A user creates an invitation, adds the event information, publishes it, and gets a shareable URL. Guests open the URL and can view the invitation and respond to the event.
One decision I made early was not requiring guests to create an account just to RSVP.
From a developer perspective, authentication would have been relatively easy to add. From a user's perspective, however, it would add another unnecessary step.
For an event invitation, I would rather remove friction than add another login screen.
Why I chose Next.js
I built the application with Next.js and TypeScript.
Next.js made sense for this project because the application has both interactive parts and pages that benefit from being discoverable by search engines.
The invitation itself is also something that needs to load quickly when somebody receives a link through WhatsApp, Instagram, SMS, or another messaging platform.
I wanted the application architecture to support both the product experience and the SEO side of the project without maintaining a separate frontend application.
Supabase for the backend
For the backend, I used Supabase.
It gave me authentication, PostgreSQL, database access, and other backend functionality without having to build all of those services from scratch.
For an MVP, this was especially useful because I wanted to spend more time working on the actual invitation experience rather than building infrastructure that already exists.
The database structure revolves around the things the product actually needs: users, invitations, events, guests, and RSVP information.
Keeping those relationships simple was important because I knew the application might eventually need to support more complex event features.
One of the more interesting problems: social previews
One of the things I wanted InviteVia to do well was sharing.
When somebody sends an invitation URL through a messaging application or social network, the link should not just appear as a random URL.
It should have a useful preview containing the event information and an appropriate image.
This led me to implement dynamic Open Graph images using Vercel's OG image generation.
Instead of creating a static image for every invitation, the application can generate a preview based on the invitation data.
That means different invitations can have different previews while still using the same underlying application.
For me, this was one of the more interesting parts of the project because it sits somewhere between frontend development, backend data, and SEO/social sharing.
Making RSVP as frictionless as possible
Another problem I wanted to solve was the RSVP experience.
Imagine receiving a wedding invitation and being asked to create an account, verify your email, and remember another password before you can simply answer "Yes."
That felt unnecessary.
So I designed the RSVP flow around the guest rather than the account system.
A guest can open the invitation, see the event information, and respond without creating an account.
The goal is simple: if someone has the invitation link, they should be able to interact with the invitation.
This sounds like a small product decision, but removing a few steps from a user flow can make a significant difference.
Building for multiple languages
InviteVia is also designed for an international audience.
Instead of building the application around a single language and adding localization later, I decided to support multiple languages from the beginning.
The platform currently supports 19 languages.
That introduced another layer of complexity because localization is not just translating strings. Routes, metadata, page titles, descriptions, structured content, and user-generated information all need to work correctly across languages.
It also made me think much more carefully about how I structure the application.
The SEO side of the project
SEO became another interesting engineering problem.
A digital invitation platform has many pages that can potentially be discovered through search engines, but simply generating thousands of pages is not enough.
The pages need useful content, correct metadata, sensible heading structures, canonical URLs, and proper language relationships.
I also had to think about how dynamically generated invitation pages should behave when they are crawled.
This is where building a product and working on SEO start to overlap. Technical decisions made in the application can directly affect how search engines understand the site.
What I learned from building it
The biggest lesson was that building the product is only one part of the work.
It is relatively easy to create a page that looks good and works locally.
It is much harder to build something that is fast, accessible, discoverable, easy to share, and simple enough for someone who has never seen the application before.
I also learned that small product decisions can have a surprisingly large impact.
Not requiring an account for guests, generating dynamic social previews, supporting multiple languages, and keeping the invitation URL simple were all decisions that seemed small when I made them.
Together, they became an important part of the product experience.
Where InviteVia is going
InviteVia started as an MVP, but I am treating it as a real product rather than just a portfolio project.
The next challenges are not only technical. They involve understanding how people actually use the invitations, improving the creation experience, making RSVP management better, and finding sustainable ways to bring new users to the platform.
For me, that is what makes building a product more interesting than building another demo.
You have to keep solving problems that you did not anticipate when you wrote the first line of code.
If you want to see the project, you can find it at InviteVia.
I am still building and improving it, so this is very much a work in progress.