The constraint: speed without sacrificing fit
We promised the community we would deliver a viable mission-matching loop for 107.flights by Friday. That meant sourcing credentialed pilots, structuring briefs from customers who needed work done, and building enough trust that both sides would respond inside a weekend. The constraint forced us to design for signal over scale—no generic directories, just a pipeline where every match felt white-glove.
Step 1 — Instrument the pilot graph
The core of the product is a searchable pool of Part 107 certified pilots. We scraped, enriched, and verified data from FAA registries, drone community forums, and previous launch waitlists. Each record feeds a simple graph:
- Capabilities: certifications, aircraft, sensors, licensed airspace, and insurance coverage.
- Availability: preferred regions, lead time, and mission types they will not accept.
- Proof: links to reels, sample deliverables, or audits we could send in a single click.
We stored the dataset in a lightweight Postgres instance with vector columns for mission similarity scoring. A background job backfills structured tags so new pilots can drop into the loop without manual reviews.
Step 2 — Translate buyer intent into structured briefs
We interviewed six potential buyers ranging from agriculture to real estate. The friction was consistent: most had tried broad job boards and been flooded with unqualified responses. Our answer was a mission brief wizard that forced clarity:
- Industry-specific prompts with examples (“Show me the crop stress map you expect” for agriculture).
- Upfront budget bands tied to mission complexity.
- Safety and compliance checklist that automatically filters pilots.
The output is a JSON spec we use everywhere else—matching, outreach, and CRM. Every brief is reviewable by an operator before it exits draft, so no low-signal requests hit the network.
Step 3 — Spin up the matching heuristic
With structured data on both sides we built a scoring function that rewarded credential overlap, regional proximity, and past mission similarity. We layered in a negative score for pilots who had declined similar work recently to avoid spamming them. The stack looks like this:
score = (capability_overlap * 0.45)
+ (mission_similarity * 0.30)
+ (geo proximity * 0.15)
+ (response_velocity * 0.10)
- (recent_declines * 0.25)
Scores above 0.68 triggered an automatic outreach sequence. Anything below triggered a manual review in the operator dashboard so we could tweak edge cases before the system learned more.
Step 4 — Outreach automations that feel handcrafted
Qualifying pilots is half the job; getting them to reply is the other half. We used a duo of automations:
- Pilot sequences: transactional emails with brief highlights, a one-click accept/decline CTA, and a calendar hold if they tapped accept.
- Buyer updates: after each response we synced the status to Airtable and triggered a Slack webhook so mission owners saw progress in real time.
The tone was intentionally operational, not marketing speak. Every message included mission-specific details pulled from the brief so it felt bespoke.
What shipped by day three
By Friday we had 34 verified pilots ready to take missions, eight live briefs, and three matches heading into onboarding calls. The operators could:
- Approve or reject briefs from a queue.
- Trigger outbound sequences and monitor responses.
- Share pilot reels with buyers in a single click.
We shipped with gaps: payout flows are still manual and the dashboard is a little too operator-centric. But the matching loop works, and the backlog of invites tells us where to focus next.
What’s next
Over the next sprint we’re layering in availability calendars, automated insurance verification, and a shareable mission summary buyers can send to internal stakeholders. If you’re building in marketplaces, check out our notes on designing trust for privacy-first communities—the same trust mechanics showed up here.