Skip to content
Publish

Work out whether you need an app at all, then take the cheapest route that gets you there

There are three ways to get an AI-built web app onto a phone, and they differ by an order of magnitude in cost.

Web app → mobile
Typical timeline
1 week to 12 weeks, depending on the answer
Pricing
The decision review is free
Why it matters

What this is actually about

The parts that decide whether the project takes three weeks or three months, and which nobody mentions until they bite.

  • 01

    The three routes differ by 10x, not by 10%

    A progressive web app is days. A Capacitor shell with real native plugins is weeks. A full native rebuild is months. They are all called "making it a mobile app" and they are not remotely the same project, so being sold the wrong one is expensive in a way that is invisible until the invoice.

  • 02

    Most products need fewer native capabilities than they think

    The usual list is push notifications, offline, and a home-screen icon.

  • 03

    A store listing is a distribution decision

    For consumer products, being in the store is where discovery happens.

  • 04

    Choosing badly is recoverable, but not cheaply

    Starting with a progressive web app and moving to native later is a normal, healthy path.

What clients struggle with

The sentences we hear most, and what we do about each one

Paraphrases of things founders have actually said on scoping calls. Left column is the experience; right column is the work.

  • "My users keep asking for an app"

    This is genuine feedback and it is usually not literal. Users ask for an app when the mobile web experience is slow, when they have to log in every time, or when they cannot find it again.

    How we help

    We look at what they are actually complaining about before recommending a build.

  • "An agency quoted me a rebuild and I do not know if that is right"

    The quote is for the most expensive of the three routes, the reasoning is not written down, and there is no way to evaluate it without already knowing the answer.

    How we help

    The decision review is free and it ends in writing: which route, why, what it costs, and what you would give up by taking the cheaper one.

  • "I need push notifications"

    The most common single requirement, and the one where the platforms differ most. Support and reliability vary by platform and by how the app was installed, which makes "can a web app do push" a question with an annoying, conditional answer.

    How we help

    We test push on your actual target devices before recommending a route, because the answer depends on the platform and the install path rather than on a blog post.

  • "I want to be in the store for credibility"

    A legitimate reason, and one nobody says out loud because it sounds like vanity.

    How we help

    It is a real reason and we treat it as one.

The gates

Everything that has to be true before you submit

We work through every one of these before the first submission, because finding them one rejection at a time is where the weeks go.

  • Route A - Progressive web app

    Days. Installable, offline-capable, push on Android. No store listing, weaker iOS push.

  • Route B - Capacitor shell with native plugins

    Weeks. Your existing web app plus real native capability and a store listing.

  • Route C - Native rebuild

    Months. React Native or Flutter. The right answer when the app is the product rather than a channel.

  • The deciding question

    What must this do that a browser cannot? If the list is empty, route A. If it is short, route B. If the interface itself is the product, route C.

  • Distribution

    Do your buyers find you by searching a store? Consumer, usually yes.

  • Who maintains it

    Every route adds a release process. Route C adds two. Be honest about the team you will have.

What you get

Deliverables

Everything lands in accounts you own, with the certificates and keys in your name.

  • A written recommendation: route, reasoning, cost, and the trade-off
  • Push notification testing on your actual target devices
  • A cost comparison across all three routes for your product
  • If route A: installable progressive web app with offline and push
  • If route B: Capacitor shell with the native capability review requires
  • If route C: a scoped rebuild plan you can take to any agency
The engagement

Phases

Scope is fixed after phase one. Every phase ends in something you keep.

  1. 013–5 days

    Decision review

    Free. We look at the app, test what a web app can actually do on your target devices, and ask what your users are really complaining about.

  2. 021–12 weeks

    Build the chosen route

    Scope and duration follow the decision. Route A is often finished before route C has been scoped.

  3. 0330 days

    Measure and revisit

    Install rate, retention, notification opt-in and crash rate. If route A turns out not to be enough, you now have evidence for route B or C rather than an opinion.

Risk register

What can go wrong, and what stops it

  • Picking the cheap route and outgrowing it

    That is a success, not a failure - you learned what was needed with real usage instead of guessing.

  • Push not working the way a blog post promised

    It is tested on your real target devices during the free review, not assumed.

  • A Capacitor shell rejected as a repackaged website

    Route B only ships with genuine native capability. Where the product has no reason to have any, route B is not recommended in the first place.

Questions

Before you book the call

  • For a great many B2B tools, yes, and it is dramatically cheaper.

  • Yes, when the app does something a website cannot. Capacitor is not the problem; a wrapper with nothing added is.

  • A written recommendation with the reasoning and a cost comparison across all three routes.

Want a straight answer on the route?

The review is free and it ends in writing, including the case for the cheaper option.

Book a Free Call