Building a Custom SaaS Platform
From Zero to Production
In 6 Months.

December 2025. A blank repo and a list of requirements.

A USA-based founder was running an ISP sales operation — dozens of field reps selling internet services across multiple vendors, each with their own CSV exports, commission structures, and payscale quirks. Tracking commissions was a spreadsheet nightmare. Paying reps was slow, error-prone, and manual.

He needed a custom CRM built for this exact world. Not Salesforce. Not a generic tracker. Something purpose-built for the ISP sales commission lifecycle — from a rep reporting a sale on their phone to an admin processing payroll on the web.

He found me. I was a final-semester CS student in Pakistan with no professional production experience, no published apps, and $0 in freelance history. What I had was deep curiosity, a bias for shipping, and the ability to learn faster than most.

We started with a focused arrangement — daily meetings, aggressive scope, and a bias for shipping. I said yes to all of it.

ISP commission tracking is surprisingly complex.

At first glance, it sounds simple: rep sells service → vendor pays company → company pays rep. But the real world is messier.

Six months of shipping. Week by week.

This was not a slow, methodical build. It was a startup sprint — daily meetings, same-day PRs, features going live while users were actively logging in. Here's the arc of how this custom CRM platform came to exist.

The stack that made it possible.

Every technology choice was driven by one constraint: one developer, fast iteration, production stability. No compromise on either shipping speed or system quality.

The bugs that taught me the most.

Production problems are different from interview problems. They have history, politics, bad data, and consequences. These are the ones I'm most proud of solving.

The Pending Pay screen — a technical deep dive.

The Pending Pay module is the most architecturally complex feature in this platform. It merges two entirely different types of "money owed to reps" into a single unified view. Here's how the data flows:

Manager opens Pending Pay
        │
        ├── Step 1: Auth check (manager = true)
        ├── Step 2: Fetch team reps where payroll = true
        ├── Step 3: Build alias map (alias table → sales_id fallback → company-wide)
        │
        ├── Step 4: Fetch Ledger Entries
        │     └── ledgers WHERE paid_date IS NULL
        │           AND (status = 'Posted' OR status IS NULL)   ← critical: null = old records
        │           AND sales_id IN (payrollRepIds)
        │
        ├── Step 5: Fetch Active Payscales for team reps
        │
        ├── Step 6: Fetch payscale_logs → resolve who created each payscale
        │     └── manager_view payscales → show manager as trigger
        │     └── admin_only payscales → show admin creator as trigger
        │
        ├── Step 7: Fetch Approved Unprocessed Orders
        │     └── Order WHERE vendor IN (payscale vendor IDs)
        │           AND (approved_topay = true
        │                OR approved_to_pay_date IS NOT NULL
        │                OR approved_topay_at IS NOT NULL)       ← 3-signal filter
        │           AND pay_processed IS NULL
        │
        ├── Step 8: Build orderRepMap
        │     └── Pass 1: order_to_rep joins
        │     └── Pass 2: Vendor_SalesRep column name match     ← the missing fallback
        │
        ├── Step 9: Fetch pay_multiplier table
        │     └── amount = base_payscale_amount × multiplier
        │
        └── Merge → buildEntries() → groupByRep() / groupByVendor()
              └── Render: 3-level accordion (Rep → Vendor → Product → Customer)
        

The key insight that took longest to find: the web app used a Vendor_SalesRep column as a secondary fallback for rep matching when no order_to_rep record existed. The mobile app didn't implement this fallback, silently dropping those orders from the view.

Full-stack ownership across all systems.

What six months of daily production work actually teaches you.

You can read every blog post about distributed systems and multi-tenancy. Nothing replaces the feeling of a production bug at 2 AM with a real user waiting. Here is what I actually internalized:

1. Ship, then protect.

The fastest way to understand what matters is to watch real users break things. The import pipeline had three complete rewrites because actual production data was nothing like our test data. The spec was wrong. The users were right.

2. The edge case is the case.

Placeholder phone numbers (value: "0"), null ledger statuses from legacy entries, orders matched via Vendor_SalesRep instead of order_to_rep — every major bug was something that "shouldn't happen" but did. Defensive data handling is not optional in production.

3. The database is the source of truth. Trust it.

A rule that became mine early on: "When it comes to ledgers, match what is in the database. Always." Don't programmatically change the sign of a value. Don't assume format. Read what's there and display it faithfully.

4. User-guided errors beat silent failures.

The biggest quality-of-life improvement was adding column validation indicators, required field markers, and downloadable import templates. The operations team stopped messaging at 2 AM about failed imports. Users fixing their own data beats developers debugging their data every time.

5. Think, then agree, then build.

A principle I internalized on this project: "Let's think and talk then agree then make changes." I learned to slow down before complex features, confirm understanding explicitly, and build once rather than build, revert, rebuild.

Competing with a 2-year head start.

During development, a competitor CRM was identified in the same ISP sales space — operational since 2023, priced at $33–$100/month per account.

The competitor had a two-year head start and an established team. This platform was built by one developer in six months with full-stack ownership. The differences emerge in how we serve this specific market:

Moving from engineering outputs to business outcomes.

The real value of this platform isn't measured in lines of code or pull requests — it's measured in operational impact.

The journey from student to production engineer.

While the founder drove the business vision, domain expertise, and client relationships, I owned the full-stack development, system architecture, deployment pipeline, and day-to-day evolution of the platform. We moved at startup speed because enterprise clients were waiting and reps needed to be paid accurately.

This meant designing the database schema, building role-based dashboards, publishing the iOS app, integrating AI systems, and debugging production issues at any hour. It meant shipping 99+ pull requests while supporting real users in a real business.

I started this project as a final-semester student with no production experience. I'm finishing it with the kind of hands-on SaaS engineering knowledge that typically takes three to five years to accumulate. Not because I'm exceptional — but because I said yes to hard problems, shipped before I felt ready, and learned from every production bug rather than treating them as failures.

Other systems I've built.

Each project pushed me into different engineering territory. Here's what else I've shipped — all production, all end-to-end.