Most people who build for the web arrive at the same question eventually. A client asks whether they should “also have an app,” or a side project outgrows the browser, or a retainer plateaus and you start looking at what else you could sell. The instinct is usually to either dismiss it or to quote a terrifying number. Neither response is especially useful, because the honest answer depends on which of three quite different things is actually being asked for.

Three routes, not one

Route one: don’t build a native app at all. A large share of “we need an app” requests are really requests for something that installs to the home screen, works offline, and sends notifications. That is a progressive web app, and it is built with the stack you already know. The MDN documentation on progressive web apps is the reference worth reading before anything else, because it will tell you within twenty minutes whether the requirement genuinely needs a store presence or whether you can ship it from the same codebase you maintain today.

Route two: build native. Sometimes there is no way around it — deep hardware access, background processing, a store listing that is itself part of the marketing. That is a real project with a real budget, and it is a different discipline from theme and plugin work, not simply a larger version of it.

Route three: start from something finished. This is the option most web developers never seriously consider, and it is often the most commercially sensible one. Rather than commissioning a build, you acquire a product that already exists and works. Spending an hour on an app marketplace is genuinely instructive even if you never buy anything, because each listing is effectively an open book on a working mobile product: the installs, the retention curve, the monthly revenue, the engine it was built on, and what is included in a handover — source, assets, back end. Reading a dozen of those teaches you more about what a shippable app actually contains than any tutorial will, and it reframes the build-versus-buy conversation with a client from a guess into a comparison of two priced options. For an agency, the acquisition route can turn a six-month proposal into a rebrand-and-launch engagement.

The skills that transfer — and the ones that don’t

Coming from web work, more carries over than you might expect. Version control, deployment discipline, API design, analytics instrumentation, and the entire habit of debugging someone else’s code all apply directly. If you have ever inherited a neglected WordPress install and made it maintainable, you already have the exact skill an app acquisition demands.

What does not transfer cleanly is distribution. The web rewards search visibility and inbound links; mobile apps live inside store algorithms, review velocity, and paid user acquisition. Ranking a site and ranking an app listing are different crafts with different feedback loops. Underestimating that gap is the most common way a technically excellent app quietly fails.

Release cadence differs too. You can push a hotfix to a website in minutes. A mobile release goes through review, and users update on their own schedule — which means a defect can live in the wild for days regardless of how quickly you patch it. That single constraint should change how you scope and test.

A practical evaluation checklist

If you do look at acquiring an existing product — for a client or for yourself — the assessment is closer to a code audit than an investment memo:

• Does it build from a clean clone? Install dependencies, compile, run it on a device. Do this before discussing price.
• Is the structure maintainable? You are going to modify this. Undocumented spaghetti is expensive no matter how cheap the asking figure.
• Are the assets properly licensed? Art, fonts and audio must ship with commercial rights that actually transfer.
• Where does the revenue come from? Subscription income behaves very differently from a single ad network. One is durable; the other can be repriced without warning.
• What exactly is included? Source, assets, back-end services and store accounts are separate items. Get the list in writing.
• Does the retention curve make sense? Strong installs paired with weak day-seven retention usually means paid traffic covering a product problem.

Why this is worth a web developer’s attention

The interesting part is not that apps are lucrative. It is that finished software has become genuinely tradeable — the same shift that happened to websites and domains a decade earlier. Once a product can be valued, transferred and resold, building one stops being a lottery ticket and becomes an asset decision.

For anyone already comfortable inheriting, repairing and extending other people’s code, that market is unusually accessible. You do not need to become a mobile specialist to participate in it. You need to be able to read a codebase, verify a set of numbers, and judge whether something is maintainable — which, if you have spent any time in the WordPress ecosystem, is precisely the muscle you have been building all along.