Gautam Pandit: The Story Behind SplitEase - Why I Built It, and Everything I Learned Along the Way

Where it actually started

Like most product ideas that end up mattering, this one didn't start as a "startup idea." It started as an everyday annoyance.

In college, I was constantly in situations where money was shared between a group - a flat full of roommates splitting rent, groceries, and electricity bills; a trip with friends where everyone paid for different things at different times; a hostel mess where nobody could remember who owed who what by the end of the month. Somebody would pay for dinner, somebody else would cover the cab, someone would forget to pay their share for weeks, and by the time anyone tried to sort it out, nobody actually knew the real numbers anymore.

What frustrated me wasn't just the math - it was that nobody around me had actually solved this properly. There were tools that technically let you log an expense, but nothing that felt built for the way groups like mine actually lived and spent. I kept waiting for someone to build something that just got it. Nobody did. So eventually, I decided I would.

The six months before I wrote a single line of code

Here's something I think a lot of people skip when they talk about building a product: most of the real work happens before you touch a keyboard.

Before I wrote any code, I spent close to six months in research - genuinely trying to understand the problem, not just the feature list. I looked at how people actually split money in real groups, where existing tools broke down, what made people abandon a shared expense sheet halfway through a trip, and what would actually make someone trust an app enough to track their money in it.

Once I felt like I understood the problem properly, I moved into the part most people find boring but I found essential: documentation. I wrote a full SRS (Software Requirements Specification) - laying out exactly what the product needed to do, for whom, and why. This wasn't a formality. It became the reference point I kept coming back to every time I was tempted to add a feature that sounded exciting but didn't actually serve the core problem.

From there, I moved into researching the right tech stack. I didn't want to pick tools because they were trendy - I wanted a stack that could actually support real-time group interactions, receipt scanning, an AI assistant, and cross-platform apps, without falling apart as usage grew. Then came system design - mapping out how data would flow, how balances would stay accurate in real time, how the mobile and web apps would share the same backend, and how the whole thing would hold up once real users, and their real money conversations, started depending on it.

Only after all of that did development actually begin.

Building SplitEase: the stack and the system

I wanted SplitEase to feel modern and reliable, not experimental. So the architecture is deliberately straightforward - nothing exotic, just the right tool for each job:

• Web app: Next.js 16, React 19, Tailwind CSS, and Framer Motion, built as a full installable PWA
• Mobile app: Expo (React Native) - Android is live, iOS is built on the same codebase
• Backend & real-time layer: Node.js with an Express REST API, and Socket.IO powering live chat, presence, and real-time balance updates
• Intelligence layer: an OCR pipeline for receipt scanning, plus an AI assistant that answers natural questions about a group's expenses
• Media pipeline: Cloudinary for handling receipt images and shared media
• Database: MongoDB with Mongoose models, with balance data cached and invalidated on write so numbers stay both fast and correct
• Auth & security: Firebase authentication, server-side group-membership checks, input validation, and rate limiting on every request

What it looks like today

SplitEase is live and being used in the real world, not just running as a demo:

• Live on the web, with an Android app already deployed and iOS in progress on the same codebase
• Hundreds of users across hundreds of groups, with a growing base of monthly active users
• Thousands of expenses logged, and a steady stream of settlements completed every week
• An AI assistant that's already answered thousands of real questions about group spending
• Receipt OCR scanning running with strong accuracy, with ongoing work to push it higher

Every day, a little more optimized

Nothing about SplitEase was "finished" the day it launched, and honestly, it still isn't. I treat it as a living product - going back through the app regularly to make things faster, fix rough edges, tighten up the balance calculations, and improve the parts users actually interact with the most. Small, boring improvements, day after day, are what most people never see - but they're the difference between an app that feels clunky and one that feels like it just works.

Why I'm sharing this

I didn't build SplitEase because I saw a market gap on a spreadsheet. I built it because I lived the problem, got frustrated that nobody had solved it properly, and decided that was going to be my problem to fix. Six months of research, a full SRS, real system design, a stack chosen for the long run, and a lot of iteration later, it's a real product that real groups depend on to keep their shared expenses honest.

SplitEase is built to work for flatmates, roommates, trip groups, family expenses - basically any situation where a group needs to know, clearly and instantly, who owes what. And it's still evolving. If you're using SplitEase, or thinking about it, I'd genuinely love your feedback, good, bad, or "this one thing is annoying." That feedback is exactly what shapes what I build next.