Native, cross-platform or progressive web app: mobile app solutions for Vancouver businesses
Most businesses that ask us for "an app" have a job in mind: let customers book, order, check in or message from their phone. There are three ways to build that, and the right one depends on budget, the device features you need and how your customers will find it. This page explains the choice; each option has its own page with the detail.
We design and build all three for Vancouver and Lower Mainland businesses, along with the backend and admin tools behind them.
Three Ways to Build a Mobile App
Pick the row that matches your situation. If you are unsure, send us the job the app has to do and we will recommend one. None of them is the "premium" option; what matters is matching the build to the job and the budget.
Named Projects
Two application projects from our portfolio, each with its own write-up. Both were built as web applications that run on any phone, the route we recommend most often when customers arrive from search rather than from an app store.
What Every App Project Includes
Whichever route you choose, the deliverables are the same shape. The platform changes what the build stage produces, not what you receive.
Scope and estimate
A written feature list, screen map and estimate after discovery, so the budget is tied to agreed scope.
Design and build
Designed screens reviewed as a clickable prototype, then the app itself with the backend, admin panel and integrations it depends on.
Testing and release
Device testing, then store submissions for native and cross-platform apps, or deployment and install prompts for a progressive web app.
Ownership and support
Source code and accounts in your name, and OS updates plus feature releases on an agreed monthly plan after launch.
How We Work
Four stages, each ending with a decision for you. The native, cross-platform or progressive web app choice is made in the first stage, with the cost of each option in front of you.
01 Discovery
Our project lead defines the job the app has to do, who uses it and which systems it connects to, then recommends the build route with an estimate for each.
02 Design
Our designer produces wireframes and full screens. You review a clickable prototype with the people who will use the app.
03 Build
Our developers build in short releases you can install on your own phones, so feedback arrives while changes are still cheap.
04 Launch
Testing, store submission or deployment, analytics and crash reporting, and a handover of accounts and documentation.
What to Expect
At launch you have an app your customers can install, a backend you can administer and documentation for every account and repository. Analytics and crash reporting are in place from day one, so you can see installs, active users and errors rather than guessing.
After launch, apps need upkeep: Apple and Google ship new operating system versions every year, and progressive web apps follow browser changes. Our support plans cover those updates and a fixed amount of feature work each month, reported against the hours used.
Your Questions, Answered
The questions we are asked most often before an app project starts.
Which option is cheapest?
Usually a progressive web app, because it is one build that runs everywhere and skips store submission. Cross-platform is next, since one codebase covers both stores. Native is the most expensive because iOS and Android are built separately. We give you an estimate for each route after discovery.
Do we need to be in the App Store and Google Play?
Only if your customers will look for you there, or if you need device features a browser cannot reach. Many businesses do better with a progressive web app that customers reach from search or a link. If store presence matters, native or cross-platform are the routes.
Can a progressive web app send push notifications and work offline?
Yes on Android and desktop browsers, and on iOS for apps added to the home screen. There are limits compared with a native app, and we check the features you need against current browser support during discovery.
Who owns the app once it is built?
You do. The apps are published under your own developer accounts, hosting is set up in your name, and you receive the source code. We can maintain it for you on a support plan, but nothing is locked to us.
What if our app is for staff or clients rather than the public?
Then it is probably a custom business application: an internal tool, portal or dashboard with logins for a known group of people. That work has its own page, and it can include a mobile screen where staff need one.