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 is the team’s tools dashboard. Its Player Profile CMS holds the recruit record; Huddler builds that recruit’s custom enrollment plan; and the forthcoming Service Tracker will turn purchased services into delivery work.

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

· Skip replaces a long lead-intake form with a conversation, then hands the structured lead to the Player Profile CMS.

· FluxEngine is the delivery tool behind one of the services Huddler sells: it 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.

Features

· One place to create a recruit for money. Huddler shapes the plan in the room while the family watches; sending it freezes services, term, total, and payment structure, and nothing downstream is allowed to recompute the deal.

· Money that cannot safely believe its first answer. Every attempt claims the pending plan, reconciles against Stripe, and adopts an existing schedule before creating another. Webhooks are ledgered by event identity, and when the system cannot honestly converge it freezes the row and pages a human.

· An incident promoted to law. The first installment family produced three trialing subscriptions, and a leftover draft invoice later auto-advanced into a second real charge. The fix was not “remember to delete drafts” — it was making reconciliation ask Stripe what already exists on every attempt, healing path included.

· Outbound mail behind a hard wall. Coach outreach leaves from the recruit’s own mailbox under eleven server-side checks and one singleton transport gate; a client button can say Launch while the server says no.

· Three states, never collapsed. Code-clean, proven, and live-functional are distinct claims, and the gaps between them produced the platform’s most important corrections — from a comma-free fixture suite to an OAuth proof that connected the wrong Google client.

· Alerts that refuse to rot. Money-path page markers resolve through one registry that throws on an unknown name, with a bidirectional check proving the emitted and registered sets match. A noisy page channel is treated as no page channel.

· An honest edge. As of August 31, 2026: the staff platform, Huddler with live payment status, the money paths, Skip v2.2, and the FluxEngine operator surface are production systems, with the credential-free suite at 255 passing tests — while the service-delivery logging layer remains specified and deliberately unbuilt.

A recruiting plan built in the room

Huddler replaces the familiar sequence of sales call, PDF quote, follow-up email, and quiet loss of momentum. A Scout uses it while speaking with a recruit and family: the family watches as the required core package becomes a plan shaped around that recruit, the Scout sets the term and payment structure, and a payable checkout link goes out before anyone hangs up. It is an internal tool designed to be screen-shared, so staff operate it while every word remains clear enough for the family watching.

That flow makes Huddler the one place a recruit can be created for a money path; Checkout, payment webhooks, and the plan tracker cannot invent another identity downstream. Sending the plan also freezes its services, term, total, and payment terms. Nothing later is allowed to recompute the deal. A live status tracker closes the loop on the same screen, letting the Scout watch the family open the link and complete payment while they are still talking. The next platform seam is the Service Tracker: after Stripe confirms payment, the frozen services Huddler sold become the work the team must deliver.

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, Huddler enrollment builder and checkout flow, money paths, Skip v2.2, and the FluxEngine operator surface are production systems. Huddler is live for staff to build a family’s custom plan during the enrollment call, send its frozen checkout, and watch payment status return while the conversation is still happening. 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.