Apps, Software, and SaaS — Lesson 1
Websites vs. Web Apps vs. Mobile Apps
Learning Objectives
- 1Distinguish between websites, web apps, mobile apps, and native apps.
- 2Determine when each type is appropriate for a business need.
- 3Recognize the cost and maintenance implications of each choice.
The fundamental distinction
A website primarily communicates — it explains, persuades, publishes, and presents. A web app lets users do work — create records, manage tasks, upload files, process orders, track progress, or interact with data. The distinction is not about technology but about purpose. A website is a brochure. An app is a tool.
This matters for planning because apps are significantly more complex to build, test, and maintain than websites. When a project evolves from "we need a website" to "we need users to log in and do things," the scope, budget, and timeline change substantially. Understanding this transition helps you plan realistically.
Many products blur the line. A blog with a comment system has app-like features. An e-commerce site with a shopping cart is a web app wrapped in a website. The useful question is not "is this a website or an app?" but "what does the user need to accomplish, and what must the system remember?"
The simplest test
If users primarily read and click, it is a website. If users create, edit, upload, or manage things, it is an app. If it requires login, it is almost certainly an app.
Web apps: software in a browser
A web app runs in a browser and does not need to be installed. Google Docs, Trello, Notion, Figma, and Slack (in a browser) are web apps. Users access them through a URL, and the software provider handles hosting, updates, and infrastructure.
Web apps are usually the right default choice for dashboards, portals, internal tools, client-facing platforms, and business workflows. They work on any device with a browser, require no app store approval, and can be updated instantly without users needing to install anything.
The limitation of web apps is that they cannot access all device features as deeply as native apps. Push notifications, offline functionality, camera integration, and background processing may be more limited in a browser. For most business applications, these limitations do not matter.
Mobile apps and native apps
A mobile app is software designed for phones and tablets, downloaded from an app store. A native app is built specifically for one platform (iOS or Android) using that platform programming tools. Native apps can access device features deeply and typically offer the smoothest user experience.
Building a native app for both iOS and Android means maintaining two separate codebases, which roughly doubles development and maintenance costs. Cross-platform frameworks like React Native and Flutter reduce this cost by sharing code across platforms, but they introduce their own tradeoffs in performance and capability.
Choose a mobile app when users need phone-specific features: push notifications, offline access, camera or GPS workflows, frequent on-the-go use, or when the app store presence itself has marketing value. For most business tools, a well-designed responsive web app is simpler, cheaper, and sufficient.
SaaS: renting software
SaaS means Software as a Service — software you access through a subscription rather than buying and hosting yourself. Salesforce, Mailchimp, QuickBooks Online, Slack, and Zoom are all SaaS products. You pay monthly or annually, and the provider handles hosting, security, updates, and infrastructure.
The advantages of SaaS are lower upfront cost, faster deployment, automatic updates, and someone else handling technical operations. The disadvantages are ongoing subscription costs that accumulate over time, dependency on the provider pricing and roadmap, potential difficulty exporting your data, and less customization than purpose-built software.
Before committing to a SaaS tool, ask: What happens to my data if I stop paying? Can I export everything? How often does pricing change? What if they remove a feature I depend on? These questions reveal vendor lock-in risk, which you will learn more about in Unit 10.
Case Study
The unnecessary app
Situation
A fitness studio spent $80,000 developing a native iOS and Android app for class booking. Six months after launch, analytics showed that 90% of bookings still came through the website. The app had 200 downloads, 40 active users, and required ongoing developer costs for platform updates.
Analysis
The studio confused wanting an app with needing an app. Their customers booked classes once or twice a week — not frequently enough to justify a dedicated app. A mobile-optimized website with an easy booking flow would have served the same purpose at a fraction of the cost.
Takeaway
Before building a mobile app, ask whether a mobile-friendly web app would solve the same problem. Apps require ongoing investment — make sure the usage pattern justifies it.
Reflection Questions
- 1. List the main software tools your organization uses daily. How many are web apps, how many are mobile apps, and how many are SaaS?
- 2. If you were starting a new project today, would you build a website, a web app, or a mobile app? What would drive that decision?
Key Takeaways
- ✓Websites communicate; apps let users do work. The distinction drives scope and cost.
- ✓Web apps are usually the right default for business tools — they work everywhere without installation.
- ✓Mobile apps are justified when users need phone-native features or very frequent on-the-go access.
- ✓SaaS trades upfront cost for ongoing dependency — always check data export before committing.