← All work
In build · repo publicProduct Engineering

New England Event Planners

An event planning and coordination platform built around a tested revenue path, a typed data layer, and build gates that have to pass before anything ships.

My role
Sole engineer. Architecture, data model, application logic, test strategy.
Stack
Next.js 16React 19TypeScript (strict)Tailwind CSS v4PostgreSQLDrizzle ORMZodVitestPlaywright

The problem

An event coordination business runs on enquiries that convert. One path carries the revenue: visitor to qualified, attributed, stored enquiry. That is also the path where a silent regression costs the most and gets noticed the latest.

What I built

A Next.js 16 App Router application on React 19 and strict TypeScript, with PostgreSQL behind Drizzle, Zod validation at every boundary, and admin, draft and venue systems. The revenue-critical flow has a dedicated test suite and a dedicated end-to-end verification script that runs against a real build. Supporting scripts enforce a performance budget and a page contract, and the production build can run without a database so CI does not need Postgres to prove the app compiles.

The hard part

Making the important path impossible to break quietly. 'Money path' is a named concept in the codebase with its own Vitest suite and its own e2e script, so a regression there fails a command rather than surfacing as a slow month. Rate-limit state is reset before the e2e run so the check is deterministic, and toolchain versions are pinned with the reason recorded as a numbered decision instead of left to whoever upgrades next.

Evidence

Architecture

How a request moves through it.

  1. Visitorin

    Arrives from organic search or a campaign with attribution parameters.

  2. Attribution capturesvc

    Source is captured and carried through the session, with its own test suite.

  3. Zod validationsvc

    Typed schemas at the boundary. The server never trusts the client's shape.

    ↳ Rejected

    Invalid or abusive input is refused at the boundary. Each rejection path is an assertion in the security and validation suites, not an assumption.

  4. Rate limitingsvc

    Bucketed in Postgres, and reset deterministically before every e2e run.

  5. Drizzle + PostgreSQLdb

    Enquiry written through a typed data layer under versioned migrations.

  6. Admin surfacesvc

    Authenticated review, drafts and venue gating behind an access boundary.

  7. Verified enquiryout

    Stored, attributed, and covered end to end by verify:e2e against a real build.

The money path. Every stage can reject, and every rejection is a test case rather than a surprise.

Technical decisions

What was chosen, and what it cost.

The revenue path is a named, separately tested concept.

WhyThe flow that produces income deserves a harder gate than the rest of the application. Naming it makes it something a test can defend.

CostIt adds a second verification lane to maintain alongside the normal unit tests.

A production build that runs without a database.

WhyContinuous integration should be able to prove the application compiles and renders without provisioning Postgres for every run.

CostA build-time shim to maintain, and database-dependent behaviour moves to the e2e lane.

Toolchain versions pinned, with the reason recorded as a numbered decision.

WhyAn unexplained pin gets removed by the next person who sees an available upgrade. A recorded reason survives.

CostUpgrades become deliberate work rather than routine maintenance.

Zod schemas at every boundary rather than trusting types alone.

WhyTypeScript types vanish at runtime. The server has to re-check anything that crossed the network.

CostSchema duplication between the type layer and the validation layer.

Constraints

  • Continuous integration must pass without a provisioned database.
  • End-to-end checks run against a real production build on a real port, not a dev server.
  • Rate-limit state is cleared before e2e so the run is deterministic rather than order-dependent.

How it is verified

  • pnpm verify runs typecheck, lint, 106 tests and a production build. One command, one answer.
  • pnpm verify:e2e resets rate-limit buckets, walks the money path in a browser, then checks the page contract and the performance budget.
  • A page contract script asserts required structure exists on the pages that matter.
  • A performance budget script fails the run when a page exceeds its weight allowance.

Outcome

  • 106 test cases across six suites, all of them runnable by anyone who clones the repository.
  • Nineteen engineering decisions and eleven architecture documents written down alongside the code.
  • Three versioned migrations. Schema changes are reviewable history, not drift.

What I would tell someone building this

  • Naming the money path changed how it got treated. An unnamed critical flow gets tested like ordinary code.
  • A performance budget that fails a command is worth more than a performance report nobody opens.
  • Recording why a version is pinned prevents the upgrade that quietly breaks the build six weeks later.

Questions about how this was built, or want something like it?

All workStart a conversation