[ MIDSEASON — FOUNDED APRIL 2024 · ≈9 MIN READ ]

An AI-powered sports marketplace, from zero to $250K in 90 days.

Founder & Product Lead Strategy UX/UI Design system Development leadership
ROLE
Founder & Product Lead
TIMELINE
April 2024 — Present
PLATFORM
iOS · Android · Web
STACK
React Native · Stripe
STATUS
Live
[ ASSET: ms-case-hero — 21:9 ]
[ TL;DR — THE 90-SECOND VERSION ]
THE PROBLEM

Sports organizations run on fragmented admin tools while athletes have no central place to discover events, courts or community — two connected problems nobody was solving together.

MY ROLE

Founder and product lead: I own strategy, research, UX/UI, the design system and go-to-market, and I oversee our team of developers — every screen on this page is my design, shipped under my direction.

THE OUTCOME
$250K+PROCESSED WITHIN 90 DAYS OF LAUNCH
11,696MATCHES GENERATED
3,000+USERS AND COUNTING
[ CONTEXT — WHY THIS, WHY NOW ]

Club sport runs on software that treats sport as admin work. I kept seeing the gap from the sideline — so I built the fix.

Organizations stitch together registration, scheduling, payments and communication from tools that were never designed for them. Athletes get the leftovers: no central place to find events, courts or community. Each side's problem makes the other's worse — disorganized clubs can't reach players, and disconnected players can't fill programs.

Midseason is the marketplace answer: one AI-powered platform connecting both sides across mobile and web. Marketplace, because the value compounds — every organization that joins makes the platform more useful to athletes, and vice versa.

Volleyball first, on purpose. A single sport keeps the cold-start problem winnable and the product opinionated — but every layer beneath it, from the design system to the data model, is architected for multi-sport expansion.

[ THE TWO-SIDED PROBLEM ]

Every decision has two customers.

[ ATHLETES WANT ]
  • Discovery — events, leagues, courts near them
  • Profiles that get them seen and scouted
  • Access — simple sign-up and payment
  • Community around their sport
[ ORGANIZATIONS WANT ]
  • Registration that runs itself
  • Payments without the paper chase
  • Insight into their leagues and members
  • Reach — a pipeline of new athletes

Two audiences, two distinct surfaces, one product. Everything that follows — every feature, flow and tradeoff — was designed against both columns at once.

[ THE ATHLETE SIDE ]
Discover: a dark map of Parksville with event pins for a run club and adult triples, and a 7 events tray
DISCOVER — EVENTS ON A MAP, NOT IN A LIST
Discover list: event cards with Closing soon, Near capacity and Waitlist open status badges
DISCOVER — STATUS BADGES DO THE TALKING
Registration sheet: register as yourself or a dependent, with a parent account and two dependents listed
REGISTER — PARENTS BOOK FOR DEPENDENTS IN ONE FLOW
League leaderboard for Mens Doubles, Session 3: ranks, movement arrows, match records and points
LEADERBOARD — LEAGUE-WIDE, UPDATED AFTER EVERY SESSION
[ MY ROLE, EXACTLY ]

This is my company, so the credit line is simple: strategy, research, UX/UI, design system, payments design and go-to-market are mine, and I oversaw our team of developers through the build. Everything shown here was designed by me and shipped under my direction.

That's the point of this case study. Founder-of-the-product isn't a conflict of interest — it's the one context where a reviewer can see every layer of my range on a single artifact: the market call, the product strategy, the interface craft, the system underneath it, and the shipped React Native product.

[ CONSTRAINTS — WHERE THE JUDGMENT LIVES ]

Four constraints shaped everything.

[ 01 — TWO-SIDED COLD START ]

No athletes without orgs, no orgs without athletes

The classic marketplace trap. It's why Midseason launched volleyball-first in specific regions rather than everything everywhere: density in one community beats thin coverage of ten. It's also why organizations came first — each org that onboards brings its athletes with it.

[ 02 — SAFEGUARDING FOR YOUTH SPORT ]

Some of the users are minors

Club sport includes kids, which makes messaging and profiles a safety design problem before they're a growth feature. Safeguarding shaped the communication model from the first wireframe — not retrofitted after an incident. The full decision is in deep dive 04.

[ 03 — PAYMENTS COMPLIANCE ]

Real money, real rules

A marketplace that moves registration fees is regulated infrastructure, not a widget. Building on Stripe bought compliance and trust, and priced in its constraints: their flows, their verification requirements, their rails. Deep dive 02 covers the tradeoff.

[ 04 — FOUNDER-LED DESIGN AND BUILD ]

A lean team, one accountable owner

Every feature costs my design time and our developers’ engineering time from the same calendar. That constraint built the discipline this page keeps returning to: smallest thing that serves both sides, shipped, measured, then extended. It's also why the AI-native workflow below exists.

[ DEEP DIVE 02 — MARKETPLACE PAYMENTS & MONETIZATION ]

The marketplace isn't real until money moves.

THE PROBLEM

Club sport money moves through e-transfers, cheques and spreadsheets. For organizations it's unpaid admin work; for parents and athletes it's friction and zero visibility. And for a marketplace, payments aren't a feature — they're the proof the model works.

THE OPTIONS

The standard startup play is to launch free, build an audience, and add payments "later" — it's less build, less compliance, and less risk for an early-stage founder. The alternative was to make payments part of v1 and carry the full weight of marketplace payments compliance from day one.

THE CALL & THE COST

Payments shipped in v1, built on Stripe. The cost was real: the heaviest engineering lift in the product, compliance obligations, and Stripe's constraints baked into my flows. But a sports platform without payments is a directory — and a marketplace thesis you can't test. Revenue is the only validation that doesn't lie.

SHIPPED

End-to-end marketplace payments: registration checkout designed for the athlete-and-parent side, payment visibility for the organization side, sponsorship integrations, and the investor-facing financial model behind the pricing. Both sides of every transaction got a designed experience, not just a processor bolt-on.

WHAT HAPPENED

$250K+ in transactions processed within 90 days of launch. That number is the payments UX doing its job: organizations trusted the rails enough to move their registration revenue onto a brand-new platform, run by clubs, paid by parents, in three regions.

Launching free would have been easier. It also would have proven nothing. $250K in 90 days is the design working.

Registration summary and payment: the event, ten athletes, registration fee, fees and tax, total, refund window, and a Pay button
CHECKOUT — ONE SUMMARY, EVERY ATHLETE, EVERY FEE, ONE TAP TO PAY
[ DEEP DIVE 03 — ORGANIZATION & LEAGUE ANALYTICS ]

Insight for people who don't read dashboards.

THE PROBLEM

Club operators are coaches, parents and volunteers — not analysts. A platform that quietly accumulates registration, league and payment data gives them nothing unless it can answer their actual questions: how is my league doing, who's coming back, where's the money.

THE OPTIONS

The default is the everything-dashboard: charts and tables for every metric, configurable by nobody who'll ever configure it. The bet I preferred: fewer, opinionated views — AI turning platform data into personalized insights per organization, at the risk of hiding raw data a power user might want.

THE CALL & THE COST

Opinionated insights won. An operator running a league between a day job and a family doesn't want a BI tool; they want to be told what matters and what to do about it. The tradeoff is real — some flexibility sacrificed — but the design principle held: serve the operator you have, not the analyst you imagine.

SHIPPED

Organization analytics dashboards and league analytics that turn platform data into personalized insight — registration, engagement and revenue readable at a glance by a non-technical operator, on the same design system as the athlete side.

[ THE ORGANIZER SIDE ]
Session draw for Mens Doubles: pools of five, courts in use, 35 checked in, and Pools A to F with their teams
GAME DAY — THE SESSION DRAW: POOLS, COURTS AND CHECK-INS
Promotion and relegation step: choose how many teams move between pools after each session
LEAGUE SETUP — PROMOTION AND RELEGATION, IN PLAIN LANGUAGE
Advanced date settings sheet: start and end dates, days of the week, weekly repeat
SCHEDULING — RECURRING SESSIONS WITHOUT A SPREADSHEET
Match Score entry: two team scores, add set, submit, with a numeric keypad
SCOREKEEPING — LIVE RESULTS FROM THE COURT
[ DEEP DIVE 04 — ATHLETE PROFILES & SAFEGUARDED MESSAGING ]

Designing communication when some users are kids.

THE PROBLEM

A sports community needs messaging and visible athlete profiles — and a youth-sport user base makes both a safeguarding problem before they're a growth feature. This is the design decision most social products get to ignore and a youth-sport platform absolutely cannot.

THE OPTIONS

Open DMs are the growth-friendly default — every social loop gets faster when anyone can message anyone. The safeguarding alternative deliberately adds friction: structured, purpose-bound communication designed around the most vulnerable user rather than the median one.

THE CALL & THE COST

Safeguarding won, and it wasn't close. Messaging is designed with guardrails as deliberate product decisions — communication scoped to the sport contexts it belongs in, not an open social graph. The cost is slower viral growth; the return is a platform parents can trust, which in youth sport is the growth strategy.

SHIPPED

Scouting-oriented athlete profiles — built to get players seen for the right reasons, by the right audience — alongside messaging with safeguarding designed in from the first wireframe. Trust here is what lets the other three deep dives exist at all: nobody moves their club, their kids and their money onto a platform they don't trust.

Design for the most vulnerable user in the room and every other decision gets clearer.

[ ASSET: ms-profile — 4:5 ]
ATHLETE PROFILE — SCOUTING-ORIENTED, BUILT TO GET PLAYERS SEEN
[ ASSET: ms-messaging — 4:5 ]
MESSAGING — GUARDRAILS AS VISIBLE, DELIBERATE DESIGN DECISIONS
[ MESSAGING, DESIGNED FOR TEAMS ]
Messages inbox with pinned team chats, unread counts and All, Unread, Teams, Announcements filters
INBOX — TEAMS AND ANNOUNCEMENTS PINNED ON TOP
The same inbox in dark mode
INBOX — DARK MODE, SAME HIERARCHY
A group thread for Thursday Night Doubles with a pinned net schedule and read receipts
THREADS — PINNED LOGISTICS, READ RECEIPTS
A team thread with a shared PDF, a practice event card with Going and Cant go, a fee to pay, and a gear listing
RICH CONTENT — EVENTS, FEES AND FILES INSIDE THE CHAT
[ THE DESIGN SYSTEM — A STRATEGIC BET ]

One system, every sport.

Registration status badge component: Closing soon, Near capacity, Waitlist open, Waitlist full, Registration closed, Registration open
ONE COMPONENT, SIX REGISTRATION STATES

The design system is mobile-first and token-driven — color, type and spacing as tokens, components built once and reused across the athlete app, the organization surfaces and the web platform.

The strategic part: it's architected to flex across sports and organization types. Volleyball is a theme, not a hard-coding. When Midseason expands to the next sport, the product doesn't get redesigned — it gets re-themed, and the multi-sport roadmap becomes a configuration problem instead of a rebuild. That's the same bet this system-of-tokens philosophy makes everywhere: spend once, flex forever.

[ ASSET: ms-system-foundations — 4:3 ]
FOUNDATIONS — COLOR, TYPE AND SPACING TOKENS
[ ASSET: ms-system-components — 4:3 ]
CORE COMPONENTS — BUILT ONCE, USED ON EVERY SURFACE
[ ASSET: ms-system-theming — 16:9 ]
THE BET, VISUALIZED — THE SAME COMPONENT THEMED FOR DIFFERENT SPORTS AND ORGANIZATION TYPES
[ HOW IT WAS BUILT — THE AI-NATIVE WORKFLOW ]

Method, not buzzword.

Midseason ships at big-team speed with a lean team because the workflow is AI-native, not AI-flavored: a Figma-to-code pipeline and AI-assisted design and build process that compresses the distance between a concept and a validated, shippable screen. The loop looks like this:

Design

High-fidelity screens and flows in Figma, on the token system.

Validate

Pressure-test against both audiences before a line is written.

Generate

The Figma-to-code pipeline turns validated design into working React Native.

Refine

AI-assisted iteration on the real build — the craft pass happens in code.

Ship

To the live product, then the loop restarts on what the data says.

The payoff isn't that any single step is novel — it's the cycle time. Concept to validated build in days keeps a lean team's roadmap honest: ideas get tested against the product, not defended in a backlog.

[ BY THE NUMBERS ]
Midseason league leaderboard screen
$250,000+PROCESSED WITHIN 90 DAYS OF LAUNCH
11,696MATCHES GENERATED
3,000+USERS AND COUNTING
iOS · Android · WebLIVE ON MOBILE + WEB
[ SEE IT LIVE ]VISIT MIDSEASON
[ REFLECTION — WHAT I'D TELL MYSELF IN APRIL 2024 ]

01 Two-sided means everything ships twice

Every feature has an athlete version and an organization version, and the second one is never free. Building this as a founder taught me a scope discipline no team role ever did: the smallest thing that serves both sides, or it doesn't ship.

02 Payments-first was the right hard call

It was the heaviest lift in the product and I'd make the same call again faster. Usage can flatter you; revenue can't. The $250K wasn't just income — it was the only fully honest signal the marketplace thesis worked.

03 Constraints were the best design tool

Safeguarding, compliance, cold-start, one pair of hands — every constraint I resented made the product more focused. Designing for the most vulnerable user and the busiest operator answered questions taste alone couldn't.

04 A marketplace is operations, not just product

The screens are half the job. Onboarding organizations, supporting parents, moving real money — I underestimated how much of a marketplace lives outside the app, and I'd staff my own attention differently from day one knowing it.

Next: multi-sport expansion — on the architecture that was built for it from day one.

[ FROM A MIDSEASON CUSTOMER ]
“Nathan has shown a great amount of care when it comes to our experience using Midseason. He quickly developed a deep understanding of how we operate as a league and business. He has done an incredible job transitioning us from our old paper ways to the impressive product he has created.”
Shane HydeCustomer of MidseasonOwner, Oceanside Outdoor Sport
[ FROM THE PLAYERS ]
“I registered 2 spring doubles teams today using Midseason. Super easy process! Love the app!”
JenParent · registered two youth teams
Replied to your story

The app is mint 👌🏼! This season is exponentially better because of it! Great work!

MIDSEASON USER · VIA INSTAGRAM DM

Built to grow with every sport it touches.

Midseason is live, processing real money, and just getting started. If you want the product, it's a tap away — if you want the person who built it, keep scrolling.

VISIT MIDSEASON MORE WORK

Let’s build
something together.

EMAIL ME
[ GET IN TOUCH ]

Want this level of thinking on your product? Reach out and talk it through.