Three years building the digital backbone of a business people trust with their money.

EPF Buddy helps people recover their Employees' Provident Fund (EPF) money when the process becomes difficult.

For many Indian employees, their provident fund is one of their most important financial assets. Yet accessing it isn't always straightforward.

Claims get rejected because of KYC mismatches, incorrect joining or exit dates, missing employer records and other administrative problems. People accumulate multiple Universal Account Numbers (UANs), old balances become difficult to access, and grievance requests sometimes close without resolving the actual issue.

Some customers arrive after years of unsuccessful attempts. Others have already approached multiple agents without finding a solution.

EPF Buddy operates as a human-expert-led consultancy. The team investigates the underlying problem, guides customers through the necessary formal processes and, where required, takes on the work of resolving their cases.

The website therefore has a job beyond explaining a service. It needs to make a complicated and often frustrating subject understandable, establish credibility with people who may already be sceptical, and help them take the next step with confidence.

I've worked directly with EPF Buddy's founder, Nikhil Gite, since July 2023.

Being the primary technical person meant there wasn't a separate engineering team translating product decisions into implementation. I was responsible for taking requirements, understanding the business context, making technical and experience decisions, building the systems and maintaining them after launch.

My involvement gradually expanded across several areas.

The business direction, domain expertise and operational delivery remained with the founder and team. My responsibility was to turn those requirements and opportunities into working digital experiences.

This project didn't begin with a complete product specification. The requirements changed as the business grew, customers used the website and new opportunities emerged.

The consultation flow is one of the most technically involved parts of the project. A customer needs to select a genuinely available slot, pay for the consultation and receive a confirmed appointment with a Zoom meeting link.

The experience connects three independent services:

• Razorpay — payment processing.
• Zoho Bookings — appointment availability and creation.
• Zoom — the actual consultation.

None of these services shares the application's internal transaction state automatically. The website needs to coordinate the sequence.

This was an important shift in how I approached backend development. I began thinking about the entire customer transaction rather than treating each API integration as an isolated feature.

Protect was one of the most interesting parts of the project because it took me into a market I hadn't previously worked in.

When Nikhil introduced the idea of expanding into insurance, he first helped me understand the Indian insurance market: why many people avoid insurance, why they distrust sales agents, how policy language creates confusion and why people sometimes discover the limitations of their coverage only when they make a claim.

That gave me the business context. I then spent time researching the market and understanding how customers think about insurance. I didn't want to build another conventional insurance website full of policy listings, generic promises and aggressive calls to action.

I developed the positioning, content strategy, page architecture, copy and digital experience for Protect.

The positioning decision

Rather than presenting insurance as another product to purchase, I approached it as a financial-protection problem. The experience addresses questions people actually have:

This allowed the website to educate before converting.

Three different customer journeys

I structured Protect around three distinct needs, each with its own dedicated experience.

The second expansion targeted employers. Until this point, the website primarily addressed individuals trying to resolve their own provident-fund problems. Organizations introduced a different customer with a different set of questions.

Nikhil provided the business requirements, statutory information, employee thresholds and service details. I translated that information into the website's information architecture, content and customer journey.

Trust is a particularly important part of EPF Buddy's business. Someone approaching a provident-fund consultancy may already have experienced rejected claims, confusing government processes or unsuccessful attempts with other agents. Generic marketing promises aren't enough.

I worked on structuring the website around documented recoveries and actual business evidence.

The website is a production application, not just a collection of static marketing pages. I have worked across the frontend, backend integrations, deployment and ongoing maintenance.

Custom implementation

I used custom Tailwind components rather than relying on a prebuilt component library. This gave me control over the website's visual identity, responsive layouts and interactions across the different service experiences.

Server-side integrations

The consultation flow uses dedicated server-side endpoints for Razorpay order creation, payment verification, Zoho availability and appointment creation. The contact form uses Next.js Server Actions and Nodemailer.

The objective was to keep sensitive operations server-controlled and prevent the browser from being trusted with payment or booking decisions.

Production responsibility

Because I remained the primary technical owner, building the feature was only one part of the job. I also had to maintain the application, diagnose integration problems, update the website as business requirements changed and make decisions about what should be improved next.

That ongoing responsibility is an important part of this project.

Looking back, several decisions had a bigger influence on the product than individual UI components.

The common thread is that I tried to solve the actual problem behind each feature rather than treating implementation as the end goal.

EPF Buddy's digital presence has evolved alongside a business that reports:

Working on EPF Buddy has given me a much better understanding of what it means to build something that real people depend on. If I were approaching the project again, I'd invest earlier in a few things.

These aren't reasons the project failed. They're opportunities I've become better equipped to recognize after working on it in production.

EPF Buddy has probably taught me more about building products than any single academic project could. I'm studying Artificial Intelligence and Data Science, and much of my engineering education happens alongside building and maintaining real applications.

This project pushed me to learn things that don't always appear in a classroom.

I learned that product decisions don't arrive as perfectly defined requirements. Sometimes a founder explains a market opportunity, and the job is to understand it well enough to decide how a customer should experience it.

I learned that good UX isn't limited to visual polish.

I learned that integrations are not just about connecting APIs. They require thinking about failure, trust, communication and what the customer experiences when something goes wrong.

I also learned that different customers need different products, even when they're interacting with the same business. The person trying to withdraw an old PF balance, the family evaluating its insurance protection and the HR manager responsible for statutory compliance don't need the same journey.

Most importantly, I learned to take responsibility beyond the point where code is deployed. There is a difference between building something that works in a demonstration and building something that people depend on.

EPF Buddy has been an opportunity to experience that difference firsthand.