Jabir.
All work

Web App — 2026

GoldLoanPro.

A multi-tenant SaaS platform for gold-loan financing businesses.

Next.js 15React 19TypeScriptTailwind CSS 4Prisma 6PostgreSQLNextAuth v5RazorpayAWS AmplifyAWS S3
Visit live site

Role

Founder & Sole Engineer

Timeline

2026 · ~10 months

Team

Solo — Founder

Type

Web App

01

The Problem

Small gold-loan firms, pawn brokers, and NBFC-MFIs across India still run their lending on aging legacy software or manual registers. The legacy PHP system this replaces had no real double-entry accounting, no multi-branch data isolation, and no way to track bank repledging against utilization limits — so interest accrual, closures, and RBI-style financial reporting were slow, error-prone, manual work.

02

What I Built

I designed and built a multi-tenant SaaS covering the full gold-loan lifecycle — origination, compound-interest accrual, part-payments, closure, bank repledging, and KYC document management — on top of a real double-entry accounting engine that generates balanced journal entries atomically for every transaction and produces Balance Sheet, P&L, and Trial Balance reports automatically. The platform features per-organization data isolation with branch-level sub-tenancy, role-based access for staff, and plan-based usage metering with Razorpay billing. Built solo over ~10 months using an agentic AI-assisted workflow (Claude Code).

03

The Outcome

Live in production at gold-loan.jabirmj.com as a commercial product with a free tier and paid plans (₹999–₹2,999/month). The codebase spans ~150K lines of TypeScript across 33 Prisma models, 80 API routes, and 33 test suites. Structured production-readiness audits caught and fixed two closure-time fraud/validation-bypass vulnerabilities before launch.

— Architecture

How one loan event becomes a balanced ledger

  1. Organization

    The tenant boundary. Every row below is org-scoped, and branches are sub-tenants nested inside it.

  2. Branches

    Each branch has its own staff with role-scoped access, working inside the parent organization.

    a loan event happens

  3. Loan lifecycle event

    OriginationInterest accrualPart-paymentClosureRepledge
    posts to

  4. Accounting engine

    One prisma.$transaction(): the debit legs and the credit legs are written together. Any imbalance or failure rolls the whole transaction back — nothing half-posts.

    commit

  5. Journal entries

    The PostgreSQL ledger of record.

    derived from the ledger

  6. Financial reports

    Balance SheetProfit & LossTrial Balance
Origination, interest accrual, part-payments, closure and repledging all run through the same double-entry engine: each event writes its debit and credit legs inside a single database transaction, so the Balance Sheet, P&L and Trial Balance are derived from the ledger rather than keyed in by hand. Every row is scoped to one organization, with branches nested underneath it.
04

Key Decisions & Challenges

01

Built a true double-entry accounting engine — every loan event posts balanced journal entries in atomic transactions.

02

Designed multi-tenancy with per-organization isolation plus branch-level sub-tenancy under each org.

03

Shipped plan-based usage metering and subscription billing with Razorpay.

04

Found and fixed two closure-time fraud/validation-bypass vulnerabilities via structured production-readiness audits.

05

Delivered the entire product solo in ~10 months using an agentic AI-assisted workflow (Claude Code).

Previous

Waitamin

Next

Slrshoppee

Have a project in mind?

I'm open to freelance work and full-time roles. Let's talk about what we could build together.

Get in touch