The Tech Stack Behind UdharPay — Why a Solo Developer Chose React, Firebase, and WhatsApp Cloud API Over a Traditional Backend.

Every Technical Decision in a Startup is a Tradeoff

When you are a solo developer building a product that needs to scale to thousands of users while costing almost nothing to run in the early days, every choice carries double the weight. You are not just choosing a technology. You are choosing what you can maintain alone, what will not bankrupt you before you get customers, and what will not require a complete rewrite when you eventually succeed.

Here is exactly how I made every major technical decision for UdharPay — and what I would do differently.

Why React + Vite Instead of Next.js

Next.js is the obvious choice for most modern web applications: server-side rendering, better SEO out of the box, API routes built in. I know Next.js well.

But UdharPay's marketing site and dashboard have different SEO requirements. The dashboard — where users manage customers, send reminders, and view analytics — has zero SEO needs. Server-side rendering would add complexity for no benefit.

For the marketing site, I pre-render the critical pages and rely on Firebase Hosting's CDN for performance. This gives me 95% of Next.js's SEO benefit with 0% of its additional complexity.

React + Vite gives me a build time under three seconds, hot module replacement that actually works, and a bundle size I can reason about. For a solo developer, developer experience is not a luxury — it is a survival requirement.

Why Firebase Instead of Spring Boot

I have built three production applications on Spring Boot. I know it well. But Spring Boot requires a server that costs money — even a minimal Render or Railway instance costs $7 to $20 per month before you have a single paying customer. For a bootstrapped micro SaaS targeting ₹299 per month customers, that is significant.

Firebase on the Blaze plan gives me:

• Zero cost until real usage begins
• Authentication with two lines of code
• Firestore real-time database with offline support
• Cloud Functions for server-side logic
• Hosting with global CDN
• All integrated, all managed, all documented

The tradeoff is vendor lock-in and limited query flexibility compared to PostgreSQL. I accept this tradeoff completely at the current stage. When UdharPay has 10,000 users, migration to Spring Boot with PostgreSQL will be funded by revenue.

Why WhatsApp Cloud API Over Twilio or MSG91

Three options exist for sending WhatsApp messages programmatically in India:

1. Twilio – USD pricing, expensive for high-volume Indian reminders
2. MSG91 – Indian BSPs through resellers, cheaper but adds complexity
3. WhatsApp Cloud API – free up to a threshold, direct Meta integration, transparent pricing

I chose option three for lower cost, better reliability, and one less vendor relationship to manage. Setup is more complex but long-term economics are clearly better.

Each utility template message to an Indian number costs approximately ₹0.16. At 50 reminders per customer per month, the cost is ₹8 per customer. With Pro plan revenue of ₹749 per customer, that is a 98.9% gross margin on messaging cost alone.

Why Stripe Over Razorpay for Global Billing

UdharPay targets India, USA, and Germany. Razorpay is excellent for India but has limited international support. Stripe handles all three markets natively, supports subscription billing with automatic renewal, and has industry-standard webhooks.

The tradeoff is Stripe’s 2% + ₹2 fee vs Razorpay’s 2% flat, negligible at my price points. More importantly, Stripe’s subscription management saves weeks of manual work.

The Architecture Decision I Am Most Proud Of

Every reminder in UdharPay goes through a Cloud Function, not the client. This means:

• The WhatsApp API key never touches the browser
• Rate limiting happens server-side
• Plan enforcement cannot be bypassed by the client
• Delivery status webhooks from Meta update Firestore automatically

Security and reliability are not optional features — they are the product.

What I Would Do Differently

If I were starting again today, I would set up Firestore security rules on day one instead of day thirty. I spent two weeks with an open database while building features. That was irresponsible and I got lucky nobody found it. Security rules first. Always.

The Road Ahead

The current stack will comfortably handle UdharPay's first 10,000 users at minimal cost. After that, migration to Spring Boot with PostgreSQL becomes the right call — more complex queries, better data portability, and lower Firestore read costs at scale.

First, 10,000 users. Then worry about migration.

Need a website for your business?

We build custom websites, apps, and e-commerce stores. Based in Pune, India.

More from the Blog