One Developer Investor ERP

Square One Capital sells property units to buyers who then pay in installments over time. Before this portal, a buyer with a question about their account — how much is due, when, whether last month's cheque cleared, or getting a copy of their allotment certificate for a bank loan application — had no self-service option. They called or visited the office, and staff looked it up manually in the ERP (ResERP) or the company's own records. The earlier version of this client's system (the onecapitalinvestment/backend_onecapitalinvestment repos) tried to solve this by having Square One Capital's own admins manually re-key investor, property, and transaction data into a separate Postgres database — which meant two sources of truth and admin time spent on data entry that the ERP already had.

ResERP is the client's existing, external, staff-facing ERP — not something this project could modify. Its client-facing API surface is fixed at 11 endpoints, all read-only except login, with no admin/bulk endpoint, no pagination, and (per docs/API_Integration.md §6) no documented error-response shape or shape consistency between endpoints. The vendor-supplied documentation (Postman collection + PDF) turned out to be wrong or incomplete on two load-bearing points — the PDF_TOKEN auth and the /product/:id response shape — discovered only by making real calls against the live API. Solo developer, five-day build, no dedicated QA, and (per docs/Git_Workflow.md §4) an open question the whole build shipped under: whether a sandbox ResERP instance exists at all, or whether dev/staging testing during the build was hitting real buyer CNIC/password data.

The core decision was to build nothing but a frontend. ResERP already holds every fact this app needs — units, payment schedules, receipts, PDFs — so there is no database, no data model, no sync job. The app is a Next.js BFF (backend-for-frontend): every ResERP call happens server-side in a Route Handler or Server Component, using a RESERP_BASE_URL env var and a bearer token that never reaches the browser. This was chosen over a client-side SPA calling ResERP directly because that would have put the ResERP token in browser JS and made CNIC/password traffic visible in devtools — unacceptable for a portal whose only credential is a national ID number. Auth uses a two-tier check: proxy.ts (Next.js 16's replacement for middleware.ts) does an optimistic cookie-presence check to redirect unauthenticated requests before they render anything, but every Route Handler independently re-verifies the session via verifySession() before touching ResERP — the proxy check alone is documented upstream as insufficient, and I treated that as a hard rule rather than a suggestion.

The session itself is a signed, httpOnly JWT (via jose) holding the ResERP login token, not the token in localStorage or a readable cookie. Because ResERP has no admin/list-all endpoint, there is no server-side aggregation or caching layer beyond what a single buyer's own session token can see — this rules out ever building an admin view against this API without a second, different ResERP credential the client would have to provide. Data fetching is organized as one lib/*.ts module per ResERP resource (units.ts, schedules.ts, receipts.ts, pdf.ts), each owning its own response typing rather than sharing one generic envelope type, because docs/API_Integration.md §6 documents that ResERP's data shape is inconsistent across endpoints — sometimes a named key, sometimes a bare array, sometimes an object that becomes an array only in list mode. Typing each one separately, instead of one clever generic wrapper, is what caught the bugs below at the type level once they were understood.

This started as a pivot, not a greenfield idea — the client already had onecapitalinvestment and backend_onecapitalinvestment running, a full custom platform where Square One Capital's admins manually entered every investor, property, and transaction. When ERP (ResERP) API access became available, the obvious question was whether to retrofit the existing Postgres-backed app to sync from ResERP, or build something new and much smaller that just reads from ResERP directly. I chose the second option, and this repo is the result — no database at all, because ResERP already is the database for everything this portal needs to show.

The first real scare was two days in, seeing every unit detail page return "not found" for every account in production. My first instinct was to suspect the auth layer, since that was the newest code — I spent time re-checking verifySession() and the cookie flow before actually diffing the single-unit response against the list response and seeing the object-vs-array mismatch. That was a useful, humbling lesson: when something fails for literally every user, look at the data shape before the auth code, because "works for nobody" points at something structural, not something session-specific.

The PDF_TOKEN question is the one I'm most glad I didn't guess on. The client had handed over what looked like a legitimate, documented credential, and it would have been easy to wire it in, watch the PDF downloads return something, and move on without noticing the response was a 200-status JSON error body pretending to be a success. Actually curling it and reading the bytes back — %PDF-1.7 vs. a JSON error — is the difference between shipping a working feature and shipping a broken one that looks fine in a quick manual test.

If I were doing this again, I'd push harder, earlier, on the open sandbox-environment question flagged in docs/Git_Workflow.md §4 — building and testing against what might be the live production ResERP instance with real buyer CNICs is a real data-handling risk that got documented rather than resolved, because resolving it wasn't in my control. I'd also add automated tests around the response-shape assumptions in lib/units.ts and lib/schedules.ts specifically, since both bugs found so far in this project were exactly that category of mistake, and there's currently no test suite catching a regression to the same pattern.

Shipped through six implementation phases (e900197 initial foundation through the feature/phase-6-polish merge) between 2026-07-21 and 2026-07-25, plus a further round of dark-theme redesign and bug fixes on 2026-07-25, promoted through the dev → staging → main branch flow described in docs/Git_Workflow.md. Delivered: CNIC-based login, a buyer's full unit list and per-unit detail (size, layout, registration number, tenant status, utility-bill counters), payment schedule with status filtering, upcoming-installment highlight, receipt history, and all five ResERP PDF documents (statement, booking form, allotment certificate, receipt, upcoming-installment notice) as authenticated streaming downloads — with the PDF_TOKEN and /product/:id issues fixed before or shortly after they reached production.

md` §8 — none of these are recorded in the repo.

One Capital Investment is a full-stack property investment management web application. Administrators manage four property types (Rental, Development, Holding, Other) through a draft/publish workflow, track investor lifecycles, run support ticket queues, and review a comprehensive audit log that records every create/update/delete with IP and user agent. The investor portal lets users browse available properties, view their portfolio and transaction history, upload documents, and review personal analytics.

Built with Next.js 15 / React 19 on the frontend and a Node.js + Express.js REST API on the backend, backed by PostgreSQL (Neon) via Drizzle ORM. Redis caching with configurable TTL and graceful degradation, Cloudinary for organized media storage, and Nodemailer for OTP-based email flows round out the stack.