Before You Build the Platform: The First Useful Thing AI Should Do

Early-stage teams building a matching network reach for the platform first — the dashboards, the accounts, the directory. The leverage is somewhere smaller and sooner: the one repetitive judgment call you're already making by hand.

Eli Wood headshot

Eli Wood

June 24, 2026 4 min read
Two groups of people separated by a gap, connected by a single sturdy plank in the foreground while a large empty scaffold looms unbuilt behind

The platform is a trap when you're early

If you're connecting two sides of a market — people who need something and organizations that provide it — the instinct is to build the platform. Profiles, listings, a search experience, accounts, dashboards, notifications. It feels like the product. It is mostly scaffolding. You can spend six months building the container before you've proven the one thing the whole network depends on: that you can reliably put the right two parties in front of each other.

Early on, you don't have a platform problem. You have a matching problem, and right now a human is solving it by hand — reading intake forms, remembering which organization takes which kind of case, emailing introductions, following up. That manual matching is slow, it doesn't scale past the founder's attention, and it's the actual value of the network. That is where applied AI earns its first dollar, long before any platform does.

Find the judgment that's expensive and repetitive

The right place to point AI first is the work that is simultaneously expensive (it takes real human attention and good judgment) and repetitive (you do a version of it every single day). That intersection is where a model creates leverage without much risk.

For a young matching network, that's almost always the match itself. Someone arrives with a messy, half-formed description of what they need. A human reads it, infers the real need underneath the words, and recalls which of the providers in the network is the right fit — not just eligible, but actually a good match for this person right now. That inference is the expensive part, and you're doing it over and over. A model can do the first pass: read the intake, extract the real need, and propose the top few matches with a sentence of reasoning for each.

Notice what that is and isn't. It isn't an autonomous matchmaker that emails strangers on your behalf. It's a judgment engine that prepares the human — turns thirty minutes of reading and recall into a ranked shortlist you can confirm in two. You stay in the loop precisely because the early matches are the ones that build or break the network's reputation. Get a few badly wrong and both sides stop trusting you. The cost of being wrong is high, so the human blesses every match while the volume is still small enough to do that.

Separate the rules from the judgment from day one

Even the first useful build benefits from one structural discipline: keep the deterministic checks out of the model. Whether a provider serves a given region, has open capacity, or works with a given category — those are facts, not judgments. Encode them as filters. Let the model reason only over what's genuinely fuzzy: what this person actually needs and which of the qualified providers fits best.

That split buys you two things cheaply. The rules half is reliable and explainable — you can always say exactly why a provider was or wasn't in the running. The judgment half stays small, focused, and inspectable, because it isn't also trying to remember business logic. When you do eventually build the platform, this boundary is already drawn, and you scale a system you understand instead of a black box you've grown afraid to touch.

A two-day start

You don't need a platform to test this. Take the last fifty matches you made by hand. Write down the deterministic filters — region, capacity, category — as plain rules. Then stand up a thin judgment step that reads an intake, applies the filters, and returns a ranked shortlist with one line of reasoning per match. Run it against those fifty real cases and compare its shortlist to what you actually did.

In two days you'll learn whether the model can carry the first-pass match, and exactly where it can't — the cases where your human judgment caught something it missed. That gap is the most valuable thing you can know as an early team. It tells you what to automate now, what to keep a human on, and what the platform actually needs to support when you finally build it. Ship the smallest thing that does the real work, keep yourself in the loop where being wrong is costly, and let the platform earn its way into existence.

Black Flag Design builds applied-AI products for early teams who'd rather ship the useful core than the scaffolding around it. If you know your one expensive, repetitive judgment, spend two days with us — we call it a Foundation Sprint.

About the author

Eli Wood headshot
Eli Wood

CEO, Black Flag Design

Eli Wood leads Black Flag Design, a creative technology company focused on shipping ambitious digital products, AI systems, and design-forward software with a direct point of view on how technology changes work.

Related stories

More from the journal

Pen-and-ink sketch of a small clockwork robot working at a tool-covered workbench late at night while a human sleeps peacefully on a couch in the background, a wall clock reading 2:00 above
ai April 24, 2026 13 min read

The Agent Stays Up Late, Not Me

Every senior engineer knows the right way to set up a codebase. None of them do it. Here’s the four-stage framework we use — The Ratchet — to take a vibe-coded project all the way to a thing you’d trust in production, and the punchline about why this only just became worth doing.

Most teams have always known they should be running tests, type-checking, security audits, accessibility checks, dead-code analysis, prose linting, and a coverage floor. Most teams run two of those. Here’s why that math has finally inverted, and the four-stage framework we use to ratchet a vibe-coded project to a hardened one.

Keith Pattison

Keith Pattison

Founder, Black Flag Design

Read
Black Flag Journal
claude code April 20, 2026 5 min read

What a Year of Claude Code Trails Tells You About Your Team

Claude Code leaves evidence — sessions, commits, PRs, review notes. Read it like a logbook and you'll find what devs actually need to know before they go deeper.

After a year of shipping with Claude Code across real client work, the signal isn't in any single session — it's in the trails. Here's what those trails told us about where Claude Code shines, where it drifts, and the habits devs should build before they lean in harder.

Eli Wood headshot

Eli Wood

CEO, Black Flag Design

Read
Black Flag Journal
playbook April 20, 2026 6 min read

The Black Flag Playbook: Six Principles for Shipping with AI

Battle-tested principles for teams building real software with AI-generated code. Human judgment, tight scope, and weekly evidence — the disciplines that keep AI-built systems reliable.

The six rules we use to ship production software with AI. Small scope, weekly demos, human-led oversight, and continuous improvement — drawn from six months of real client engagements.

Keith Pattison

Keith Pattison

Founder, Black Flag Design

Read