Firebase Hosting + Cloud Functions

Firebase Hosting and Cloud Functions serve as the operational backbone for Total Ventures, providing a managed backend infrastructure that abstracts away server management for authentication, data persistence, and event-driven compute.

What it is

Firebase is a Google-owned platform offering a suite of backend services. For Total Ventures, the critical components are Firebase Hosting, Cloud Functions, Firestore, and Authentication. Hosting provides a CDN for static assets and single-page applications, though for most web frontends, I use Vercel. Cloud Functions are event-driven serverless functions that execute backend code in response to triggers (HTTP requests, database changes, scheduled events). Firestore is a NoSQL document database, and Firebase Authentication handles user sign-up, sign-in, and identity management. This combination delivers a complete, managed backend without requiring me to provision or maintain servers.

How I use it

Each Total Ventures brand operates with its own dedicated Firebase project. For Total Formula 1, Firebase handles user authentication, stores race predictions, and manages user-specific preferences. Cloud Functions process incoming race data webhooks, update Firestore, and trigger notifications. For Pregnancy Power Hour, Firebase manages user accounts, controls access to premium content, and tracks user progress through various course modules, with functions handling subscription validation and content delivery. On Inky, Firebase stores user profiles, manages generated image metadata, and processes payment webhooks from Stripe via Cloud Functions. I also leverage Cloud Functions for scheduled tasks, like daily data aggregation or sending reminder emails. For image transformations and storage, I often integrate Cloud Functions with Cloudinary to offload heavy media processing. My Next.js App Router applications often interact directly with these Firebase services through client-side SDKs or API routes that proxy to Cloud Functions.

Why this over alternatives

The primary draw of Firebase is its integrated suite of services. Having Auth, Firestore, and Functions under one roof significantly reduces the integration overhead I would face with disparate services. As a solo operator, minimizing operational burden is critical. Firebase's managed nature means I spend no time patching servers or scaling infrastructure—it handles that automatically. The generous free tier allows me to launch and iterate products without significant upfront costs, and the pay-as-you-go model scales predictably. Compared to self-hosting on a VPS or EC2, the developer experience is streamlined, letting me focus on product features rather than infrastructure. While other serverless options exist, Firebase's tight coupling with Firestore and Authentication makes it a cohesive choice for the types of products I build.

Where it falls short

Vendor lock-in is the most significant drawback. Migrating away from Firestore or Firebase Authentication would be a substantial undertaking. Cloud Functions can also suffer from cold starts, introducing noticeable latency for infrequently invoked functions, which impacts user experience in some scenarios. Debugging functions in a distributed environment can be more complex than debugging a monolithic server. While the free tier is generous, costs can escalate quickly if not monitored, particularly with high Firestore read/write volumes or extensive function invocations. Furthermore, the managed nature means less granular control over the underlying infrastructure compared to IaaS offerings, which can be a limitation for highly specialized requirements. I structure my monorepo using Turbo to manage backend function code alongside frontend projects, which helps mitigate some of the complexity, but the inherent trade-offs remain.