Northline Recruiting is a made-up name used here to protect the client’s identity. The system itself is the operating platform behind a three-partner football recruiting and NIL firm. It is not the public brochure site. It is the desk behind it: the place where staff manage recruits, assemble service plans, charge families, reconcile money, and prepare outreach to college coaches.

I serve as Fractional COO and systems architect through Pyris. I designed the platform, direct the coding agents that help build it, run every destructive database change myself, and own the distinction between code that is green and a system that is safe to point at a family’s money.

The product has four cooperating layers:

· Front Office, Huddler, and Checkout hold staff records, build a plan from the service catalog, and turn that plan into a public payment session.

· The money layer handles full payment, deposits plus installments, staff invoices, arrears, refunds, and reconciliation against Stripe.

· Skip replaces a long recruit-intake form with a conversation and writes the structured record as a byproduct.

· FluxEngine builds and sends coach-outreach campaigns from the recruit’s mailbox under a server-enforced transport gate.

Those are not four products bolted together. They are four parts of one business process with two unusually expensive blast radii: real money and outbound mail to real people.

Money that cannot safely believe its first answer

The billing problem looks ordinary until time becomes part of the threat model.

A family can open a checkout link for seven days. Stripe retains an idempotency key for roughly twenty-four hours. A deterministic key therefore prevents a duplicate schedule during the concurrency window, then quietly stops being a guarantee while the customer’s legitimate link is still alive.

The production defense is layered. A pending plan is claimed before work begins. Every attempt reconciles against Stripe and adopts an existing schedule before creating another. Webhooks are ledgered by event identity because they arrive late, out of order, and more than once. Stripe owns the installment schedule; Northline records what actually happened. When the system cannot honestly converge, it freezes the row and pages a human instead of throwing and hoping a retry is wiser.

That architecture was earned through a live incident. The first family on the installment path produced three trialing subscriptions. Recovery closed the immediate problem, but a leftover draft invoice later auto-advanced on Stripe’s own timer and created a second real charge about an hour after the first. The customer declined a refund; I applied the amount forward as account credit and then closed the bug class rather than patching the one plan.

The useful lesson was not “remember to delete drafts.” It was that a local model of the transaction was insufficient. Reconciliation had to ask the payment processor what already existed on every attempt, including the healing path.

Outbound mail with a hard wall

FluxEngine was ported from an earlier outreach system into Northline, but it was not allowed to carry its old assumptions with it.

The first rule is ownership. Mailboxes, OAuth consent, database records, and the Google project belong to the client—not to my personal accounts and not to Pyris. The second is authenticity: coach-facing mail comes from the recruit. The third is transport: a campaign cannot send because a client button says it may; eleven server-side checks and one singleton gate decide whether anything can leave.

The operator builds a campaign, selects recipients from the coach directory, and schedules delivery through Ariadne, a thread that assigns send times at build rather than sleeping between jobs. Re-spinning a campaign changes time, not order. Suppression is permanent. A global kill stops campaigns and revokes transport without erasing the evidence needed to understand what happened.

The recipient picker is one of my favorite examples of the site’s working method. The first design was a cascading Role → Position interface with counts and substring matching. On paper it was richer. In the live directory it was wrong: “Head Coach” also caught “Assistant Head Coach,” compound titles behaved unpredictably, and counts made a brittle taxonomy look authoritative.

The replacement is deliberately simpler: one flat checklist populated from the directory, exact matching, and no counts on the boxes. “Coaches” is checked by default and is byte-identical to applying no title filter. In the August 29, 2026 walk, 57 selectable terms reached 7,738 of 8,101 non-blank titles; the remaining 363 were administrators rather than people the selector should pretend to understand.

That is not a UX anecdote. It is an architecture rule: the live distribution gets to veto the elegant taxonomy.

The proof gate

Northline distinguishes three states that are easy to collapse:

1. Code-clean — the implementation builds and its tests pass.
2. Proven — the promised property appears in before-and-after rows or an equivalent controlled proof.
3. Live-functional — the deployed system performs the real path with the real boundary conditions.

The gaps between those states produced most of the platform’s important corrections.

A test suite once passed because every term in its fixture list happened not to contain a comma. Another harness was one unguarded replace-all away from deleting all 8,042 coach-contact rows; a refusal guard stopped it at the boundary. Express returned an HTTP 304 with no body and made dozens of client calls look like separate product defects. An OAuth proof connected FluxEngine using Skip’s Google client because both credential sets had plausible names. Each failure looked local until the system was exercised as a system.

The alert layer follows the same discipline. Money-path page markers resolve through one registry that throws on an unknown name. A bidirectional check proves that the emitted set and the registered set match. A noisy page channel is treated as no page channel.

What is live

As of August 31, 2026, the React application is live on Vercel, the Node API is live on Railway, and Supabase provides Postgres and authentication. The API health endpoint returned 200 that morning and—correctly—did not pretend its package label was a deployed source version.

The staff platform, money paths, Skip v2.2, and the FluxEngine operator surface are production systems. The coach-title selector walk covered 8,101 non-blank titles. The credential-free suite closed August 29 at 255 passing tests. Those are separate wires measured at separate times, not one claim that “the platform is 8,101 things large.”

The system still has boundaries. Build C, the service-delivery logging layer, was specified and never built. The external public-site seam for Skip exists in the application but was not live-verified in the August 31 brief. A production system is allowed to have an honest edge; it is not allowed to hide one inside the word complete.

Why this belongs in the portfolio

Northline is the clearest example of how I work when software has consequences.

I did not begin with a pristine architecture and implement downward. I built a working business surface, watched it fail at the seams between systems, and promoted each surviving correction into an invariant: Stripe owns the schedule; a count keeps its identity; a model never becomes the cashier; an outbound gate lives on the server; the person who can destroy data types the command; built green is not works live.

The product is useful because of its features. It is trustworthy because of the things those features are structurally unable to do.