Web, Mobile, or Device: Where Your MVP Should Live

Almost every product conversation we have starts the same way. A founder describes the problem they want to solve, and within two minutes someone says the word “app.” Usually an iPhone appears, and someone sketches boxes on a napkin.

Here is the interesting part: the platform is often the least examined decision in the whole project. “We need an app” is a delivery mechanism, not a strategy. Whether your MVP lives on the web, on a phone or inside a piece of hardware changes your budget, your timeline and how quickly you can learn from real users.

Here is how we work through that decision during discovery, and the questions that actually matter.

Start where the problem happens

Platform follows context. Before thinking about technology, ask one question: where is the user, and what are they holding, when the problem occurs?

• If they are at a desk, in a browser, working through a task, a web application is probably your fastest path.
• If they are standing in a warehouse, walking a job site or sitting in their car, a mobile app is probably the answer.
• If the problem involves the physical world, like a machine that needs to report its own status, you may be looking at an embedded device with software wrapped around it.

Most founders have strong opinions about the first two and have never seriously considered the third. All three are real options, and picking the wrong one is expensive in both directions: you can overbuild the platform, or you can build the right product on the wrong surface.

The case for web first

For most B2B tools, dashboards, marketplaces, internal systems and anything with a workflow longer than a few taps, we recommend a responsive web app first. Here is why.

Nothing to install. A link works everywhere. On day one you can send your MVP to a customer in an email, and they can be using it thirty seconds later. App stores are powerful distribution, but for a first release, install friction slows down the learning loop.

One codebase, every device. A well-built responsive web app works on a laptop, a tablet and a phone. You are maintaining one product instead of three.

Iteration speed. Push a fix, refresh the page, and every user has the new version. No app store review, no waiting for users to update. In the weeks after launch, when you are learning fastest, that speed matters more than anything.

Search engines can find you. If part of your growth plan is people discovering your product, the web is the only platform where that happens organically.

Because the browser is a forgiving surface, a focused team can usually get a custom web application live in weeks rather than months. And if your product sells to businesses, the app often doubles as your storefront. The same questions you would ask of any marketing site, like the ones covered in this list of things your website should answer before sales does , apply to a B2B product’s login page and dashboard too.

The case for mobile first

Sometimes the phone isn’t a smaller version of your product. Sometimes it is the product. Build mobile first when:

• The job happens away from a desk. Inspection apps, deliveries, field service, anything with a camera, barcode scanner or GPS at the center.
• Push notifications are part of the value. Reminders, alerts and messages that need to reach people wherever they are.
• The experience is consumer and thumb-first. Social products and habit-forming utilities live on the home screen, or they don’t live at all.
• Offline matters. A technician in a basement or a driver out of coverage needs the app to keep working and sync later.

The tradeoffs are real. Native mobile usually means two platforms, iOS and Android, with review cycles on every release and an install step between your marketing and your first user. If those constraints don’t buy you something valuable, they are costs without benefits.

There are middle options worth knowing about. A progressive web app can be installed from the browser and send notifications on many devices, and cross-platform frameworks let one codebase ship to both stores. When clients come to us already set on building a mobile app , we usually spend part of discovery making sure a simpler first version isn’t hiding in plain sight.

When the product is a device

Some of the most interesting projects we see don’t fit on a screen at all. If your product is a sensor in a grain bin, a controller on a factory line or a tracker in a fleet of vehicles, you are building embedded IoT software: firmware on hardware, a connection to the cloud and usually an app that lets a human see and control it.

Embedded products play by different rules. There is physical inventory, manufacturing, certification and a much harder time quietly fixing something after it ships. The engineering spans device, server and app software at the same time.

But the MVP logic still applies, and it usually saves enormous amounts of money:

• Fake the hardware first. Before commissioning custom electronics, prove the value with off-the-shelf dev kits, or even a person entering readings manually behind the scenes. If customers don’t value the data, the circuit board doesn’t matter.
• Build the companion software early. The dashboard and the alerts are where users actually experience the value. That software can be built and tested against simulated devices long before the physical product is final.
• Design for the field. Devices go offline, batteries die and firmware needs to update over the air. Planning for that on day one is cheap. Retrofitting it is brutal.

Web, mobile and embedded work are usually pitched by three different vendors. They don’t have to be, and products tend to get better when they aren’t, because the person designing the dashboard understands what the device can actually deliver.

The trap to avoid

The most expensive version of this decision is no decision: building the iOS app, the Android app, the web portal and the device firmware all at once. Every platform you add multiplies your testing, your bugs and your launch coordination.

Pick the surface where the core job happens. Do that one well. Put the others on the post-launch roadmap, where they can be built properly once the first version has taught you something.

A five question checklist

Before committing to a platform, run your idea through these:

1. Where is the user when the problem occurs?
2. What does the product need from the hardware: camera, GPS, sensors, notifications, offline access?
3. How will the first hundred users find it: a link, an app store or a sales conversation?
4. How fast will we need to iterate after launch?
5. What can honestly wait for version two?

If the answers point in different directions, that’s normal. They usually point to one primary surface plus a roadmap, which is exactly the shape of a good MVP.

How we decide it with you

Platform choice is one of the first calls we make together during discovery, before any production code is written. We map the user’s context, weigh the tradeoffs above and recommend the fastest honest path to real users. For many products that’s a responsive web app. For plenty of others, it’s a phone in someone’s hand or a sensor bolted to a machine. What matters is that the decision gets made deliberately, with the product’s actual job at the center of it.

Get that right and everything downstream gets cheaper: the scope, the timeline and the lessons you learn on day 91.

Not sure where your idea should live? Tell us about it . Helping founders pick the right first surface is one of our favorite parts of discovery.