From 90 days to 20.

In 2022, getting a third-party app listed on Square's App Marketplace took a typical partner about 90 days. Not because anyone was lazy — because the process was artisanal. Partners filled out a sprawling multi-tab spreadsheet of listing content; internal teams chased errors and omissions by email; every submission was a bespoke conversation between the developer, partnerships, marketing, and content specialists. There was no validation, no single source of truth, and no way for a partner to know where they stood.

The dangerous part of a process like this is that it looks like rigor. Every manual step had a reason. But the platform's growth loop — more developers building apps, more apps in the marketplace, more sellers running on partner software — was being throttled at its narrowest point, and the narrowest point was us.

The decision I owned was to treat the queue as a product problem and fund a real team against it: one PM, one product designer, an engineering manager and five engineers, a product marketer, and a content specialist. Six months. And one scope decision that shaped everything downstream — the target customer wasn't our existing managed partners. It was any developer, including the ones who would never get a partnerships meeting. If the system only worked with a human escort, it wasn't the system I wanted.

Here's the context that makes this project interesting beyond Square. True self-serve third-party onboarding — build, submit, and launch without talking to a human — is rare in B2B software, and vanishingly rare in payments. The dominant pattern in the industry is a “become a partner” form that routes to a business-development queue. That's not because companies don't want self-serve; it's because a self-serve gate is an enormous amount of product. You are signing up to build public documentation, machine-enforceable requirements, automated and human review, legal agreements that work at click-through, security and compliance checks, transactional comms, and the internal tooling to operate all of it — where a partnerships funnel needs only a form and a calendar.

The scale of that machinery is easiest to see at Apple, which runs the world's reference implementation: in 2025 its App Review operation evaluated over 9.1 million submissions and rejected over 2 million of them, per Apple's own transparency report — hundreds of expert reviewers working behind what developers experience as a simple submit button. In Square's own space, the pattern at the time we built — and largely still today — was gated: Toast's integration program runs through a partnership application, business-development vetting, a signed partner agreement, and staged certification before an app is listed; Clover requires identity-verified production developer accounts and multi-stage functional, legal, and listing review; and Lightspeed's marketplace starts with a partner application to its partnerships team. Even Shopify — the strongest self-serve developer experience in commerce, and one we studied openly — gates every launch behind its app review team. Outside commerce, Salesforce's AppExchange security review alone is quoted at four to eight weeks.

None of that is a criticism — those companies are being responsible with their merchants' data and their platform's trust, and so were we. It's a statement of the problem's difficulty: in a payments platform, an app gate is a compliance-and-security product, not a form. Which is exactly why building it self-serve was worth funding, and why we benchmarked against the consumer app stores — Google Play Console, App Store Connect, Shopify Partners — rather than against other payment companies' partner programs.

The transferable framework, before the Square specifics. Making a gated process self-serve means replacing each human checkpoint with a system that does the same job better:

• A paved path instead of a conversation. The submission becomes a structured product surface — every requirement visible, every section tracked, progress explicit — so the applicant always knows what's left.
• Validation instead of correction. Requirements are enforced at input time, not discovered by a reviewer three weeks later.
• A review workflow instead of an inbox. Human judgment stays — for content quality, technical QA, and compliance — but it runs on a status pipeline with explicit states, diffs against previous submissions, and structured feedback the applicant can act on.
• Compliance as product, not meetings. Legal agreements move to click-through; security and technical requirements become a checklist mirrored in public docs, so developers self-assess before they ever submit.
• Comms and monitoring as first-class scope. Every state change notifies the developer automatically, and internal tooling gives the operating team a queue they can actually run.

On Square, that framework became a status pipeline every submission moved through — and both sides of it got real product. The developer-facing half lives in the Developer Console; the internal half was an admin console where reviewers worked a submissions queue, saw per-section diffs against the previous version, ran technical QA gates, and tracked availability across Square's countries. (The internal tooling isn't pictured here; it's someone else's operational surface now.)

When review found problems, the developer didn't get a phone call — they got a flagged listing with per-section feedback and a path back to draft mode:

And the machine talked back. Every state change carried a transactional email — submitted, in review, requires updates — so no developer ever had to ask “what's happening with my listing?”:

The last mile was content: we made the submission requirements public in Square's developer docs, so a developer could see exactly what an effective listing required before writing a word. Requirements you publish are requirements you've been forced to make coherent — externalizing the checklist improved the checklist.

An honest label on these numbers: they're the team's own operational measurements, not a Block financial disclosure — and they're public because the project's design lead tells the same 90-to-20 story in his own portfolio. What I can add from the product side is what the speed bought: with the queue gone, new-app launches grew by multiples, and the platform team's partnerships and content specialists stopped being a routing layer and went back to doing judgment work. The system story — how this fit the platform's operating model — is in The operating model is the product.

The 2022 ship was the beginning, not the end. Over the following two years the team kept pulling humans out of the doorway: the technical QA process moved into the tool itself — walkthrough-video submission, a QA checklist mirrored one-for-one in the public docs — and, the step I cared about most, a click-through agreement that let any developer submit an app to Square without talking to partnerships first. That closed the loop on the original scope decision: the door didn't just open faster for invited guests; it opened for everyone.

That's also the claim you can check. Square's partner page today says any developer can build and launch an app in the App Marketplace, and the developer forums announced the fully self-serve submission experience publicly in 2024. The infrastructure outlived my tenure — which is the whole point of infrastructure.

One more thing these rails carried: when we built Add-ons a year later — third-party functionality rendered natively inside Square's own surfaces — its distribution path was this same submission system, extended with an add-ons section. Bet #1's infrastructure became bet #2's launchpad. Platforms compound like that when the boring layer is built right.

• Ship in-context guidance with v1. Deeper content guidelines inside the editor — examples and standards at the point of writing — were struck from the first release for scope. Right call under the timeline, but it left quality correction to the review loop, which is the expensive place to do it.
• Design for localization from the first schema. Square operates in multiple countries and currencies, and the listing model should have accepted developer-provided translations from day one. Retrofitting internationalization into a content pipeline costs more than building it in — a lesson I'd apply to any platform surface now.
• Publish the operational metrics as we went. The 90-to-20 result lived in internal dashboards for years before it had a public telling. Build the public proof alongside the work — filings, docs, keynotes — so the record can speak at full resolution when you need it.