One of the earliest technical decisions in digital product
development is also one of the easiest to get wrong:What kind of application should we build?
A product idea can often be implemented in several ways.
It could be:
- a website
- a web application
- a Progressive Web App
- a native mobile application
- a cross-platform mobile application
- a desktop application
- a backend service with multiple interfaces
The wrong question is:
“Which technology is the best?”
There is no universal winner.
The better question is:
“Which application approach best fits the users, problem, environment, capabilities, constraints, and future of this product?”
That changes the decision completely.
THE CORE IDEA: AN APP IS AN ACCESS STRATEGY
A digital product has capabilities.
Users need ways to reach those capabilities.
Think about the product as:
USER NEED → PRODUCT CAPABILITY → APPLICATION INTERFACE → PLATFORM → INFRASTRUCTURE
The same underlying capability can sometimes be delivered through different platforms.
For example, a printing marketplace could allow a customer to:
- discover printing businesses
- request a quote
- upload a document
- pay
- track an order
Those capabilities don't automatically require a native Android application.
They might initially be delivered through a responsive web application.
Or a PWA.
Or a native mobile application.
The product requirement comes first.
The technology follows.
1. Website, Web App, and Mobile App Are Not the Same Thing
These terms are often used interchangeably, but they describe different ideas.
A website
A website is primarily designed to present information or content.
Examples include:
- company websites
- publications
- documentation
- portfolios
- landing pages
Its primary interaction may be:
DISCOVER → READ → NAVIGATE
A web application
A web application allows users to perform substantial interactive tasks through a web browser.
Examples might include:
- online banking
- project management
- dashboards
- marketplaces
- web-based editors
Its interaction might be:
SIGN IN → INPUT → PROCESS → RESULT → ACTION
A mobile application
A mobile app is software designed specifically for a mobile operating environment.
It may provide deeper access to device capabilities and platform-specific behaviours.
The distinction matters because the engineering requirements are different.
2. The Browser Is a Platform
It is easy to think of a browser as merely a place where websites appear.
Modern browsers are much more capable.
A web application can potentially use:
- local storage
- camera access
- location
- notifications
- file selection
- background capabilities
- device sensors
- network APIs
- authentication mechanisms
- graphics capabilities
The exact capabilities depend on the browser, operating system, permissions, and implementation.
This means:
The web itself is a powerful application platform.
That is one reason web applications can sometimes deliver experiences that once required dedicated software.
3. What Is a Progressive Web App?
A Progressive Web App, or PWA, is a web application that uses web technologies to provide capabilities and experiences associated with installed applications.
A PWA can be designed to provide features such as:
- installation from the browser
- offline or limited-connectivity behaviour
- caching
- app-like navigation
- notifications where supported
- responsive interfaces
- device integration where supported
But PWA does not mean:
“A website that magically becomes a native app.”
The capabilities available to a PWA are still constrained by the web platform and the user's browser and device.
That distinction matters.
4. Native Apps Go Deeper Into Their Platform
A native application is built specifically for a particular operating system and its development environment.
For mobile, this commonly means developing specifically for platforms such as Android or iOS.
Native development can provide strong access to platform capabilities and platform-specific behaviours.
This can be valuable when an application depends heavily on:
- advanced device features
- platform-specific performance
- specialized hardware
- deep operating-system integration
- sophisticated background processing
- demanding graphics
- platform-specific user experiences
But native development also means accepting the cost of platform-specific development.
If you need Android and iOS, you may need to account for both ecosystems.
5. Cross-Platform Apps Try to Share the Work
Cross-platform frameworks allow developers to build applications that target multiple platforms from a shared codebase or shared development model.
The goal is straightforward:
Build once where practical, deliver across multiple platforms.
This can reduce duplicated development work.
But “cross-platform” does not mean:
“Everything is identical everywhere.”
Different operating systems still have different:
- interfaces
- permissions
- lifecycle behaviours
- hardware
- APIs
- policies
- distribution systems
A cross-platform application therefore still requires platform awareness.
6. There Is No Free Abstraction
Every abstraction solves some problem and introduces others.
Consider the three broad approaches.
Web
Strength: broad reach and easy access through browsers.
Trade-off: constrained by browser and web-platform capabilities.
Native
Strength: deep platform integration and strong platform-specific control.
Trade-off: potentially more platform-specific development and maintenance.
Cross-platform
Strength: shared development across multiple platforms.
Trade-off: additional framework complexity and occasional platform-specific work.
The professional decision is not:
“Which one has no disadvantages?”
It is:
“Which trade-offs are acceptable for this product?”
7. Start With the User's Environment
Technology decisions should begin with the people who will actually use the product.
Ask:
What devices do they use?
- smartphones?
- tablets?
- laptops?
- desktop computers?
What operating systems?
- Android?
- iOS?
- Windows?
- macOS?
- Linux?
What connectivity?
- reliable broadband?
- mobile data?
- intermittent connectivity?
What hardware capabilities matter?
- camera?
- GPS?
- microphone?
- Bluetooth?
- sensors?
- local storage?
How often will they use the product?
- once?
- occasionally?
- several times a day?
How much friction can they tolerate?
A product used once to submit a form may not justify an app installation.
A product used every day may benefit from a more app-like experience.
8. Installation Has a Cost
Developers sometimes think:
“We'll just build an app.”
But asking someone to install an application introduces friction.
The user may need to:
- find the app
- download it
- wait for installation
- grant permissions
- create an account
- update it later
For some products, that friction is acceptable.
For others, it can prevent people from using the product at all.
Compare:
LINK → USE
with:
STORE → DOWNLOAD → INSTALL → OPEN → SIGN IN → USE
If your product's value can be delivered effectively through the browser, removing unnecessary friction can be a major advantage.
9. But Installation Can Also Create Value
Installation isn't automatically bad.
A frequently used application can benefit from being installed.
For example, users may want:
- an icon on their device
- quicker access
- notifications
- offline behaviour
- persistent sessions
- deeper device integration
The important question is:
Does installation create enough value to justify its friction?
That is a product decision, not merely a technical decision.
10. Connectivity Changes the Architecture
A product designed for reliable broadband can make different assumptions from one used on unstable connections.
Imagine a customer filling out a long order form.
The user has entered:
- service
- quantity
- specifications
- delivery information
Then the connection disappears.
If everything existed only in memory on the server, the user may lose their work.
A more resilient application could preserve appropriate information locally and synchronize it when connectivity returns.
This is one reason offline-capable or network-resilient designs can matter.
The broader principle is:
Application architecture should reflect the reliability of the environment in which the application operates.
11. Mobile-First Does Not Mean Mobile-Only
Designing for mobile first can be sensible when many users primarily interact through phones.
But that doesn't mean ignoring larger screens.
A good responsive application can adapt its interface to different environments.
Think:
SMALL SCREEN → MEDIUM SCREEN → LARGE SCREEN
Rather than:
“Build desktop and squeeze it onto a phone.”
Mobile-first thinking asks:
What is the most important information and action when space is limited?
That often produces a cleaner experience on every device.
12. Performance Is Part of Product Design
A technically powerful application can still provide a poor experience if it takes too long to become usable.
Performance can be affected by:
- application size
- images
- scripts
- network latency
- server response time
- database queries
- rendering complexity
- third-party services
For users on slower connections, unnecessary data can become especially expensive.
This means performance isn't merely a developer concern.
It affects:
- usability
- retention
- accessibility
- operating costs
- user trust
A useful principle is:
Don't make users download or process what they don't need.
13. Web and Native Can Share the Same Backend
Choosing a platform doesn't necessarily mean choosing an entirely separate system.
For example:
WEB APP
and
MOBILE APP
might both communicate with:
API → APPLICATION SERVICES → DATABASE
This is important.
The user interface can change without rebuilding the entire backend.
A product might therefore evolve from:
WEB → WEB + PWA → MOBILE APP
while keeping significant parts of the underlying application architecture.
The exact architecture depends on the product.
But this illustrates a powerful idea:
The interface is only one layer of the product.
14. Design the Backend Around Capabilities
Suppose your application supports:
- user accounts
- businesses
- orders
- payments
- notifications
The backend can expose capabilities around those domains.
For example:
IDENTITY
BUSINESS DIRECTORY
ORDER MANAGEMENT
PAYMENT PROCESSING
NOTIFICATIONS
Then different clients can consume those capabilities.
This reduces the temptation to build business logic independently into every interface.
Instead:
WEB
↓
API
↓
BUSINESS RULES
and:
MOBILE
↓
API
↓
BUSINESS RULES
The same underlying rules can then govern both experiences.
15. Don't Build Two Products by Accident
Suppose you build a web app and a mobile app.
The web version says:
Order status: In Production
The mobile version says:
Production Started
That may look harmless.
But if the two interfaces gradually develop different rules, you can end up with two competing versions of the product.
The problem isn't different wording.
The problem is duplicated business logic.
For example:
WEB
calculates delivery fees one way.
MOBILE
calculates them another way.
Now the same customer can receive different results.
A strong architecture centralizes important business rules where appropriate.
16. Device Capabilities Can Change the Decision
Ask what the product actually needs from the device.
Camera
A web application may be sufficient if users simply need occasional camera access.
A native or specialized solution may be more appropriate when advanced camera processing is central to the product.
Location
A browser can often access location with permission.
But the required behaviour may determine whether web capabilities are sufficient.
Notifications
Web and native platforms support notifications differently.
The product's notification requirements matter.
Bluetooth or specialized hardware
If the product needs deep hardware interaction, platform capabilities become more important.
The principle is:
Choose technology according to required capabilities, not fashion.
17. Think About Distribution
How will users discover the product?
A web application can generally be reached through:
URL → BROWSER → APPLICATION
A mobile application typically involves a distribution ecosystem.
That can affect:
- discovery
- installation
- updates
- permissions
- account requirements
- review processes
- platform policies
Distribution is therefore part of product architecture.
The product doesn't only need to function.
Users need a practical path to reach it.
18. Updates Work Differently Across Platforms
Web applications have a major operational advantage:
When the server-side application changes, users generally access the updated version through the web.
Installed applications have a different lifecycle.
A new version may need to be:
- built
- packaged
- distributed
- installed or updated
The details depend on the platform and deployment model.
This means the cost of maintaining the application can differ substantially depending on how it is delivered.
19. Choose Based on the Product's Core Risk
A useful decision technique is to identify the dominant risk.
If your biggest risk is:
“Users won't want to install anything.”
A web application may make sense.
If the biggest risk is:
“We need deep device integration.”
Native or platform-aware development may become more attractive.
If the biggest risk is:
“We need multiple platforms but have a small development team.”
Cross-platform approaches may be worth considering.
If the biggest risk is:
“Users have unreliable connectivity.”
Network resilience should become a major architectural concern.
If the biggest risk is:
“The workflow is complex and users need repeated daily access.”
A more app-like experience may become valuable.
The architecture should respond to the real constraint.
20. A Simple Decision Framework
When evaluating an application approach, score each candidate against:
Reach
How easily can users access it?
Device integration
How much hardware and operating-system access is required?
Performance
How demanding is the workload?
Connectivity
How well must it operate under poor or interrupted networks?
Distribution
How much friction can users tolerate?
Development capacity
How much can the team realistically build and maintain?
Maintenance
How difficult will updates be?
Cost
What development and operating costs can the project sustain?
Future growth
How likely is the product's platform requirement to change?
You don't need mathematical precision.
The framework simply forces you to make the decision based on the product rather than personal preference.
21. A Worked Example
Imagine a service marketplace where customers:
- discover providers
- view profiles
- request quotes
- upload files
- communicate with providers
- make payments
- track orders
Now compare approaches.
Responsive Web Application
Potential advantages:
- easy access
- shareable links
- no installation required
- broad device reach
- straightforward updates
Potential limitations:
- some device capabilities may be less convenient
- offline behaviour requires deliberate design
PWA
Potential advantages:
- web reach
- app-like experience
- installation options
- possible offline capabilities
- centralized web deployment
Potential limitations:
- platform/browser capability differences
- some native capabilities may remain unavailable or less integrated
Native Mobile Apps
Potential advantages:
- deep platform integration
- strong device capabilities
- platform-specific experiences
Potential limitations:
- greater development and maintenance effort across platforms
- installation and update friction
Cross-Platform Mobile
Potential advantages:
- shared development
- multiple mobile targets
- app-store distribution
Potential limitations:
- framework complexity
- platform-specific exceptions still exist
Which one wins?
There is no answer until we know the actual product requirements.
22. Start Small Without Building a Dead End
There is a difference between:
starting simple
and:
building something that cannot evolve.
A product might sensibly begin as a responsive web application.
If adoption proves strong and users need deeper device capabilities, a mobile application can later be introduced.
But that transition becomes easier if the underlying system already has:
- clear APIs
- separated business logic
- structured data
- authentication
- stable domain concepts
- reliable deployment
This gives us a useful strategy:
Keep the first delivery simple while protecting the important architectural boundaries.
23. Don't Build for Imaginary Scale
A common mistake is designing for millions of users before the product has its first hundred.
The team may introduce:
- many services
- complex infrastructure
- distributed systems
- elaborate caching
- multiple databases
- sophisticated orchestration
before discovering whether anyone actually wants the product.
This creates unnecessary cost and complexity.
A better principle is:
Design for today's real requirements while avoiding decisions that make tomorrow's reasonable growth unnecessarily difficult.
That is different from either extreme:
BUILD FOR MASSIVE SCALE NOW
or:
IGNORE THE FUTURE COMPLETELY
24. But Don't Ignore Irreversible Decisions
Some decisions are relatively easy to change later.
Others are expensive.
Changing:
- button text
is relatively easy.
Changing:
- an entire data model
- authentication architecture
- payment architecture
- core API contracts
- data ownership
- platform strategy
can be much harder.
Therefore, spend more design effort on decisions that are:
EXPENSIVE TO REVERSE
and less on decisions that are:
EASY TO CHANGE
This is a powerful product-development habit.
25. Think in Terms of Reversible and Irreversible Decisions
Before making a major technical choice, ask:
If this turns out to be wrong, how difficult will it be to change?
Reversible
- interface wording
- colors
- navigation labels
- some UI components
- certain implementation details
Moderately reversible
- frontend framework
- API structure
- database organization
Potentially expensive to reverse
- platform strategy
- data ownership
- core architecture
- authentication model
- payment architecture
- major external dependencies
The more expensive the decision, the more evidence you should gather before committing.
26. Product Architecture Should Protect User Value
Technical elegance isn't the final objective.
Suppose one architecture is beautiful but makes the product:
- slower
- harder to access
- expensive to operate
- difficult to maintain
while another is simpler and delivers the user's core outcome reliably.
The second may be the better product architecture.
This leads to a critical distinction:
Good architecture is not architecture that impresses developers.
It is architecture that supports the product's required outcomes responsibly.
27. Your Architecture Should Answer Five Questions
For almost any digital product, you should eventually be able to answer:
1. How do users reach it?
WEB / PWA / MOBILE / DESKTOP / OTHER
2. Where does the application logic live?
CLIENT / SERVER / SERVICES
3. Where does important data live?
DATABASE / STORAGE / OTHER SYSTEMS
4. How do components communicate?
APIs / EVENTS / NETWORK PROTOCOLS
5. How does the system operate reliably?
SECURITY + MONITORING + DEPLOYMENT + RECOVERY
If these questions have no clear answers, the product architecture is probably still immature.
28. A Practical Architecture Map
Take an app you want to build and draw:
USER
↓
DEVICE
↓
INTERFACE
↓
API
↓
APPLICATION LOGIC
↓
DATABASE / STORAGE
↓
HOSTING / INFRASTRUCTURE
Then add:
AUTHENTICATION
AUTHORIZATION
EXTERNAL SERVICES
MONITORING
BACKUPS / RECOVERY
Now ask:
Which parts must exist on day one?
Which parts can be added later?
Which parts represent the greatest risk?
Which parts would be expensive to replace?
This exercise can prevent a surprising amount of unnecessary complexity.
29. The Product Decision Comes Before the Technology Decision
When someone asks:
“Should I use Flutter, React Native, native Android, a PWA, or a web app?”
the question is incomplete.
First ask:
Who are the users?
What devices do they use?
What are they trying to accomplish?
How frequently do they use the product?
What device capabilities are essential?
What connectivity conditions exist?
What distribution friction is acceptable?
What can the development team realistically maintain?
What does the business actually need?
Only then does the framework question become meaningful.
30. The Economic Value of Choosing Well
Platform choice affects more than developer preference.
It can affect:
- development cost
- maintenance cost
- time to market
- user acquisition
- accessibility
- support requirements
- infrastructure costs
- update costs
- technical debt
- future expansion
A product that reaches customers efficiently can create more value.
A product that requires unnecessary development effort can consume capital before it proves its value.
A product that is technically impressive but inconvenient to use can lose customers.
So choosing an application platform is ultimately an economic decision supported by technical reasoning.
31. The Deeper Principle: Build the Delivery Layer Around the Problem
There is no universal:
“best app technology.”
There is only:
the most appropriate delivery architecture for this product under these conditions.
The mental model is:
USER NEED
↓
PRODUCT CAPABILITY
↓
DELIVERY EXPERIENCE
↓
PLATFORM
↓
APPLICATION ARCHITECTURE
↓
INFRASTRUCTURE
↓
OPERATIONS
The direction matters.
Don't begin at the bottom and force the problem to fit the technology.
Begin with the user and work downward.
32. What You Should Remember
When deciding what kind of application to build, don't ask:
“What technology is popular?”
Ask:
“What does the product need to do, who needs it, where will they use it, and what constraints must the system survive?”
Then evaluate:
WEB
PWA
NATIVE
CROSS-PLATFORM
DESKTOP
or a combination.
Choose the simplest approach that can deliver the required outcome reliably while leaving sensible room for future change.
The goal isn't to build the most sophisticated application.
The goal is to build the right application for the problem.
FROM “WHAT SHOULD WE BUILD?” TO “HOW SHOULD PEOPLE ACCESS IT?”
Digital product development becomes much clearer when you separate two questions:
What capabilities does the product need?
and:
What is the best way to deliver those capabilities to its users?
The first is a product question.
The second is an architecture question.
A web app, PWA, native application, or cross-platform application is simply a different way of delivering software capabilities.
The best choice depends on:
USERS + DEVICES + CAPABILITIES + CONNECTIVITY + DISTRIBUTION + DEVELOPMENT CAPACITY + MAINTENANCE + FUTURE NEEDS
That is the real decision framework.
And once you understand it, you stop choosing technologies because they are fashionable and start choosing them because they solve a real problem.
That is a much more valuable development skill.
READ. USE. SOLVE.
Image: LANSA
.png)
No comments:
Post a Comment