The Gate Is Gone: The App Store Moment for AI Is Here
The Gate Is Gone: The App Store Moment for AI Is Here
First published on X, October 2026.
In July 2008, Apple opened the App Store with about 500 apps. What followed was a new class of builder. Suddenly a solo developer in a dorm room could ship something to millions of people.
But there was still a gate. You had to know Objective-C. You needed a Mac, a developer account, and the patience to get through review. The App Store democratized distribution. It didn’t democratize building.
That’s the part that’s changing right now.
A Universe of Builders
With Grok Bot - and, to a degree, what Meta is starting to do with Muse - the builder tools themselves are going consumer. I’m not a huge coder. I’ve worked with, and translated ideas to, engineers and coders throughout my career, but if you need me to write in Java, or Python, or Ruby on Rails - good luck. That is not my skill set.
And yet, here we are, where I can build a full-stack wedding operations product anyway, for my own wedding, in plain English, with a bot that has its own computer, a browser, a schedule, and the judgment to stop and ask before it does anything that matters. It’s mind-blowing to me.
That’s the App Store moment for the consumerization of AI: a marketplace where regular people can build, publish, and install things that actually do work.
And just like 2008, the categories will get crowded fast. That’s fine. The right ideas, built by people who actually live the problem, will win out.
The Unit Is a Company: TaaC
Building Wedding OS showed me something I find fascinating: most of what gets shared today is a prompt or a single skill. Draft this email. Summarize this inbox. Do this super repetitive task each day so I don’t have to do it anymore. That’s all good - it’s useful.
What I think wins in this store is bigger: a template that behaves like a small company. One spine, many skills, complex built-in logic about what matters when, and trust gates so it never does something you didn’t approve. That’s the pivot from basic templates and prompts to Templates as a Company (TaaC).
Wedding OS is my proof, and my first TaaC.
Day 9 of building Wedding OS in public: we’re live.
Every wedding site has a checklist tool. What they don’t have: Approve-first vendor email, call, and text system, with a dynamic ops engine that flexes to you.
Public template in the @grok Bot contest.
Who Cares About Weddings?
I get it. This isn’t a use case for everyone. It’s the anti-“here’s a tool to make everyone’s life easier” type of deployment. I’m fine with that.
But if you’re getting married (or remember the experience), the hyper-complex composite picture of a TaaC like this should resonate. Wedding planning gets sold as mood boards and venue tours. The real expense is coordination, time, invoices, deposits, room blocks, vendors who go quiet, RSVP lists split across multi-day events, competing quotes that are irreconcilable, the day-of plan nobody starts until it’s late. It goes on and on. Couples either pay a planner thousands (which is no guarantee of success) or become the unpaid project managers of their own wedding.
As a TaaC, Wedding OS takes on all those various layers. It starts with an intake, and everything builds from there: a 110+ task checklist that auto-flexes to your needs and the days you have left, a budget sketch from your real numbers, vendor sourcing that stops at a draft until you approve, contract and paperwork tracking, guest groups, RSVPs and seating from one spreadsheet, and day-of runbooks that build from day one.
And, my favorite part: it has pre-built scripting that can run via APIs (like Bland AI) to literally perform vendor calls and texts - just another thing off the plate of a soon-to-be-married couple.
Breaking the Chassis
It’s not without its issues, and I mostly found them fascinating. Building this kind of stack, in a brand-new ecosystem, has shown:
✱The pipe isn’t the brain. I wired up texting through a voice and SMS service. Outbound worked great. But when guests replied, the answers came from that service’s own auto-agent, not from Wedding OS. Going forward, it’s key to know exactly where the intelligence lives. In a TaaC, that’s the spine, so route everything back to it.
✱QA that didn’t ship. After deploying the template, we found real fixes in QA testing. Because of the template’s size (100 KB+), publishing the updated template kept creating empty stub versions instead of the new one, so the fixes didn’t land (and still haven’t, as of writing this). Going from V1 to V2 (and beyond) in the future will need some smoothing.
✱The approval gate is a feature. Every guest and vendor message waits for a yes from the user. Early on that felt slow. Now I think it’s the whole point of this TaaC’s trust gates - the bot does the work, the human keeps the judgment.
✱AI testing needs a clean room. If I’m proud of one discovery in this process, this is it. In the 2010s, you built and tested an app inside a walled garden - meaning you could prototype in a constrained, concise, and predictable space. Today that garden is gone. Even when I cloned a fresh copy of my own template, the moment it loaded it could see my memory, my context, and my connected apps - and it quietly used all of that to tailor the experience. Great for me. Terrible for QA, because a brand-new user starts with none of it. Every builder in this new store is testing in an environment that’s already personalized, which makes it hard to prep a TaaC for a true clean-slate customer. The next layer of tooling this space needs is real clean-slate test environments - fresh users, no memory, no connections - so what we ship is what strangers actually get.
None of these are reasons to wait. It’s the same friction the early App Store had back in ’08 and ’09, and the people who can run with it now will be the ones with the best products when the store matures.
...And It’s Getting There
One of the funniest parts of building in public was something that happened outside of my control. I burned a lot of early development time trying to get two people - the presumed couple-to-be (but it could also be a parent, a sibling, or a friend) - onto the same instance of one Wedding OS bot.
The conclusion I came to, at the time, was no. Not yet.
Then, mere days after I shipped Wedding OS, this happened...
At SpaceXAI, Team Bots prep our account teams every morning, coordinate engineering work, answer data questions, triage customer feedback, and run hiring loops.
Team Bots are now in public beta for Teams and Enterprise.
This is a massive win for Wedding OS, because multiplayer team bots can keep a highly complex ecosystem consistent for the key users involved in a wedding. And the irony isn’t lost on me. Even in a sprint-speed build, this announcement showed how fast the chassis is getting stronger. Something that was impossible during my build was standard a week later.
Every week the tooling closes another gap, and weddings are a perfect place to start. For a lot of couples, the wedding industrial complex is a massive stressor, a massive cost, and (on occasion) a bit of a grift. It doesn’t have to be.
Why the Builders Win the New AWS Moment
A lot of the AI exhaustion - I sense - from the average user comes from the half-life of tools and LLMs. Every week there’s another system, another model, another tool (seemingly) to learn. So the question in a moment of AI fatigue is: who wins? Where do you hitch your wagon? Which builder do you bet on? I have a thesis.
Amazon built industrial-strength infrastructure to run its own store, got very good at it out of necessity, and then rented that muscle to everyone else. AWS was a byproduct of a real business with real needs.
I think that’s what’s happening with Grok Bot - and potentially places like Meta, Google, and Microsoft. These are companies that already had businesses to run and needed AI to run them. Once you’re dogfooding your own tool every day, you fix what breaks, because you need it fixed. Then the customer gets the upgrade.
You also see around corners. An LLM, built for the sake of AI, has to guess at what the consumer wants or needs next. The companies building for the real needs they’re immediately facing have cut the guesswork. Amazon built AWS for what it needed, and I think SpaceXAI and Meta are positioned similarly.
Team Bots were already doing real work inside SpaceXAI before they shipped to customers. I doubt that feature would have arrived as fast without that internal need. Plenty of companies have big internal needs. The edge is how fast you turn what you use on Monday into what your customers get on Friday.
The Bet
In 2008, some of the biggest winners were the people who saw a new kind of store and built for it first.
This time the gate to building is mostly gone, and the unit worth building is a TaaC. Some winners will be discrete, small, and universally applicable. Others? They’ll have deep domain expertise, handle bespoke situations with longitudinal complexity, and they’ll offer solutions that execute less as a tool or a product, and more as a company, working under your complete control and discretion.
Wedding OS is my first TaaC in that store. It won’t be the last.
Header image: Paolo Veronese, “The Wedding at Cana” (1563), Musée du Louvre. A wedding feast with a few new guests: the Grok Bot crew, crashing the party.