11:17pm. The owner of three coffee shops sends us exactly one line: “The agent answers fine, but customers still have to message me. What now?”
It sounds like a technical question, but it is really a product question — and the reason for this post: a few honest notes on building an app with AI as a beginner, roughly what we end up saying to clients at eleven at night.
Here is how it usually goes: you spend two weeks building an AI agent that reads documents, looks up records and calls APIs, and answers so well it is slightly unsettling — then you notice it runs in your terminal, and nobody but you can use it.
That is where the real work starts: the next job is not “make the AI smarter” but putting a UI on it so other people can click something.
You have an agent. Now give it an interface
End users do not care which model you picked, how long your prompt is, or how fast your vector database runs — they care about exactly three things: it opens, it clicks, it gives an answer.
That is where you hit the first fork in the road — and the one that quietly costs people an extra month: web app or mobile app?
There is no answer that fits everyone, but there is a faster way to decide than your gut: pick based on what blocks you at release time, not on how it feels.
| Factor | Web app | Mobile app |
|---|---|---|
| Release blocker | Buy a domain, deploy, done | Build the metadata, policy and screenshots, follow store guidelines, then wait for review |
| Time to first version | One evening | Days to weeks; merge new features into the first version before you submit |
| Upkeep cost | Cheaper, no platform fees | Developer account fees, updates for two platforms |
| Risk of removal | Practically none — the domain is yours | An app can be pulled at any time if it breaks policy |
| Best when | Small audience, internal tools, lookups | Daily use, push notifications, camera or location |
Mobile apps: the hard part is not the code
Almost every week we run into a charming misunderstanding: that the hardest part of a mobile app is writing the code — when in fact, once the agent works, the code is just a thin layer of interface and the real work is getting the app out into the world:
- A developer account. Apple charges yearly ($99/year) and Google Play charges once ($25), and you may also need to verify your business identity.
- The review queue. A first release usually takes days to weeks: you do not choose your launch date — a reviewer does.
- Store guidelines. Privacy rules, how you ask for permissions, content rules, in-app payment rules — read them once and you will understand why some very plain-looking apps take six months to ship.
- Rejection, then do it again. A rejection is not a disaster, but each round costs days and you resubmit from scratch.
- Two platforms, two releases. Every small change walks through the release cycle.
- An app can be pulled at any time. No consent and no warning: if a store decides your app breaks policy, it can disappear from the shelf — and you lose your only distribution channel with it.
In other words: for mobile apps, the hard part is no longer code — it is paperwork. And you cannot vibe-code paperwork.
The app market: more people building, fewer people downloading
Two numbers, and they only make sense read together.
One: downloads are falling. In early 2026, Appfigures estimated that combined App Store and Google Play downloads reached about 106.9 billion in 2025, 2.7% lower than the year before — the fifth consecutive annual decline, after a pandemic peak of roughly 135 billion — and as unbelievable as that number still sounds, the direction is clear: people install fewer apps than they used to.
Two: submissions are surging. In the first half of 2026, the number of new apps arriving on the App Store doubled year over year to roughly 560,000, according to figures reported by The New York Times — mostly because AI made it possible for non-programmers to build one fast.
Put those two together — a smaller pie, twice as many people in the queue for it — and the consequences are easy to guess:
- Keyword competition. You are not only fighting for user attention, you are fighting for a name on a store against hundreds of thousands of other new apps.
- Stricter review. Apple itself tightened its guidelines, adding criteria to reject apps that “do not add value” to the App Store — plenty of apps get through the coding part and die right here.
- Longer waits. Apple still says 90% of submissions are reviewed within 48 hours, while developers describe waits measured in weeks — for you, that means launch day is not yours to choose.
And one thing almost nobody tells you before you start: an app can be pulled from the store at any time if it is judged to break policy, with no need for your consent and no time to fix it — a risk that simply does not exist with a web app, where the domain, the data and the product are yours.
Web apps: building an app with AI in a single evening
Web apps, by contrast, are where AI shines brightest right now, because the loop from idea to something runnable is measured in hours.
You need exactly three things:
- A coding tool with AI. Claude Code, Codex or GitHub Copilot all do the job: they will not invent the product for you, but they write very quickly the parts you already know you need.
- A framework that already exists. Do not start from zero — a few easy starting points:
- React Router — the framework React itself maintains: routing, forms, data handling and server rendering are all built in, and if you already know React this is the smoothest place to start — and the one AI coding tools know best.
- Next.js — also React, but packaged with more for apps that need logins, a database and several business flows.
- SvelteKit or Nuxt — two tidy options, pleasant syntax, communities big enough that you will not feel alone at 2am.
- Somewhere to deploy. Cloudflare, Vercel and Netlify all have free tiers that are plenty for an early stage, and they handle certificates, domains and global distribution for you.
So when do we recommend the web without a second thought? When the audience is under 100 users and the need is narrow: room rentals of a few dozen rooms, a restaurant menu opened by QR code, bookings for one small shop, an internal lookup tool for a team of four. At that scale our advice is blunt: build a web app, and build it yourself — a couple of evenings of work, hosting that fits inside a free tier or costs very little, and no service to hire, because a mobile app for a few dozen users is far too much paperwork for far too little benefit while a web app you open from a link works today.
Let’s be straight: at that scale you do not need us — we get involved when a system starts running into the things vibe coding cannot carry: security, permissions, load, and keeping it alive around the clock.
What about WordPress?
The short version: WordPress is a rigid boilerplate built to solve the no-code entrepreneur’s problem — shipping a content website — and what it does badly is customization: want a new business flow, a different behaviour or another way of displaying something, and you are off hunting for a plugin or settling for “close enough”.
And now that AI writes code alongside you, the reason “I cannot code” — is gone.
For the same amount of time, vibe-coding a web app from scratch with a framework and an existing template will be better and FASTER: your own data model, your own user flow, your own fine-tuning of every interface detail — and no plugin to ask permission from.
If you already run a WordPress site and it works, leave it alone simply because it is fine; but if you are building a new app from 2026 onwards, think again.
Vibe coding gets you something lightweight, not a large system that runs 24/7
Vibe coding is good at exactly one thing — turning an idea into something clickable — and bad at the rest: turning something clickable into something that runs every day, for many people, and then for very many people.
These are the things that only show up after the demo runs smoothly:
- Security. API keys sitting in browser-side source. No rate limits. No permissions. Nobody stopping a stranger from typing input that walks your agent off a cliff.
- Cost. A model call in an unbounded loop can burn money faster than any ad campaign you have ever tried.
- Load. Five users and five thousand users are two different problems, not two settings of the same problem.
- Data and backups. Losing a database once loses your customers’ trust, and usually the customers.
- Monitoring. When the system breaks at 3am, who knows? Where do you look? Where did the error come from? If you cannot answer that, you are running on faith.
- The small jobs that are not small. Domains expire, certificates expire, quotas expire, and some library nobody maintains anymore quietly falls over.
Vibe coding is not bad; it was simply not built to answer those questions, which only appear once real users show up.
Where Mon AI fits in
We work with you end to end: writing the app, getting it onto the stores, and advising on which platform fits — including when the answer is “build a web app, do not lose weeks on store paperwork”.
With years of experience building production systems, running cloud servers, and shipping apps on both the App Store and Google Play, we can help you with hard-won experience — not by asking AI on your behalf, the way plenty of newly founded companies do.
On running costs: our target is to run your system for no more than a third of what competitors in your industry charge, and if your current system is expensive to run we will bring infrastructure and operations cost down by at least 30% — if we cannot, we do not charge for that work.
The bottom line
If that coffee shop owner asks again, our answer stays short: with three shops and a few thousand regulars, you do not need an app on a store yet. A web app opened by a QR code on the counter is enough — one evening to build, and customers use it without installing anything.
But if you have a genuinely good agent and want it to become a product — stable enough that people pay for it, safe enough that you sleep — then treat the interface as a real project, not a spare evening.
Thinking about building an app for your customers? Send us one line describing your users — even if you are only curious. We can advise, or help with part or all of it, exactly to the context you have in mind.



