Building an AI SEO Platform: How HeySEO Went from Idea to SaaS
April 9, 2026
How WebLaunch built Founder Feast, a curated dinner networking platform for founders across Vancouver, Toronto, and Kelowna with Stripe payments and automated event management.
Loic Bachellerie
April 9, 2026
The best business relationships are rarely built in conference halls or on LinkedIn. They happen at dinner tables, over good food, with people who actually understand what it means to build something from nothing.
That insight is the foundation of Founder Feast - a curated networking platform that matches founders for exclusive dinners at top restaurants across Vancouver, Toronto, and Kelowna. The concept was sharp. The execution needed to be sharper. In five weeks, we took it from a Google Doc to a live product processing real payments in three cities.
Here is how we built it.
Networking events for founders have a signal-to-noise problem. Open meetups attract everyone. Conference cocktail hours are loud, rushed, and forgettable. The people you actually want to meet - operators who have raised a round, built a team, or navigated a pivot - are not standing at a badge table waiting to talk.
Founder Feast flips the model. Instead of broadcasting an event to hundreds of people, it accepts applications, selects participants by hand, and places five or six founders around a dinner table at a restaurant worth going to. The curation is the product.
The challenge is making curation scalable without losing what makes it valuable. You need a way to accept applications, collect payment, review candidates, manage the event logistics, and communicate with attendees - all without turning the operation into a full-time administrative job. That is the software problem we were hired to solve.
Before writing a single line of code, we mapped the full feature set. Founder Feast needed:
None of these pieces are exotic. The engineering challenge was integrating them into a coherent system that a small operations team could actually run - without technical help.
Every technology decision on this project was made against two criteria: speed to production and long-term operational simplicity. We were not building infrastructure for a Series B company. We were building a product that needed to be live, stable, and manageable by a lean team.
Next.js 14 with the App Router was the natural choice for the front end. Server Components reduced the amount of JavaScript shipped to the client, which mattered for conversion on the landing page. The App Router made routing and layout composition clean. TypeScript kept the codebase maintainable as features accumulated. Tailwind CSS v4 handled styling without the overhead of a component library. Framer Motion handled the animations on the landing page - the kind of polish that signals to a founder that the product they are applying to is serious.
Firebase handled authentication and data persistence via Firestore. The document model was a good fit for application records, which have irregular shapes as they move through the review process. Firestore's real-time capabilities gave the operations dashboard instant updates without any polling logic. Firebase also removed the need to stand up and manage a database server - a meaningful reduction in operational surface area for a product that needs to stay running with minimal maintenance.
Stripe was the only serious option for payments. The Stripe integration powers two tiers - Standard and Founding Member - with payment collected at the time of application. Stripe's hosted payment flow handles PCI compliance, failed card retries, and receipt emails. We connected it to the application pipeline so that a completed payment triggers the right status update in Firestore and kicks off the welcome notification sequence.
Resend handled transactional email. Clean API, reliable deliverability, and straightforward template management. Telnyx handled SMS. Founders get a text when their application is received and again when they are approved. The two-channel notification approach keeps the experience responsive without requiring anyone to monitor an inbox manually.
AWS S3 handled media storage for the gallery and any assets that did not belong in the repository. Vercel handled deployment, with edge caching on the landing page and preview deployments for every pull request. Microsoft Clarity supplemented Vercel Analytics with session recordings and heatmaps - useful for understanding how applicants moved through the form.
We spent the first week on structure. Repository setup, environment configuration, CI/CD pipeline on Vercel, and the core component library. By the end of week one, the landing page was taking shape - hero section, how-it-works flow, gallery, testimonials, pricing table, and FAQ. All responsive. All performing on mobile.
The goal was to have something a real person could look at and understand by the end of week one. That kept the project grounded in the actual user experience from the beginning.
The application form was designed to take under a minute to complete. Name, company, city, what you are working on, and payment. That is it. The form validated on the client before submission and again on the server before writing to Firestore.
The Stripe integration required care. Payment needed to feel like a natural part of the application, not a jarring redirect to a third-party page. We used Stripe's embedded payment element to keep the checkout experience within the Founder Feast interface. A successful payment created the application record in Firestore with the correct status and triggered the first notification to the applicant.
The operations team needed a way to review applications without touching the database directly. We built a Firestore-backed dashboard that displayed applications by city, surfaced the relevant information for each applicant, and allowed status changes with a single action.
Status changes drove the notification pipeline. An approval sent a welcome email via Resend and a confirmation SMS via Telnyx. A decline sent a polite rejection. Every notification was templated and logged.
Week four was about making the product durable. We wired in Vercel Analytics and Microsoft Clarity. We audited the form for edge cases - what happens if a payment succeeds but the Firestore write fails, what happens if someone submits twice, what happens on a slow connection. We handled them.
We also invested time in animation and micro-interactions on the landing page. The Framer Motion work here was not decorative. A landing page that feels polished increases the likelihood that a founder completes the application. That is a business outcome, not an aesthetic preference.
The final week was dedicated to end-to-end testing of every user path - successful application, failed payment, approval flow, decline flow - and a full staging review with the Founder Feast team. We ran through the operations dashboard together, confirmed the notification templates read correctly, and verified analytics were tracking.
The product went live before the end of week five.
Founder Feast launched with active events in Vancouver, Toronto, and Kelowna. The application form was processing real payments within days of launch. The operations team was managing applicants through the CRM without any technical support from us.
The platform handles the full applicant lifecycle: discovery, application, payment, review, approval or decline, and event assignment. The notification pipeline means applicants are never left wondering about their status. The analytics setup means the Founder Feast team can see exactly where their conversion funnel is working and where it needs attention.
The Founding Member tier sold out quickly, which validated both the concept and the product execution. When the first tier sells, the landing page is doing its job.
Founder Feast was a zero-to-one project. No existing codebase. No existing customer base. No existing infrastructure. Five weeks later, it was a working product generating revenue.
That timeline is not a coincidence. It is the result of making the right technology decisions early, staying disciplined about scope, and building the integration work correctly the first time.
If you have a concept that needs to be a product - an event platform, a marketplace, a SaaS tool, a community application - the question is not whether it can be built. It is whether your team can build it fast enough to matter. Speed to market determines whether you get to learn from real users or whether you spend another quarter in planning.
WebLaunch is a Growth Engineering Studio. We build full-stack products from concept to deployment, and we do it on timelines that make business sense. Founder Feast is one example. We have others.
If you are sitting on a concept, let's talk.
More from Case Study
Let's discuss how we can help you achieve your goals online.