The 90/10 bet.

Every platform company draws the same diagram: its own logo in the middle, its products radiating outward, the customer's business orbiting the center. It's a comforting picture and it is not the reality. A real seller runs their business across a constellation of tools — accounting software, e-commerce platforms, marketing suites, help desks, booking systems — and Square is one node in it. As Square moved upmarket, that constellation got denser: bigger sellers have more specialized needs, and more of their operations live in software Square doesn't make.

The strategic question I kept putting in front of the organization: if the goal is to be the command center of a seller's business, you cannot get there by building every spoke yourself. The math forbids it.

The sharpest version of the argument fits in one question: what if we could give third-party developers a way to extend our first-party offerings without having to build 90% of similar features just to have that 10% of new niche functionality? A booking product with document management. An orders dashboard that knows about your shipping provider. Today a developer who wants to add that 10% must rebuild the other 90% — their own app, their own auth, their own UI — and the seller pays for it in tab-switching and re-entered data. Let them build only the differentiated slice, rendered inside Square's own surfaces, and everyone's economics change: the developer's cost collapses, the seller's workflow unifies, and Square's platform becomes more valuable with every add-on it hosts.

That was the bet. I wrote it up, argued it, and spent four months building organizational support before a line of product code — the funding motion was itself a project. We validated demand along the way: the team's UX researcher surveyed sellers at scale, and the interest was overwhelming — most respondents already ran multiple third-party tools alongside Square, and they wanted them in one place. (The survey internals are Block's, so they stay internal; the program was funded on that evidence.)

Extensibility programs die two ways: they're so open they degrade the host product, or so constrained nobody builds on them. We wrote the guardrails first:

• Meet sellers where they are. Add-ons appear inside the workflows sellers already run — the appointment panel, the order detail, the dashboard home — not in a separate app they must remember to open.
• The seller manages a business, not a toolbox. Enabling, permissioning, and paying for an add-on had to feel like Square, end to end.
• Shorten time-to-value — for the developer too. Industry-standard tooling, a paved path to build, and distribution through rails that already existed.
• Keep the remarkability bar high. Third-party did not get to mean second-rate. Add-ons rendered with Square's own design-system components, so a Dropbox or DocuSign panel was visually indistinguishable from Square's own UI.

That last principle had teeth. It ruled out the cheap answer — and set up the defining engineering fight of the program.

The fast way to put third-party UI inside your product is an iframe. It's also the way to get a product that feels like a mall kiosk: foreign styling, broken resize behavior, UI that can't escape its box, and a security posture you're forever litigating. Product and engineering leaned toward iframes because the alternative looked unaffordable — the initial estimate for a native rendering approach was two years. Alex, whose design bar the whole program rested on, refused to accept the iframe experience, and pushed hard for a better answer. My job was to hold the funding steady while the disagreement resolved on evidence instead of fatigue.

The answer came fast once the right expertise joined: a front-end specialist built a proof of concept in two weeks on Remote DOM — the open-source approach Shopify published for exactly this problem — and the two-year estimate collapsed to about two months. Add-on code executes in a sandboxed context with no direct access to the host page; it describes its UI, and a serialized view tree crosses the boundary to be rendered by Square's own components. Security stays tight, and the seller sees native Square UX.

Two lessons I've carried since. First, when design and engineering disagree about what's possible, the cheapest move a product leader can make is funding a short, real spike — two weeks of proof beat months of meeting-room estimation. Second, the pattern won on the merits industry-wide: Remote DOM is public open source and powers Shopify's extensibility surfaces today. We weren't clever in isolation; we were early on a pattern the industry has since converged on.

The screens tell the story faster than I can. A digital-goods seller edits an item in Square, and SendOwl — one of our alpha partners — is simply there, inside the item editor, managing delivery of the files the item sells:

Discovery worked the same way — contextual, not catalog-first. Sellers found add-ons where the need surfaced: a banner inside the customer directory, an in-product prompt beside the workflow the add-on extends, backed by App Marketplace search that could filter by which Square surface an add-on appears on:

And because this was a payments company's dashboard, the unglamorous half got built too: enablement flows that told a seller exactly which surfaces an add-on would appear on; role-based permissions so a front-of-house manager could see signed documents but not create shipping labels; loading and failure states for when a partner's servers went down; and support routing that sent sellers to the developer's support channels, not Square's call centers — third-party functionality that failed like a professional product, not like a widget.

Distribution cost the program almost nothing — because the platform had already paid for it. A year earlier we had rebuilt app submission as a self-serve pipeline; Add-ons extended that same listing flow with an add-ons section, so a developer packaged their add-on, attached it to their marketplace listing, and only the content needed fresh review. Developers built with industry-standard tools — Node.js, a templating layer that mapped to Square's design-system components, locale files for international surfaces — and submitted builds through a CLI that triggered automated and manual QA and security checks, on a versioned release process.

This is the compounding I care about most in platform work: bet #1's infrastructure became bet #2's distribution, unchanged. When the boring layers are built as products, every later bet gets cheaper.

Add-ons ran a real external alpha: developer preview documentation, a local development server, component design guidelines, a Figma toolkit, and working add-ons from external partners — SendOwl's digital delivery and appfoundation.io's appointment tooling among them, rendering natively inside Square surfaces for real workflows. The thesis held: third-party developers could ship native-feeling Square functionality without Square building it, and without the seller ever leaving their dashboard.

Then 2024 reorganized the company's priorities, and the platform's frontend resources moved to other bets. Add-ons was paused before general availability. I won't dress that up: I conceived it, fought for its funding, and believed in it — and the company made a portfolio decision that went the other way. That's what a portfolio is. My honest scorecard: the demand evidence was real, the architecture was right, the alpha proved the experience — and I'd fought the program's cause harder and earlier in the annual planning cycles, where resource contests are actually decided.

The epitaph matters less than the vindication. The extensibility thesis Add-ons bet on is now the industry's default direction — Shopify's Remote DOM powers production extensibility at scale, and every platform racing to be legible to AI agents is rediscovering the same truth: the platforms that win are the ones third parties can extend without permission meetings. Add-ons are dead; long live add-ons. I wrote about where that thesis goes next in Don't ship the org chart, and about the decade-long platform arc it belongs to in How a platform becomes structural.

• Secure multi-year funding commitments for platform bets. Add-ons was funded annually, which meant re-arguing an infrastructure thesis against feature roadmaps every planning cycle. Platform extensibility pays back on a longer clock than a fiscal year, and the funding structure should match the payback curve.
• Get paying partners into the alpha. Our alpha proved the experience worked; it didn't prove anyone would pay for it. A revenue signal — even a small one — is the strongest armor a program has when resources get contested.
• Publish the pattern earlier. Shopify open-sourced Remote DOM and owns the narrative for an approach we were building in parallel. Platforms should publish their architecture bets — it compounds credibility with exactly the developers you're courting, and it makes the work legible outside the building. This page is me applying that lesson late.