Invoice Portal

A supplier relation management portal built for Diamond Fabrics, part of the SAPPHIRE group. Suppliers sign in, submit invoices against the purchases made from them, and the system updates accordingly — no email threads, no paper chase.

The front end is Next.js with Tailwind; the back end is NestJS. The portal leans on Next.js server-side rendering so pages arrive already built and ship less JavaScript to the browser — which matters when the people using it are suppliers on modest hardware and unpredictable connections, not engineers on fibre.

TODO(zain): Write two or three sentences here that a stranger could read and immediately know what this product is. Who logs in? What do they do in their first thirty seconds? What happens on the other side of the submit button?

Problem

Real facts, so far: the portal exists to make the link between an order and its receipt verifiable. Purchases at Diamond Fabrics are made by people on the company’s behalf, and each purchase is expected to have a receipt behind it. Before the portal, there was no systematic, order-by-order way to check that — matching a receipt to the order it belonged to was a manual step, done after the fact, which meant a mismatched or incorrect receipt could sit against an order without anyone easily noticing.

The request came from the top: SAPPHIRE’s CEOs asked for this on behalf of finance and management, not as a developer-led initiative. What they wanted was a way to check the money moving through orders against what was actually being spent — a control the existing process didn’t have. The portal answers that directly: each purchaser gets their own credentials, sees only their own orders, and uploads the receipt against the specific order it belongs to. The receipt is attached to the order automatically, at the point of purchase, rather than matched to it later by someone working from loose paperwork.

Research

TODO(zain): Did you talk to the people who’d use it — suppliers, the finance team, procurement? What did you learn that changed the design? If you didn’t do formal research, say so honestly and describe what you did do instead: reading the existing process, shadowing someone, digging through the ERP data model. Also: what existing systems did you have to understand before you could write a line of code, and how did you learn them?

Architecture

Real facts, so far: Next.js (SSR) front end, NestJS API, Tailwind for styling.

TODO(zain): Draw the boxes. What sits between the supplier’s browser and the database? Where does purchase data come from — an ERP, SAP, a separate DB? How does an invoice get from the portal into whatever system finance actually works in? What’s the database, and what does the core schema look like (supplier, purchase, invoice, line item, status)? How is auth handled, and how do you know a supplier can only see their own purchases?

NestJS was a deliberate choice on the back end, for two reasons, and both are real. The technical one: NestJS’s structure — modules, dependency injection — scales past a solo file in a way a bare Express app doesn’t once there’s more than one contributor or more than one route file’s worth of logic. The other reason is just as honest: this was a chance to learn NestJS properly, rather than a framework picked to sound good on a résumé. SSR earned its place for the reason already noted above — it means suppliers on modest hardware and unpredictable connections get a page that arrives already built, rather than one assembled client-side after a slower first paint.

Development

TODO(zain): How was this built and by whom? Were you solo or on a team — and if a team, what was yours to own? How long did it run? What was the deployment story: where does it run, how does a change get from your machine to invportal.dfl.com.pk? Was there a staging environment, a review step, a QA pass?

TODO(zain): Pick the one part of the build you’re proudest of and explain it properly — the invoice submission flow, validation against the purchase record, file handling, the status machine, whatever it is. This is the section where an engineer reading your portfolio decides whether they want to work with you. Show the thinking, not just the stack.

Challenges

TODO(zain): Name three real ones. Candidates, if they ring true: matching a submitted invoice against the right purchase; handling duplicate or partial invoices; suppliers with poor connectivity or old browsers; integrating with a system you didn’t control; permissions across multiple supplier accounts. For each: what broke, what you tried, what actually fixed it.

Results

The Invoice Portal wasn’t pushed further after I left the company, and since then no React developer has been hired to maintain it.

Lessons learned

TODO(zain): What would you build differently if you started this again on Monday? What did this project teach you that you’ve carried into everything since? And — the question that makes a case study credible — what did you get wrong the first time?