In this case study, we apply vibe coding to the development of a full CRM platform to enable home based cafes for social impact
Better.sg is a Singapore non-profit exclusively dedicated to tech for good. We have grown a community of more than 2,800 members, making us the largest tech-for-good community in Singapore. We operate through a mix of activities, including in-house incubated projects, consultancy and implementation support for other Singaporean charities, and upskilling through mentorship programs.
The Majurity Trust is a major Singaporean charity fund, deploying capital through diverse grants and schemes. Their latest initiative is the Foundry Forward Fund, a scheme disbursing capital for non-profits willing to pair up for a common goal.
Given our experience in supporting other charities, it was natural for us to apply for it. We got matched with a social enterprise. As the project is still in progress, let's call it X for the purpose of this article.
A social enterprise means that any profit generated by the entity is reinvested towards the charitable purpose written in the bylaws. X typically organises training for would-be F&B professionals, usually coming from disadvantaged backgrounds, and acts as a force for societal integration.
X wanted to expand their integration efforts by enabling home-based cafes. However, no current platform was offering the kind of features needed to operate such a network. Therefore, they needed a partner to develop such a platform. This is where Better.sg comes into play.
Once we received approval for the grant, we started building a team of volunteers from our community while collecting requirements and scoping the project. 8 developers and 2 testers, all volunteer and committing 4 hours max per week. The timeline was very short — six weeks to develop everything. I had serious doubts about our ability to deliver the full scope, or even a functional MVP. So we prepared a staged approach to the project, with phase 1 including critical minimal functionalities, and phase 2 containing everything else.
The X team had already advanced the work. They had a very nice working prototype built with Lovable (with no backend and only mockup data), which could demonstrate the main features needed:
The missing critical features were:
Additional good-to-have features:
That seemed very hard to deliver in six weeks. But let’s explore. At that time, Lovable had rolled out the Supabase integration, and that was identified as the best shortcut we should take to try to implement all the required features.
We started by testing the prototype and identifying where mock-up data needed to be replaced. This step was critical - it set the foundation for our data model, and getting it right would shape everything downstream.
We started prompting Lovable, asking to build table for each data object we had identified. Then we analysed the suggested data table creation query and started correcting it. Lovable was getting about 85% right. Most of the fields were right for a simple reason — Lovable was analysing the prototype pages and deriving the attributes from what was displayed. However, some dependencies with external keys were missing, and some fields related to certain features were missing. Easy fix!
When we logged into Supabase and saw the Entity-Relationship Diagram (ERD) — a visual map of tables and how they connect — it was a “wow” moment. In just 20 prompts, we had replicated a big chunk of what would normally be an expensive e-commerce management system.
With the data model in place, the next step was replacing mock-up data with live data from Supabase. Doing this all at once would have overwhelmed Lovable (we already had 14 app pages), so we went page by page. Generally, the context Lovable was using was at most the current page code, the object model (basically a table definition), and the dependency graph.
This approach worked well, but not well enough. Once we understood how Lovable is working with Supabase (basically creating standard webhooks and adapting them to the data), we also designed better prompts to ensure that we took security into account.
Our typical prompt for each page would look like this:
“In this page / cafes, replace mock-up data and instead implement real-time integration with Supabase cafes table. You can find additional information about cafes in the cafes_opening_hours table. Access to the cafes table and other related tables should be read-only for public access, read-only for authenticated users with role customer, and write access is only allowed for authenticated users with role owner where the user_id is equal to owner_id field in the cafes table.”
From that, Lovable generated both a React hook to access the data and a Supabase policy to control who could do what. This gave us fine-grained control over each role, effectively implementing a role-based access control system.
When data manipulation such as joins was needed, Lovable created Supabase functions (middleware) to handle validation or transformations. All we had to do was to review the queries/functions before they went live.
Authentication was easy to set up but required heavy testing. As we added more roles, we ran into inconsistencies because role names weren’t consistent across the database, frontend logic, and TypeScript interface definitions. This confusion came from our own lack of consistency in naming conventions early on. Once we enforced discipline in naming, the system worked and we never needed adjustments again.
Notifications were another part we were worried about having to code manually. There is an integration with Resend API, but we had doubts that it would work as advertised. We were wrong. Lovable surprised us: it understood the Resend API well and wrote Supabase functions that act as middleware to manage it. Orders, order updates, account creation, password resets — they were all working seamlessly.
One mistake we made was testing with dummy emails, which caused Resend’s bounce metric to spike out of this world. Our bad! Email templates are fully managed in the Supabase functions. Lovable, having easy access to these as context, made it very easy to add secure links and dynamic elements to them.
Everyone in the team is a volunteer and has a day job, but in three weeks we were nearly there. We took one more week to implement the design system and good-to-have features. Four weeks in, we were ready to have a first high-level review by the X team.
Initially, there were some uncertainties around the order lifecycle and the payment process. Once clarified with the X team, we refactored the order flow significantly. It was surprisingly easy to do as the code was well organised and structured, so changing steps didn’t require changing many lines.
Six weeks in, we had a working MVP — far ahead of where we thought we’d be. The only things left on our list were a forgotten password flow and a super admin dashboard, which we knew we could quickly add in the future.
We pushed the MVP to UAT to avoid scope creep. Two days of testing surfaced 27 bugs, including 11 critical. I decided to give Lovable a go at bug fixing too. It took me 1 hour and 43 minutes and about 40–45 prompts to clear the whole list. Everything passed re-testing.
By week eight, both missing features were done: the password flow and the super admin dashboard were implemented. We did three sections for the super admin dashboard: Cafes, Customers, and Orders. Each of them was fully implemented in a single prompt, detailing which metrics we wanted and included a graph with a daily/weekly selector. One main reason is that most of the hooks to fetch data and the functions for transformations were already there since we display similar metrics on each role’s own dashboard.
Some developers were not comfortable working with Lovable and preferred to use their Integrated Development Environment (eg. Cursor), to push changes. This was especially the case for the design system. We had Lovable integrated with Github, so everything stayed in sync. Every preview rendered successfully in Lovable was saved as a commit on GitHub, and code changes merged on GitHub showed up in Lovable within seconds. Conflicts were rare, but we learned an important lesson: keep code updates (pull requests, or PRs) small and incremental.
We had one moment at which the preview was not working anymore. We had to roll back before the merge in Lovable. Then break down the PR into smaller ones and incrementally add them, and it worked just fine. Another lesson was that when adding new libraries, you need to explicitly prompt Lovable to install them.
In total, the project took about 50–55 volunteer hours. It’s now ready for pilot launch with seven cafés, running on free Supabase and Resend plus $20 for Lovable. At scale, the system could support up to 50,000 customers for just $70/month. This project showed how Lovable can supercharge small, volunteer teams. With the right planning, scoped prompts, and clear processes, we delivered a production-ready app in just six weeks.
💡 BONUS: Now let’s see how ChatGPT would summarise our project (content below is generated by GPT5):
This project demonstrated that with the right planning, clear scoping, and disciplined prompting, Lovable can be a powerful accelerator for building complex, production-ready applications in record time — even with a fully volunteer team and minimal weekly commitment. By leveraging Lovable’s deep integration with Supabase and APIs like Resend, we were able to deliver a robust MVP in just six weeks, including features we initially thought impossible within the timeframe. The staged approach, strong role-based access control (RBAC) implementation, and iterative testing ensured both security and functionality. Challenges, such as role naming inconsistencies, PR merging conflicts, and handling third-party integrations, were resolved through better process discipline and incremental changes.
1. Start with a strong data model — getting the data structure right early on makes all downstream work easier and safer.
2. Leverage AI for targeted, context-rich prompts — limiting scope per prompt (e.g., one page or feature at a time) improves accuracy and security.
3. Integrations can be seamless — Lovable’s built-in knowledge of services like Supabase and Resend saved significant development time.
4. Adopt incremental merging — small, frequent PRs reduce conflicts and make rollbacks safer.
5. Volunteers + AI = high productivity — even part-time contributors can ship high-quality apps quickly when supported by the right tools and workflow.
6. Plan for refactoring — a clean, modular codebase makes changes painless when requirements evolve mid-project.
7. Test with real data early — using dummy data in live integrations (e.g., emails) can cause unintended operational issues.
.jpg)
