I shipped a live integration sandbox in 90 minutes instead of taking the partnership call. It changed the conversation.

#partnership #api #buildinpublic #startup

A CEO sent me a DM yesterday afternoon. Aviation learning platform. Wanted to talk about a partnership with my smaller aviation API (Rotatepilot — question banks, METAR decoder, airport lookups). Real founder, real platform, real intent.

I had two options:

Reply with my usual qualifying questions, schedule a 30 min call later in the week, do the meeting, agree on what to build, build it, send it for review, iterate.
Build it now and send the link.

I went with option 2. 90 minutes of work. The conversation flipped from "show me what this looks like" to "what's the commercial shape."

Here's how, and why I'll do this for every inbound partnership conversation from now on.

The DM that triggered this

From the CEO of SkyX International (aviation learning platform, Public Beta on Product Hunt):

"We are interested in your RotatePilot website, since it includes crucial tools that we think can help us develop a large selection of aviation tools. Your data bank (ATPL/PPL questions, API…) also fascinates us. We think a partnership between both platforms could benefit you and us. It could either be an API, embed, or any kind of licensing partnership. We are open and flexible. Before engaging into anything, I invite you to take a look at our platform, test out the features as you want, and feel free to give your suggestions."

Translation: "I want to integrate your API but I don't know what your API looks like yet, and you don't know what we'd actually consume."

The default founder-to-founder script here is:

"Great, here's a Calendly link, let's do 30 min."
On the call, you screen-share your API docs, they ask questions, you both end with "send me a sample integration."
You build the sample. You send it. They review. Maybe respond in a week. Maybe not.

I've done that loop probably 20 times in the last year. The conversion rate is awful. Most never come back. The ones that do, come back 2-3 weeks later by which time the energy has dropped.

What I did instead

Spent 5 minutes browsing their platform (onboarding.skyxintl.me). Took specific notes:

They list "structured learning pathways + spaced repetition" but no question bank size visible.
They list "METAR decoder" as a feature.
I didn't see a language switcher on the landing — looked English-only.
They're pre-launch (countdown timer at 00:00:00:00).

These are gaps where my API fills in. Not theoretical fit, actual fit, with specifics.

Then I built rotatepilot-skyx-sandbox — a single HTML file that hits four of my public REST endpoints live in the browser and renders the responses in a learning-platform style UI:

Question bank — GET /api/v1/question?subject=meteorology&count=2 — returns FAA-labeled MCQs with explanations.
METAR decoder — GET /api/v1/metar?icao=KJFK — returns decoded flight category, wind, visibility, cloud layers.
Airport lookup — GET /api/v1/airport/KSFO — returns name, ICAO, runways, training-airport flag.
Quiz of the day — GET /api/v1/quiz-of-day — returns one shared question for daily-engagement features.

The whole thing is one file. No build step. No backend. Calls go straight from the browser to my edge-served endpoints (CORS enabled, no auth tier needed at this volume). Open DevTools and you see the real requests.

Stack: ~300 lines of HTML/CSS/vanilla JS. Pushed to GitHub. Enabled GitHub Pages with gh api -X POST repos/.../pages -f "source[branch]=master". Live in 90 seconds.

Live demo — paste any ICAO, pick any subject, see real responses.

What I sent back to the CEO

Three messages, in order:

Qualifying questions — ranked top-2 pieces, format (API vs embed vs license), 6-month volume guess, commercial direction. Plus a 30-min call offer for later in the week if he preferred async.
Substantive feedback on their platform — what looked strong, three peer-pushback notes (the countdown timer reads 00:00:00:00, no product screenshot above the fold, Product Hunt badge buried in footer), and a concrete integration proposal direction.
The sandbox link — "Instead of waiting on the call to show what the JSON contract looks like, I went ahead and built the sandbox. It's a single static page that hits 4 endpoints live. Take a look when you have 5 min — would help us skip a lot of 'what does it look like' on the call and jump straight to commercial shape."

Total time: roughly 90 minutes of real work, including writing the messages and verifying the live endpoints.

Why this changes the conversation

The default partnership conversation has three rounds of friction:

Discovery — what do you have, what do we want.
Mapping — does the shape match, what would integration cost.
Commercial — how do we make money on this.

A sandbox collapses rounds 1 and 2 into a single artifact the other side can open and inspect on their own time. They don't need to wait for a meeting to understand the shape of what you have. You don't need to spend the meeting explaining endpoints. The meeting (if it happens) is just round 3, which is the only round that actually moves the deal.

It also forces you to do the work before you've gotten a "yes," which is exactly the work that makes the partnership real. Half the partnerships I've talked about never happened because the work to make them concrete never got done. Doing it on day zero filters out partners who weren't going to follow through anyway.

The general pattern

You don't need someone's permission to demonstrate value. The thing that's expensive isn't the meeting, it's the uncertainty between "we should partner" and "let's actually integrate." If you can collapse the uncertainty in 90 minutes of static-file work, do it.

This works for:

API-led partnerships — show your endpoints rendering in their kind of UI.
Embed/widget integrations — drop an iframe in a styled wrapper that resembles their site.
Data licensing — a quick HTML view of a sample of your dataset with proposed fields.
Cold outbound to a specific company — same idea, build a custom demo and lead with it.

It does not work for vague "let's chat" inbounds where the asker doesn't know what they want. That's a different problem (qualifying, not delivering).

The tools, for replicability

One HTML file. No framework.
git init && git add . && git commit && gh repo create --public --push
gh api -X POST "repos/USER/REPO/pages" -f "source[branch]=master" -f "source[path]=/"
Live URL: https://USER.github.io/REPO/

Source for the sandbox I built: github.com/Perufitlife/rotatepilot-skyx-sandbox.

What I'm doing with this pattern next: applying it to every cold outbound I send for my BaaS security auditors. Instead of "want a free scan?" → "here's a sandbox of what a scan of your project might find, formatted as a real audit report." Same effort, 10x higher conversion.

If you've shipped a sandbox-before-meeting and it worked (or didn't), I'd love to hear what you learned. Reply or DM.

I'm building a portfolio of single-purpose dev tools at github.com/Perufitlife. Latest: five open-source BaaS security auditors (Supabase, Firebase, PocketBase, Appwrite, Nhost) shipped this week.