For most of the years I have been building products, the slowest part was building. That is no longer true. The slowest part of my last two launches was waiting for a person I will never meet to approve work that took a few days to write.

The bottleneck moved. It used to be me. Now it is someone else’s queue.

What actually happened

PopSmart Studio is the clearest case. Studio turns one product photo into on-model shots and scenes, and the obvious next move is publishing those images where merchants actually sell — Meta, Pinterest. Building each integration was fast. The OAuth flow, the catalog calls, the posting pipeline: a couple of focused days each, because I was not writing most of it from scratch anymore. Then I submitted for review, and the project stopped moving.

Meta wanted a screencast, a privacy policy URL, a written justification for every permission, and then a reviewer’s verdict on a timeline they do not publish. Pinterest’s API access is its own gate that sits in front of app review — you apply, you wait, you get standard access or you do not. Every round of back-and-forth reset a clock I did not control.

PopSmart Clerk had the same shape on a different doorstep. Clerk is a Shopify app, so it lives or dies by Shopify’s app review. The code was ready well before the listing was. The delay was not engineering. It was the queue.

So I had two finished products sitting behind three human review pipelines, and nothing I could do to the code would move any of them faster.

The constraint moved; the gate did not

AI did not just make me a little faster. It collapsed the exact part of a launch that used to absorb most of the calendar. An integration that would once have been a week of careful API reading is now a couple of days of focused work. The build is no longer the long pole.

The review pipelines on the other side were designed for the old world — a world where it was safe to assume anyone submitting an integration had spent weeks building it, so a multi-week review felt proportional. That assumption is dead. The reviewers are still pacing themselves against a build time that no longer exists.

The result is an asymmetry that did not exist two years ago: I can build faster than the platforms can agree to let me ship. The bottleneck is no longer my competence or my hours. It is the part of the process I cannot touch.

What the queue actually costs

The frustrating thing is not that review exists. It is how it is run.

  • The timelines are not published, so you cannot plan a launch around them. You submit, you wait, and “soon” is the only estimate you get.
  • The feedback is often generic. A rejection that says a permission is “not justified” does not tell you what would justify it, so you guess, resubmit, and burn another cycle.
  • The reviewer is a coin flip. The same submission can pass with one person and bounce with the next, which means the gate is not a standard. It is a mood.
  • The cost lands entirely on the builder. The platform loses nothing by being slow. You lose the launch window, the momentum, and the thing you were going to build next.

For a solo studio, that last point is the real tax. I do not have a team to park on a stalled launch while I move on to something else. When a launch stalls in someone’s queue, the whole studio stalls with it.

The part I will defend

I am not arguing the gate should not exist. App review is the reason a merchant can install a Shopify app without auditing it, and the reason a Meta permission is not a free pass to someone’s customer data. Access to other people’s platforms is access to other people’s users, and that should cost something. The review is the price of being trusted with it, and that price is fair.

What is not fair is that the price is paid in an unpredictable amount of my time. The mechanism is right; the implementation has not caught up to how fast the other side of it now moves. A trust gate that cannot tell you when it will open is not protecting anyone from bad actors — it is taxing the honest ones, because the bad actors were never working to a schedule anyway.

The rule I took from it

So I changed the order of operations. Review is no longer the last step before launch. It is the first. The day an integration is even roughly real, it goes into every queue it will ever have to pass, and I build the rest of the product while strangers look at it. I assume the gate is slower than the work, because now it always is.

Plan the launch around the queue you do not control, not the code you do. The code is the fast part now. Build like it.