Background
Better.sg is a Singapore non-profit exclusively dedicated to tech for good. The organization has grown a community of more than 2,800 members, making it the largest tech-for-good community in Singapore. Operations include 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.
Better.sg applied for the fund and was matched with a social enterprise (referred to as “X” in the article). This social enterprise organizes training for would-be F&B professionals, usually from disadvantaged backgrounds, and acts as a force for societal integration.
The Project
X wanted to expand their integration efforts by enabling home-based cafes. No existing platform offered the needed features to operate such a network, so Better.sg was engaged to develop a custom platform.
The team consisted of 8 volunteer developers and 2 testers, each committing 4 hours maximum per week. The timeline was extremely tight—six weeks to develop everything. A staged approach was adopted, with Phase 1 including critical minimal functionalities and Phase 2 containing additional features.
Scope
X had already created a working prototype using Lovable (with no backend and only mockup data) demonstrating main features:
- Browsing cafes
- Registering cafes
- Registering menu items
- Registering as a customer
- Ordering drinks
Critical missing features were:
- Full end-to-end order management
- Payment flow
- Authentication
- Data model
- RBAC (role-based access control)
- Design system
- Email notifications
Building the App with Lovable
1. From Prototype to Data Model
The team started by testing the prototype and identifying where mock-up data needed replacement. This step established the foundation for the data model.
The team prompted Lovable to build tables for each identified data object. Lovable achieved approximately 85% accuracy on the initial attempts. Most fields were correct because Lovable analyzed the prototype pages and derived attributes from displayed information. However, some external key dependencies and feature-related fields needed correction.
When the Entity-Relationship Diagram (ERD) appeared in Supabase, showing tables and their connections, it was a significant moment. In just 20 prompts, the team had replicated a large portion of what would normally be an expensive e-commerce management system.
2. Replacing Mock Data with Live Data
With the data model in place, the next step involved replacing mock-up data with live data from Supabase. Processing all pages simultaneously would have overwhelmed Lovable, so the team worked page by page.
A typical prompt for each page followed this pattern:
“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 such prompts, Lovable generated both a React hook to access the data and a Supabase policy to control access permissions. This provided fine-grained control over each role, effectively implementing a role-based access control system.
3. Authentication
Authentication setup was straightforward but required extensive testing. As more roles were added, inconsistencies arose because role names weren't uniform across the database, frontend logic, and TypeScript interface definitions. Once naming conventions were enforced, the system worked consistently without requiring further adjustments.
4. Notifications
The team was initially concerned about manually coding notifications. While Lovable offered a Resend API integration, the team doubted it would function as promised. They were mistaken. Lovable demonstrated strong understanding of the Resend API and wrote Supabase functions serving as middleware to manage it. Orders, order updates, account creation, and password resets all worked seamlessly.
5. Progress and Refactoring
Despite all team members being volunteers with day jobs, significant progress occurred within three weeks. Six weeks in, the team had a working MVP—significantly ahead of initial expectations.
6. User Acceptance Testing and Bug Fixing
The MVP was pushed to UAT to prevent scope creep. Two days of testing identified 27 bugs, including 11 critical ones. The team attempted using Lovable for bug fixing. It required 1 hour and 43 minutes and approximately 40–45 prompts to clear the entire list, with everything passing re-testing.
7. Working Across Github and Lovable
Some developers were uncomfortable working with Lovable and preferred using their Integrated Development Environment (e.g., Cursor) for pushing changes. With Lovable integrated into Github, everything remained synchronized. Every successful preview in Lovable was saved as a GitHub commit, and GitHub code changes appeared in Lovable within seconds.
Key Takeaways
The project required approximately 50–55 volunteer hours total. It is now ready for pilot launch with seven cafes, running on free Supabase and Resend plus $20 for Lovable. The project demonstrated how Lovable can amplify small, volunteer teams' capabilities.
- Start with a strong data model — Getting the data structure right early makes all downstream work easier and safer.
- Leverage AI for targeted, context-rich prompts — Limiting scope per prompt improves accuracy and security.
- Integrations can be seamless — Lovable's built-in knowledge of services like Supabase and Resend saved significant development time.
- Adopt incremental merging — Small, frequent PRs reduce conflicts and make rollbacks safer.
- Volunteers + AI = high productivity — Even part-time contributors can ship high-quality apps quickly when supported by the right tools and workflow.
- Plan for refactoring — A clean, modular codebase makes changes painless when requirements evolve mid-project.
- Test with real data early — Using dummy data in live integrations (e.g., emails) can cause unintended operational issues.