Joby's First NYC Air Taxi Flights Aren't About Air Taxis — They're a Distribution Lesson

On April 27, Joby Aviation completed the first point-to-point electric air taxi flight in NYC history — JFK to a West 30th Street heliport, 7 minutes versus 60–120 minutes by car. The week-long demo runs along existing helicopter routes operated by Blade, which Joby acquired in April 2025.

The aircraft are real. The flights are real. The 7-minute number is real.

And buried inside the press coverage is the actual interesting story for solo operators: Joby didn't build a new transit network. They bought a tiny existing one (Blade) and rode along on its FAA approvals, terminal leases, helipad operating agreements, and customer relationships.

That's the same distribution playbook every successful indie app uses to get into a new platform, and it's the one most solo operators consistently fail to copy.

What Joby actually did, structurally

They didn't apply to NYC for new helipad rights.

They didn't build out terminal infrastructure.

They didn't negotiate landing rights at JFK.

They didn't build a customer pipeline.

They bought Blade — a 10-year-old helicopter charter business that already had all of those things — and then operated their next-generation aircraft inside Blade's existing operational envelope. The "first NYC eVTOL flight" headline obscures that the route, the terminal, and the operating playbook were all 10+ years old. Joby brought the airframe. Blade brought the distribution.

The Blade acquisition closed in April 2025 for an undisclosed amount, reportedly under $200M. Joby's market cap is in the billions. The acquisition was a rounding error on the balance sheet and a load-bearing piece of the strategy.

The pattern, named

"Ride along on someone else's logistics."

This is the same shape as Stripe Atlas riding along on Stripe's existing payment compliance infrastructure. As Notion's API riding along on the existing user base of every Notion power user. As every "we integrate with [bigger product]" indie SaaS that gets traction.

The bigger company brings the boring, expensive, hard-won regulatory or customer or operational footprint. The smaller player brings the differentiated product. Both win.

The pattern is older than software and works every time. Banks ride along on government-issued currency. Restaurants ride along on city food-permit infrastructure. Airbnb rode along on residential housing stock. Every successful new product layer rides along on an older, lower-margin, harder-to-build infrastructure layer.

Why solo operators consistently fail to use it

Most indie devs default to "build my own everything" because the alternative — "build inside someone else's surface" — feels like surrendering control.

It's not.

The right framing is "rent the infrastructure that's expensive to build and that customers already trust, while owning the product layer that's actually your differentiation."

Joby's aircraft is theirs. Blade's helipad lease is rented. Notion's data model is rented. The productized workflow you build on top of Notion is yours. The mistake is conflating "owns" with "controls" — you can build a great product that depends on rented infrastructure as long as the rental terms are stable enough and the differentiation is yours.

The specific failure mode for indie devs: spending three months building auth, payments, email delivery, search infrastructure, mobile push notifications. All of these are expensive infrastructure problems with strong existing solutions. Building them yourself is a way of losing three months that you could have spent on the actual differentiated product.

The 30-minute exercise for your product this week

List the three most expensive things to bootstrap from scratch for your category.

Auth. Payments. Distribution. Regulatory compliance. Customer trust. Integration with X-system. Whatever the analogous "boring expensive infrastructure" looks like for your domain.

For each, identify the existing player whose 10-year head start you can rent. Via API, via integration partnership, via small acquisition, via "we sit inside [bigger product]" positioning.

Then ask: which of these three could I be riding on tomorrow that I'm currently building from scratch?

Most solo devs find at least one. Some find all three.

The output is a small document with three rows: "Thing I'm building from scratch," "Bigger player whose infrastructure I could rent," "Migration cost." If the migration cost is bounded and the rental terms are stable, you have your weekend project.

The specific examples that map this pattern in 2026

A Slack app rides on Slack's enterprise relationships, SSO, and compliance. You keep the product. Slack does the boring work. You don't need to negotiate with IT departments, pass SOC 2 audits, or run your own SSO infrastructure. Slack already did it.

A Shopify app rides on Shopify's merchant base, Shopify Pay, and tax handling. Shopify negotiated the relationships with payment processors. Shopify ran the chargeback infrastructure. Shopify handles sales tax across 50 states. Your app sits in the middle and does the differentiated work.

A Notion plugin rides on Notion's content and user base. Notion brought 30M users. You bring the workflow extension. Distribution problem solved.

A Cursor extension rides on Cursor's distribution and editor infrastructure. Cursor solved "developers install our IDE." You solve the workflow problem inside it.

A Granola or Fireflies integration rides on the existing meeting-recording infrastructure those tools built. You don't have to integrate with Zoom's notoriously fiddly API yourself — Granola already did, and the recording is sitting in your tool's database the moment the meeting ends.

The pattern is everywhere. The discipline is naming it explicitly and choosing the bigger player whose footprint you actually want to inherit.

The honest counter-take

Riding along on someone else's logistics has a cost.

They can change the rules. They can take their share. They can deprecate your access. They can compete with you directly — which is exactly what Apple did to Tile, Sherlock-style, repeatedly. What Notion did to several plugins by absorbing the functionality into the core product. What Slack has done to several Slack-app-shaped products that got popular enough to threaten core revenue.

Don't read this as "always build inside someone else's surface."

Read it as "be conscious about which infrastructure you're choosing to rebuild from scratch and why, because the unconscious default is to build everything yourself, and that's almost never the right call for a one-person shop."

The specific risk hierarchy: rent the infrastructure where the bigger player's incentives are aligned with yours (Stripe wants you to process more payments — aligned). Be cautious where the incentives are partially aligned (Notion wants more users, but not specifically the workflow your plugin enables — partially aligned). Be very careful where the incentives are misaligned (Apple wants users on Apple-owned products, your third-party integration is competing for that slot — misaligned).

The check-yourself questions

Three questions to ask before deciding to rent infrastructure vs. build it yourself.

Is the rental cost stable and bounded? Stripe's pricing is well-known and changes rarely. Apple's App Store rules change unilaterally and often. Pick the rentals where the cost is predictable.

Are my interests aligned with the rentier's? If they want me to succeed because my success makes them more money, I'm in the right place. If they're indifferent or actively competitive, I'm exposed.

What's the swap-out cost if the rental terms change? If I can swap from Stripe to another payment processor in two weekends, the dependency is bounded. If I can't swap from Apple's App Store at all because that's where my users are, the dependency is unbounded and I should price it accordingly.

The Joby/Blade case is a good example of all three: Blade's helipad rights are stable, Blade's incentive (Joby keeps them in the air taxi business) is aligned, and the swap-out cost is high enough that Joby didn't even consider it — they just bought the company.

The take-home

Stop building auth from scratch. Stop running your own email infrastructure. Stop doing payment compliance yourself.

Pick the bigger player whose boring expensive infrastructure you actually want to inherit. Build your differentiated product on top of it. Pay the rental cost in fees or revenue share. Pocket the years of saved effort.

The pattern is everywhere from Joby to Notion to your unbuilt SaaS. The difference between the operators who use it and the operators who don't is a quarterly habit of asking: which of the things I'm currently building from scratch could I be renting from someone whose 10-year head start is exactly what I need?

Make that audit a quarterly habit. Spend the saved time on the differentiated product. Watch the math work.