zsty.us

Before / After · Case Study

Global Merchant Processing — a quiet security check that became a full rebuild

A friend's payment-processing company got a passive, look-don't-touch security review of their website — and it turned up problems serious enough that patching wasn't the honest answer. The customer-facing site is now being rebuilt from the ground up on a foundation the company controls, with the company's name held back until they sign off on going public.

When a passive audit surfaces serious holes in a friend's frontend, the right move is rebuild — not patch.

At a glance

What this rebuild covers.

  • Security

    A passive review of the public site — no logins, no poking at anything private — surfaced holes serious enough that the honest recommendation was a rebuild, not a round of patches.

  • Security

    The specific findings stay private while the new site is being built — publishing them now would advertise an open door on a friend's live business.

  • Agents

    The engagement opened with the same automated audit pass used to qualify every prospect: show the owner exactly what's broken before pitching anything.

  • Design

    The rebuild keeps the company on its own brand and look — customers land on the same business, just on a site that's owned, reviewed, and actually fixable.

The story

Problem · Insight · Build · Outcome.

  1. 01 · Findings

    Passive audit surfaced serious frontend security holes.

    Standard pre-engagement scan turned up issues that went beyond what a patch sweep would responsibly address. Findings shared privately with the client; not published while the rebuild is in flight.

  2. 02 · Decision

    Rebuild, not patch.

    With a friend's business on the line, the honest call was a full frontend rebuild on the operator's modern stack rather than a fix-and-pray sweep. Client agreed; engagement opened.

  3. 03 · Build

    In flight on the operator stack.

    Same Next.js + TypeScript strict + Drizzle/Neon + Vercel stack used across the rest of the portfolio. Customer-facing flows rebuilt first; admin + data migration follows. Detailed scope held pending client sign-off on public attribution.

  4. 04 · Pending public attribution

    Public case study unlocked when the client signs off.

    When the client confirms what's safe to publish — name, domain, sector, before/after screenshots — this entry flips `pendingApproval: false` and lands the full case study. Until then it's reachable only by direct URL with `noindex,nofollow`.

For the technically curiousHow it was done
  1. 01

    Where it started

    A friend's company in the merchant-processing space, running its customer-facing site on a vendor-controlled frontend. The engagement began the same way every prospect gets qualified: a passive security audit of what's publicly visible — nothing touched, nothing logged into.

  2. 02

    What the audit found

    The scan surfaced serious frontend vulnerabilities — beyond what a responsible patch sweep would address. The findings were shared privately with the owner and are deliberately withheld from this page: detailing them while the old surface is still live would publicly advertise an unpatched issue.

  3. 03

    The decision: rebuild, not patch

    With a friend's business on the line, a fix-and-pray sweep over a vendor-controlled frontend wasn't the honest call. The recommendation was an end-to-end rebuild of the customer-facing site; the client agreed and the engagement opened.

  4. 04

    The rebuild

    The new site is in flight on the same proven foundation as the rest of the portfolio: our hosting platform, a strictly-typed and source-controlled codebase, and a managed database — with compliance-aware copy and disclosures for the payments space. Customer-facing flows come first; the admin surface and data migration follow.

  5. 05

    What unlocks later

    Once the rebuild ships and the client confirms what's safe to publish — name, domain, sector, before-and-after screenshots — this entry becomes a full public case study. Until then, the details stay gated on the client's sign-off.

Before

  • Vendor-controlled frontend with disclosed vulnerabilities
  • Findings withheld pending client sign-off

After

  • modern web framework
  • TypeScript strict
  • managed Postgres
  • edge hosting we operate
  • Compliance-aware copy + disclosures

What changed, with evidence

Agent backbone

Audit-first engagement model

The work started with the same passive-scan pattern used to qualify other prospects: surface what's broken or risky before pitching a fix. The findings on this site were severe enough that a patch pass wasn't appropriate — a rebuild was the honest recommendation.

Design

Frontend rebuild on the operator stack

Rebuild keeps the company on its own brand surface but rehosts the customer-facing flows on the operator's modern, source-controlled stack — Next.js with TypeScript strict, Drizzle/Neon for data, Vercel for hosting. Removes the classes of frontend issues that drove the original findings.

Retention

Client-confidential until shipped

Name, domain, and the specific vulnerabilities are withheld from this public entry while the rebuild is in flight. Publishing them now would publicly advertise an unpatched surface against a friend's business.

← All rebuilds

Global Merchant Processing — a quiet security check that became a full rebuild — zsty.us