Category
- 🚗 The Invention Lab Story
Date of issue
Oct 27, 2025
After creating the MVP, another concern quickly arose. 🤔
We believed that truly operating a service requires knowing who is using it, what cards they're combining, and what ideas they're developing . That's why we decided to add a membership registration feature.
🔒 There are so many membership services...
While researching various services, I discovered the sign-up feature offered by Firebase . It's provided by Google, the foundation of our service, and its global reach guarantees its security, so we thought it was just what we were looking for. However, when we tried to implement it, the initial setup was more complex than expected, and the need to understand both the frontend and backend proved daunting (since I'm not a true developer). Above all, given the need for rapid feature enhancements, it felt like a bit of an overkill.
Next, I checked out Clerk , an authentication solution recommended by a startup CEO . While it seemed easy to use, with an intuitive UI and easy setup, it felt a bit cumbersome for MVP use. Because it's so feature-rich, I felt it could be excessively demanding for an early-stage team like ours, who only needed simple authentication.
Then I discovered Supabase , which was much simpler and more intuitive than Firebase. It provided database, authentication, and storage all in one, and its SQL-based nature made table management easy. After using it for a while, even non-developers like me found it easy to use, so we ultimately decided to use Supabase for membership registration. 👏🏻
😞 Infinite trial and error
However, as we added features one by one, unexpected difficulties began to arise. Errors kept occurring as we created tables containing member information and linked them to other tables, such as "List of Wishlisted Cards" and "Saved Ideas." While the relational data structure provided by Supabase initially seemed intuitive and simple, the process of actually establishing relationships proved far from simple.
Especially when setting permissions between tables connected through foreign keys, I naturally encountered the concept of RLS (Row Level Security). RLS is, simply put, a security policy that controls who can access what data . When I first encountered this concept, I was extremely confused. If I set even one condition incorrectly, all of the data would be exposed, or not at all.
RLS (Row Level Security)
: A security feature provided by the open source PostgreSQL DB that allows database administrators to implement fine-grained access control at the row level of a table, including specific commands such as select, insert, update, and delete, by defining policies that control how one or more roles are visible and act on specific data rows.
: A security feature provided by the open source PostgreSQL DB that allows database administrators to implement fine-grained access control at the row level of a table, including specific commands such as select, insert, update, and delete, by defining policies that control how one or more roles are visible and act on specific data rows.
Ultimately, I fixed things one by one while talking to AI Studio's Code Assistant, and thanks to that, I was able to gain insight into 'this is what the backend is like, and data design and permission management are really important for service operation.'
😱 Gemini API Key Exposed
One day, another unexpected issue was discovered. While reviewing the deployed Invention Deck, we discovered that the Gemini API key was exposed. Because the API key was embedded within the web app code, anyone could view it by opening the developer tools. This was a serious problem that went beyond a security issue. Since the Gemini API key is billed based on usage, if someone were to use it to call the AI without permission... we could literally be hit with a huge billing bomb.
Since the service had to be exposed externally, I absolutely had to find a way to hide the key. After exploring various options, I finally found the answer: Supabase. I discovered that by leveraging the Edge Function provided by Supabase , I could securely move the key to the server and keep it hidden from public view.
Since then, we've changed all Gemini API requests to be handled through Supabase's Edge Functions. This has made our code much more secure and our structure more organized.
🤖 Solving problems with AI from now on
Of course, there were many more trials and errors. But this time, instead of relying on outsourcing, we solved the problem ourselves, one by one. Fortunately, Google AI Studio's Code Assistant proved to be a reliable partner! When we displayed an error message and asked, "Why isn't this working?" or "This part seems to be the problem. Can you tell me how to fix it?", it suggested appropriate code or solutions.
Thanks to this, code that initially felt unfamiliar gradually became familiar. By making even small modifications myself, I was able to see how the functionality was actually implemented. This led me to examine the code itself more and more frequently, and when specific errors occurred, I naturally began to trace the problem and fix it. Of course, I'm not a professional developer, but I began to understand enough about the logic flow and how tables are connected.
🪙 Furthermore, we even implemented plan-specific feature restrictions!
As the service's features began to operate stably, we began to consider how to operate it. The first question that came to mind was, "Is it right for all users to have the same features?" While there were some planning concerns, there were also practical reasons. The Gemini API incurs actual costs based on usage, and the template feature, which was planned and produced in-house, made us cautious about making it freely available to anyone.
So, ultimately, we decided to design plans that considered both user usage and the sustainability of the service, limiting features for each plan. Free users could even combine cards to generate ideas, while paid users could access all features! This was also implemented using Supabase.
Actual set plan
We created a separate table containing user plan and usage data and referenced that information based on each user's request flow and feature access conditions.
When you log in, retrieve the plan associated with your user_id.
Check the usage every time the function is executed
If it is a free plan, determine whether the usage limit has been exceeded,
If you have a paid plan, you can use all the features freely!
This entire process was neatly configured by connecting Supabase's RLS and authentication logic.
Entire DB of Invention Deck
✨ In closing...
EP.4 was a journey of confronting the real-world challenges of membership registration, security, and data management. Every time I created a new feature, new problems arose, and I was sometimes bewildered by unfamiliar error messages. However, as I resolved them one by one, the service gradually became more robust and sophisticated.
These days, even non-developers are planning and creating their own services using Vibe Coding. If you, the readers, are also struggling with similar concerns, I hope this episode will be of some help!
👉 In the next episode, Ep. 5, we'll be serializing the first public release of Invention Deck AI, which doesn't have to be perfect! 👏🏻
If you're curious about the URL of the actual Invention Deck AI, please stay tuned!
Subscribe to 'The Invention Lab Blog'
If you subscribe to the site, you can be the first to receive the latest updates, including new posts, via notifications and email.
Join Slashpage and subscribe to 'The Invention Lab Blog'!
Join Slashpage and subscribe to 'The Invention Lab Blog'!
