BOOTINGJRV//SYSTEMS/
Glove Former Tech Services needed two different things that don't share a codebase: a public site that reads like a precision operator to procurement buyers, and an internal ledger to bill the consultancy work and run payroll. We built both.
The public site and the internal ledger solve different problems for the same business. B2B procurement buyers land on an industrial site and bounce fast when they hit stock photos, a broken form or an eight-second hero — that's a credibility problem, and it's solved with a fast, well-built website. Billing the consultancy work GFTS actually does — audits, engagements, technical services — is a bookkeeping problem, and it's solved with a ledger, not a landing page. We treated them as two builds because they are.
The public site is a React + Vite single-page app with a Three.js 3D hero and GSAP scroll-triggered animation, kept smooth with Lenis. Below-fold components lazy-load with React Suspense so the performance budget survives the 3D hero rather than being spent by it — the site holds a Lighthouse performance score of 95 or above with the WebGL scene live.
Supabase runs analytics behind the scenes, so the site can be judged on real production traffic rather than a launch-day guess. Schema.org JSON-LD, an auto-generated sitemap and a preloader round out the technical SEO pass.
GFTS bills technical audits and consultancy, not tonnage, but the paperwork has the same shape as a haulage ledger already built for a different client: a month of dated line items becomes one invoice, and the same login runs payroll. Forking that codebase was the honest engineering call rather than building the same structure again from nothing.
The risk in forking is the one a previous fork of this exact codebase actually shipped: a rename that caught the visible strings and missed the rest, leaving an app whose link preview still named the wrong company. So every brand string here — company name, letterhead, tab title, link preview, authenticator label, cookie and cache names — reads from one module, `lib/brand.ts`, instead of being retyped across the app. There's one place a rename can be wrong instead of forty.
Payroll computes EPF, SOCSO, EIS and SKBBK off the official schedules and freezes the numbers onto the issued slip, so a later statutory rate change never rewrites what was actually remitted. Two-factor sign-in with single-use recovery codes and an office-facing user guide ship with the app.
Fork the ledger where the paperwork genuinely matches, but treat the rename as its own audited step rather than a find-and-replace. A single brand module is the difference between one place to check and forty.
