Web, PWA, or Native Apps

People ask Alevi Group for an app when what they have is a job to be done. Sometimes that job belongs on the web. Sometimes it belongs on a phone, installed, with the device doing real work. Sometimes it sits in between: a progressive web app that can be saved to a home screen and still share one codebase with the site. Choosing badly is expensive, because the expensive parts are not the first screens. They are distribution, offline behavior, payments, review, and the second year of upkeep.

This note is the way we choose. It is not a ranking of technologies, and it is not a claim that one of them is modern and the others are not. Alevi Group builds custom software, SaaS platforms, and mobile apps. All three shapes are available. The discipline is refusing the one that does not fit.

Start from the moment of use

Before we talk about stores or frameworks, we ask where the person is when the work happens. Are they at a desk, with a keyboard, following a link someone sent? Are they between rooms, one hand occupied, needing the same three actions every day? Are they somewhere the network drops? Do they need the camera, precise location, Bluetooth, or a notification that must arrive even when they have not opened anything?

An Alevi app, when we use that phrase, means the shape that fits the job: a website, a PWA, or a native client. The name on the invoice does not change the physics of the device.

When a website is the product

A website is the right product when the work is occasional, linked, and broad. People arrive from search, from a message, from a document. They may never come back, or they may come back next month. They need a URL they can trust, a page that explains itself, and a path that works on a phone browser without an install. Account creation, if it exists, should earn its place. Many serious tools are websites. There is no trophy for making them pretend to be apps.

This site is a website on purpose: static, specific, and easy to read. That is a different problem from a product your customers use every day. A marketing page wrapped around a login is not, by itself, a SaaS platform. The platform is the system behind the login, described in how we approach a custom SaaS build.

When a progressive web app earns its keep

A PWA is worth it when people return often enough to want an icon, and the web is still the right codebase. Saved to a home screen, able to open faster the second time, sometimes able to keep working when the network is poor. It can share accounts, billing, and content with the site, which is a real advantage when there is one product and several doors into it.

We do not sell a PWA as a free native app. Install prompts are easy to ignore, and push on the web is not the same promise on every platform. If the product's value depends on a capability the web does not reliably have, we say so before the plan assumes one codebase. A PWA is often the right first mobile surface while a product is still finding its shape: one way to learn which actions people repeat before paying for two stores and two release trains.

When native is the point

Native is the right choice when the device itself is the product. The camera is not a fallback. Offline is not a nice-to-have. The work happens in short sessions, many times a day, and an icon on the home screen is how people start. Or the product has to be in the store because that is where your customers already look, and a website would be invisible to them.

Native has costs a proposal should say out loud. Two platforms, or a deliberate choice to ship one first. Review times you do not control. Store accounts and policies. A release that is slower than a web deploy. Alevi Group will build the native client when those costs buy something the web cannot, not so a deck can say "mobile app."

The costs people skip

The first screen is the cheap part of all three. The lasting costs are identity, sync, and care. A person who starts on the web and continues on a phone should not have two accounts unless there is a reason. Data entered offline has to merge without destroying the other copy. None of that is solved by a fashionable framework.

Distribution is the other skipped cost. A website can be updated the same day. A store binary cannot. If the product is still changing every week because we are learning, we keep the fast surface on the web until the core job is stable, then add native for the moments that need it. That sequence is in how an Alevi Group project runs.

How we choose, in practice

We write the top tasks, the place they happen, and the capabilities they require. We mark which capabilities are unavailable or unreliable on the web for the platforms in question. If the important tasks are all available on the web, we start there, and we add an installable web app only if return visits justify it. If a task is native-only and the product is hollow without it, we start native, on the platform your customers actually carry, and we say what the other platform will wait for.

We also ask who will maintain it. A client team that will take the work over may not want three skill sets on day one. The repository, the store accounts, and the signing keys should end up with the organization that will live with the product.

Changing your mind later

You can add a native client later, or a web app later. Both are ordinary if accounts and core records were designed as a system, not as a side effect of the first interface. What is hard to undo is a private data model only one client understands. We spend the early design there, whichever shape ships first.

If you already know the moment of use, tell us that in the first note. If you do not, say what people are trying to finish and where they are standing when they try. That is enough to start. The practice behind the choice is on the work page, and the door is the contact page.

Web, PWA, or native: how Alevi Group chooses