AI can write my entire app but it can't get Microsoft to approve it
byβ’
My Windows build has been in Microsoft's certification queue for three weeks. Three new models shipped in that time, two of them can supposedly do my whole job, and not one of them can get a human at Microsoft to press approve.
What's the longest you've been stuck on something you couldn't code your way out of?
114 views


Replies
@thomas_conway1Β how did you / are you currently solving this?
The silence already lied to you once, so it can't be read as pending.
That's the part Gal's visibility point and Asad's two clocks both route around. Setting it down works when no news means no news. Yours failed silently on attempt one, which means no news and dead look identical from where you sit, and that's why you keep opening the dashboard.
The thing you control isn't the waiting, it's the sampling. A fixed cadence you decide in advance, once a day at a set time, turns silence into a checked state instead of an open question. Same information, but the ambiguity stops living in your head all day.
Did the first rejection show up in the dashboard eventually, or did you only catch it because you happened to look?
SlimSnap
@abdullah_javaid3Β Only because I looked. The status flipped to failed in the dashboard, no reason attached, and no email ever arrived. It could have sat there another month and I'd have had no idea.
Fixed cadence is a good call. Right now I check whenever it crosses my mind, which is the worst of both.
Though a checked state has limits here. I know attempt one failed. I still don't know why, and that's what makes attempt two feel like a coin flip rather than a wait.
@bickovΒ The three weeks is the wait. The coin flip is a different problem.
Right now Microsoft is the only thing that can tell you whether the build passes, so running one test costs three weeks. That is what makes attempt two feel like chance instead of work. Most of what certification checks is mechanical though, and the Windows App Certification Kit runs that same class of check on your own machine in minutes.
Did that failed submission ever produce a certification report in Partner Center, or was the status flip genuinely the only artifact you got?
SlimSnap
@abdullah_javaid3Β Different process than you're picturing, worth clarifying for anyone else hitting this. My blocker isn't Store certification, so WACK doesn't apply. It's Azure Trusted Signing identity validation, Microsoft verifying my company is a real entity before they'll issue a code-signing cert. No Partner Center submission, no cert kit step, nothing runs on my machine.
To your question: no report. The only artifact was the status going to failed in the Azure validation dashboard. No reason, no email.
The WACK point is solid for an actual Store submission though. Mine is one step earlier, they won't sign until they've verified the company, and that verification is the black box.
@bickovΒ Fair correction, I was one step downstream of your actual blocker.
Identity validation fails differently than certification does. Certification is a human judging your build. Identity validation is a record match, your submitted legal entity details checked against third party business registry data, so a failure is usually a field that does not line up rather than a verdict on you. Registered legal name, address, and whether the entity shows up in the public listing at all are where the mismatch tends to sit.
Which matters because the dashboard is not the only channel. Have you opened an Azure support request against the Trusted Signing account itself? That is a different queue than the validation status page, and it is the one place the failure reason can actually be asked for by a person.
Certification queues are one of the few remaining places where the bottleneck is a person's attention, not throughput, so no amount of model capability touches it. Longest for me was a payment provider's compliance review, and the only thing that ever moved it was finding an actual human to email directly...
Then the only thing left is the order you do them in.
If attempt two goes in before the ticket comes back, you lose the answer either way. It passes and you never learn whether the name was actually the cause, or it fails and you are guessing again with one fewer attempt spent. The ticket is the only step in this whole process that produces a reason, so let it produce one, then resubmit against a confirmed cause instead of a strong hunch.
Worth watching that they do not close the ticket as superseded if a new validation is already in flight when someone picks it up.
The App Store version got me too, but going through it changed how I read the rejection. Mine came back on a launch hang β stalled on a cold start on a device class I'd never tested, flagged under 2.1. First instinct was Gal's: opaque human gate, coin flip, nothing I can do. But the reviewer hadn't read a policy doc differently, they'd literally run my app on older hardware with a cold cache and hit a freeze I never saw, because I only ever launched it warm on my own phone. Once I clocked that, a chunk of "the human gate" stopped being a queue I'm helpless in front of and became a free QA pass on the exact matrix I was too lazy to test: oldest device, cold start, no network, first-ever launch. The truly uncontrollable ones are the policy calls β yours, Gal's payments case β where the clock-reset is the whole tax. But for the crash/hang class, the lever I pull now is "run it the way the least forgiving reviewer will," and the round-trips mostly stopped. Yours is upstream of even that, though: identity validation with no reason and no email is a worse black box than review, since review at least coughs up the guideline eventually.
SlimSnap
@narek_keshishyanΒ Turns out it did cough up a reason, just late. Attempt two failed and the status finally said why: "Email verification failed."
Three weeks of imagining a compliance verdict, and the verification email was sitting in Gmail spam the whole time. Link expired unclicked, status flipped to fail, nobody judged the company at all.
Your read still holds, a review gate at least tells you the guideline. Mine wasn't even a gate, it was a spam filter.
This is such a perfect example of the new reality we're living in β AI has democratized BUILDING, but not DISTRIBUTION or TRUST.
The irony is almost poetic: you can generate an entire functional app in hours (something that would've taken months before), but you're stuck at a gatekeeper that doesn't care about your code quality β they care about reputation and trust signals that AI can't fake for you.
A few thoughts from someone who just launched their first product today:
π The bottleneck shifted β Used to be: can I build this? Now it's: can I get permission to distribute this? The hard problems are no longer technical; they're bureaucratic and trust-based.
π€ Human-in-the-loop is now about compliance, not coding β You still need humans, but for different things: account verification, app store reviews, domain reputation building, community trust.
π‘ Possible workarounds to consider:
- Start with web-only distribution (no MS approval needed) while building trust signals
- Use a publisher or established partner who already has store access
- Build an audience first (social media, PH launch, etc.) so Microsoft sees you as legitimate
- Consider alternative stores or sideloading options
π¨ The bigger question: As more people use AI to build apps, will platform gatekeepers become even stricter? This feels like the beginning of a new kind of "app inequality" β where having a verified developer account becomes as valuable as the code itself.
Thanks for sharing this openly. It's a warning sign all indie builders need to see. The AI revolution isn't "build anything you want" β it's "build anything, good luck getting anyone to trust it."
SlimSnap
@youliqnΒ The frame holds in general, building got cheap and trust didn't. But my case deflates the drama. The gatekeeper judging whether we're a real company turned out to be a verification email sitting in Gmail spam. No trust verdict, just a filter.
On web-only distribution, that's already how the Mac version ships, signed and direct from the site, no store involved. The only stuck part was a Windows code-signing cert, which is plumbing, not a reputation gate.
So I'd soften the ending. Sometimes it isn't good luck getting anyone to trust you it's check your spam folder
Dial
app store review is the one that gets me every time. spent two weeks once waiting on Apple to re-review a payments-related update, got rejected for a guideline that wasn't even the reason they cited, resubmitted, waited again. no model helps with that because the bottleneck isn't code quality, it's a human on the other side reading a policy doc differently than you did. the annoying part is you can't even parallelize it, one submission at a time and the clock resets on every rejection.
SlimSnap
@galdayanΒ Same, and the reset is what actually costs you. Mine failed on the first attempt with no reason given and no email. I only found out by checking the dashboard. Resubmitted, back to zero, and I still can't tell if it's moving or silently dead again.
Everything downstream got faster and the approval step didn't move at all.
Dial
@bickovΒ no email on a rejection is brutal, at least give people something to act on. silently going back to zero with no diagnostic is worse than a slow yes. makes me think the real fix isn't a faster model, it's just better status visibility from Microsoft's side, a dashboard that actually tells you where in the queue you sit instead of pass/fail with no timestamp.
The Microsoft queue is a particular kind of stuck, because the skill that got you this far stops working. Everything else in a build responds to effort. You push, it moves. A certification queue does not care how good you are, and that is the part that itches. Not the three weeks, but that your competence suddenly buys you nothing.
The longest I have been stuck was never on a hard problem, it was always a dependency on someone who had no reason to hurry. What helped was separating the two clocks. There is work time, where effort maps to progress, and there is queue time, where the only honest move is to set it down and go build the next thing, so the wait runs in the background of a good day instead of the foreground of a stalled one. Three new models shipping while you sit there stings, but none of them are stuck where you are either, and that gap is usually a moat rather than a threat. The approval lands on its own schedule. The only thing you control is whether it gets to sour the weeks around it.
SlimSnap
@asadmalik901Β Two clocks is right, and I've been doing it by accident. Shipped a scrolling capture feature and wrote a few posts while this sat there, so the wait has been background noise rather than the main event.
The part that still gets me is the silence. Work time gives you feedback even when it's bad news. The queue gives you nothing, so you can't tell whether you're waiting or whether it already failed weeks ago and nobody sent the email. Mine did exactly that on the first attempt. That's why I keep checking instead of leaving it alone.
@bickovΒ And then the black box turns out to be a spam folder. There is something almost perfectly humbling about that ending. I would not file it under silly mistake though, it is the exact tax of the silence you named. When a channel gives you nothing, the brain fills the gap with the heaviest story available, and "Microsoft is judging whether we are a real company" weighs a lot more than "check spam." The small thing I am taking from your thread: when a system goes quiet, widen where you look before you widen what you imagine. The reason is usually smaller and dumber than the fear. Glad it was nothing about you or the company in the end.
SlimSnap
@asadmalik901Β You're right it wasn't a silly mistake, it was the tax of the silence. Three weeks widening what I imagined, when the answer was in a folder I never opened. Good thread, thanks for staying in it.