A services marketplace, then the same codebase sold twice

Team Advertiser is a digital marketing agency that needed to sell services the way a marketplace does: a catalogue with tiered pricing, a negotiation step, an order pipeline, payment, delivery and a dispute process when it goes wrong.

The most interesting outcome was not planned. Once the platform was running, the same codebase was rebranded and deployed for a second client on entirely different infrastructure — turning a bespoke build into a repeatable product without a rewrite.

Three parties with genuinely different permissions. Clients, agency staff and a superadmin who arbitrates disputes and cannot be modified by ordinary admins. Getting this wrong means either staff seeing customer data they should not, or an admin being able to quietly rewrite a disputed order.

Payments that must reconcile. A payment webhook can arrive twice. If the handler is not idempotent, the second delivery credits the account again — and this only surfaces as a discrepancy weeks later.

Real-time chat, including for visitors who have not signed up. An unauthenticated socket connection is an open door unless the handshake itself is verifiable.

Serverless was not an option. WebSocket connections need a persistent process, which ruled out the deployment target the client initially assumed.

Three role tiers with a protected superadmin. Dispute resolution, coupons, role changes and audit logs sit above the admin tier, so an admin cannot alter the record of a dispute they are party to.

Idempotent payment capture. Order status and payment recording happen as a single all-or-nothing database operation, and a repeated webhook delivery is recognised and ignored rather than replayed.

Signed guest chat. Visitors who have not registered can open a support conversation, with the handshake authenticated by an HMAC signature — so the socket is open to the site, not to the internet.

Deliberate infrastructure choice, written down. A persistent Node process behind Nginx with a pinned runtime, on a multi-tenant VPS where restarting the wrong process would take down another client's site. The operations runbook exists specifically so that does not happen.

Defence in depth on inputs. Schema validation, sanitisation against XSS and NoSQL injection, shared rate limiting, TOTP two-factor authentication for staff, and pagination capped so a crafted request cannot exhaust memory.