Recently, a video about AI apps triggered me, and I need to talk about it. Pivot to AI is a great channel that I subscribe to - it covers the current AI disruption and works hard to dispel hype and misconceptions with a healthy dose of snark and wry humour. This week, Pivot reviewed a paper from the National Bureau of Economic Research, Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools, that investigates increase of new apps appearing in app stores without a matching increase in total consumer app usage.
The conclusion Pivot reaches is that people are rejecting a flood of poorly implemented applications characterized as “crappy AI spam apps.” Well, as a producer of said “crappy AI spam apps”, I took that as a direct challenge.
I want to say this clearly: I am precisely the person Pivot is warning us about. A solo developer, using agentic tools, adding to the flood. So this isn’t a sermon from high ground - it’s the view from the mudpit. I want to talk about what I’ve learned in my first few months publishing apps to the Apple App Store, the rules I’m holding myself to, and why I’m putting them in writing: so I can be held accountable to them.
Slop isn’t an AI problem
There is an obvious abundance of low-quality apps, and it’s a real challenge for end users to sift through stacks and stacks of minimum-viable-products that were one-shot out in a week just to get something - anything - into a store. I agree with that completely.
But two truths get bulldozed by the “AI spam” framing: not all slop required AI, and not all AI apps are slop.
Historically, app development has been really hard. Smaller devices must manage resources far more carefully than software built on desktops with lots of memory, abundant storage, and continuous power. Code was lower-level and more idiosyncratic, so creating a truly enjoyable experience took teams and a lot of effort. A developer could build something functional but it probably didn’t look or feel good. A designer could build something attractive but it might be flaky or have thin capabilities. It took unicorns, or teams, usually working for months or years, to deliver real quality - which is why the ratio of great apps to mediocre ones has always been so small.
Agentic coding tools totally collapsed that barrier to delivery. Pretty much anyone willing to spend the time and pay for the tokens can now get an app into a store within a month. Obviously the opportunity has presented itself and people who were previously unable to overcome prior technical barriers are now taking their shots to deliver the solutions they feel the market is missing. The paper presents the data to prove it. But I believe the true source of the “sloppiness” isn’t the letters “A” and “I” - it’s that new, lowered barrier to entry meeting a much older, bad piece of advice: ship now, fix later.
I do want to point out something about the report that the snarks gloss over: there’s a flood of AI code being generated and new apps mostly go unused - but the paper intentionally does not conclude they are all “slop”. It offers two explanations but doesn’t cite either as a definitive cause: either the marginal apps are low quality, or discovery and adoption are themselves a bottleneck. That second possibility is the one I want to continue to deal with, because it’s the one that I am currently stuck on and should legitimately keep potential builders up at night.
”Failing Fast” on Day One is still “Failing”
Conventional wisdom says to get a product to market as quickly as possible and iterate rapidly based on user feedback. In a space where your product is in high demand and you have a collaborative customer base, that’s awesome advice. The feedback loop is the engine, and the MVP is how you turn the key.
But in an oversaturated marketplace, that engine never turns over.
There are already millions of apps out there with many having solved the most common problems years ago. The odds of a new app organically generating attention, downloads, ranking - and then the reviews and feedback that are supposed to power your iteration engine - are slim. Discovery overwhelmingly favours apps with a substantial marketing budget, influencer approval, or some other powerful impetus for adoption. So the MVP you shipped as a starting line, planning to refine it once users tell you what’s wrong, may sit there.
No discovery. No users. No feedback. No iteration.
The thing that was meant to be the beginning of a conversation becomes an epitaph. And there’s another cruel twist hiding in that NBER data: in a discovery-starved market, a high-quality app and a slop app may look identical on Day One. Both sit there in silence. The market won’t tell you which one you shipped - not for months, maybe not ever. You don’t get to find out the easy way.
So let’s be honest about the full shape of the trap: shipping quality doesn’t solve the discovery problem. Having your market find your app is a whole separate problem with its own answer, and I’ll get into it another time - maybe after I’ve figured it out myself. But shipping slop guarantees you never even reach the discovery problem, because the rare person who does stumble onto your product page takes one look and leaves, and you’ve blown your single impression.
If the iterate-after-launch loop is broken, the work it was supposed to do has to happen before you ship. You need to front-load the quality.
Front-loading the quality
Have a clear, defined purpose. Quality apps are built to solve a specific problem. Resist the urge to bolt on extra features that don’t serve that solution; they confuse the user and dilute the thing you do well. “Complete” is not the same as “feature-rich.” A complete app fully delivers on its purpose with nothing missing and nothing extraneous. That’s the target - not a longer feature list.
Be holistic - mind the core and the edges. Get your fundamentals solid: stability, security, data integrity, accessibility. Then go looking for trouble at the margins: unexpected edits, unhandled exceptions, the inputs and behaviours no reasonable person would try. Real testing means going way off the happy path on purpose to find those things yourself, before a hard-won converted user finds them for you and leaves forever.
Build the feedback you’ll need - on your terms. If the marketplace won’t hand you a feedback loop, build your own into the product: error reporting and diagnostics the user chooses to share. Done right, this can be a privacy feature, not a surveillance one. Your app can capture what goes wrong locally, the user reviews it, and nothing needs to leave the device unless they decide to send it. You get the signal you need to improve your app without becoming another needy, naggy tattletale.
Usability is style and taste - the very things the models still lack. AI is excellent at producing something that looks good. It is not yet good at producing something that feels right. It solves input and output functionally - about as well as a capable junior developer - but it has no instinct for the small frictions, rhythms, and expectations that separate a tool you tolerate from one you reach for. That instinct is judgment, and judgment is exactly what AI is still lacking in (for now).
The NBER paper proves this point almost by accident - its title is the whole argument in four words: Writing Code vs. Shipping Code. Across more than a hundred thousand developers, AI sent code generation quantities through the roof - multiples more code has been written. But finished, shipped releases rose only a small fraction as much, and real-world usage of the resulting apps didn’t rise at all. The bottleneck was never generation. It was the human layer downstream - review, integration, and the judgment call about whether the thing that got generated is any good. The machine can flood the top of the funnel; only judgment clears the bottom. That judgment is the entire difference between an app and slop, and it is the exact part the AI can’t yet do for you (yet).
The test
I’ve been talking about apps, but the same logic applies to just about every AI-powered initiative out there - from indie SaaS offerings to the features being bolted onto products with billions of dollars behind them.
Most devs feel about their apps the way most parents feel about their children - incredibly proud, and eager to show off their greatness to the whole world. But before you publish to the store, run the one test that really matters: would you download this if you came across it cold, with no idea you’d built it?
Be brutally honest. If the answer is no, then you haven’t smoothed out the rough edges yet, or the purpose isn’t tight, or it simply isn’t ready. Hold off. Keep iterating, keep improving - just do it before the launch, not in the silence afterwards.
Just to be honest, I haven’t really proven any of this works (yet). These are the lessons I took from my own early products, and the standard I’m trying to clear with the next ones. But if I get this wrong, I’ll be writing about that too in a few months.
And in fairness to Pivot, who I think is mostly right: there is a flood, and a lot of it is low-effort. I’m not claiming the apps are all wonderful. I’m claiming that “supply up, usage flat” cannot, by itself, tell you whether the thing you shipped is any good. The discovery bottleneck the paper refuses to rule out is exactly what should make you slow down and get it right before you ship. Don’t give up, but be patient and mindful.
Remain insistnt that your value proposition is strong, persistnt in refining and improving your UX, and consistnt in handling customer feedback.
Be persistnt.
