What is a Web App?

You almost certainly used three or four web apps before lunch. Your email is one. Your online banking is one. The system you send invoices from is one. None of them arrived on a disc, none of them needed installing, and none of them actually live on your computer. You opened a browser, typed an address, and the software was there.

A web app, short for web application, is software that runs inside a web browser rather than being installed on a device. MDN Web Docs, Mozilla's developer reference, describes web apps as applications built with web technologies and delivered through the browser, which does the running.

That plain definition has a consequence most business owners have never had spelled out. Your public website and the dashboard you run the business from are the same category of thing. Understanding that changes what you buy, who you buy it from, and how much of it you end up maintaining by hand.

Installed software and web apps

The difference is easiest to see side by side.

The practical wins sit in the second column. Nobody chases staff to install version 4.2. A laptop that dies does not take the customer list with it. Someone can check an order from a phone in a car park without anything being installed first. And because the records live in one database rather than scattered across machines, the business has a single version of the truth to work from.

Website or web app? The line is blurrier than it sounds

The traditional distinction is that a website shows you information and a web app lets you do something. A restaurant's opening hours page is a website. Your email is a web app.

That line has largely dissolved. A modern small business site takes bookings, processes payments, stores customer records, gates a members area, and sends automated follow-ups. It is doing things, continuously, on behalf of the business.

So the label matters less than a practical question: how much of your business actually runs through it? If the answer is a phone number and an address, you have a website and it should be cheap. If the answer includes money changing hands, stock levels moving, or customer data being stored, you have software, and it deserves to be treated as software when you budget for it, secure it, and plan who maintains it.

This is the gap that surprises buyers. They price a brochure site and commission a business system.

Front end, back end, and the database underneath

Every web app has three parts, and knowing the names makes vendor conversations much easier to follow.

The front end is what the customer sees and clicks in the browser. The back end is the code on the server that does the actual work when they click: checking stock, charging a card, saving a booking. The database is where the records are kept.

The front end and back end talk to each other constantly through an API, the request-and-response exchange we walk through in What is an API?.

The part worth your attention is the database, because it is where most small business pain actually originates. A typical setup grows by accident: a store on one platform, an email tool on another, a spreadsheet for stock, a separate system for invoices. Each of those is a web app, and each owns its own database. The store knows about orders. The email tool knows about subscribers. The spreadsheet knows about stock. None of them knows what the others know.

Somebody then keeps them in agreement by hand, and that person is usually the owner. Every extra subscription is another SaaS product holding its own copy of your customers, which is one of the reasons we weigh these decisions carefully in Build vs Buy.

The misconception that costs the most money

Here is the belief we correct most often. An owner decides they need software their team can use on a phone, and concludes they need a mobile app: a build for the App Store, another for Google Play, two review processes, and two sets of updates forever.

Usually they need a web app. It opens in the phone's browser, runs on both platforms from a single codebase, updates the instant it is deployed, and never queues for anyone's approval. For most small business needs, an internal dashboard, a booking system, a store, a job tracker, that is the whole requirement met at a fraction of the cost.

A web app can go further than a browser tab, too. Add a few standard capabilities and it can be saved to a phone's home screen, open full screen without browser furniture, and keep working through a patchy connection. That version has a name, a progressive web app, and it is worth asking about before anyone quotes you for two native builds.

The genuine reasons to build native are narrower than most people assume: heavy use of device hardware, serious offline requirements, or distribution through an app store as a deliberate sales channel. If none of those apply, a web app is very likely the answer.

Do this now: audit what you already run in a browser

This takes about fifteen minutes and tells you more about your software costs than any vendor will.

• 1.List every piece of software your business used this week, including the ones you barely think about.
• 2.Mark the ones that opened in a browser. Those are all web apps, and there will be more than you expect.
• 3.For each, write down where its records live and whether anything else in your business can read them.
• 4.Circle every pair you personally keep in agreement by copying, exporting, or retyping. Each circle is an integration that does not exist yet.
• 5.Add up the monthly subscriptions attached to the list.

Two numbers usually surprise people: how many separate databases hold a version of the same customer, and what the combined subscriptions come to over a year. Both are arguments you can now make with evidence rather than a feeling.

How we think about web apps at Enki

We treat the public site and the internal system as one build rather than two purchases. Custom Web Apps covers both halves on one codebase and one database, and every web app added afterwards connects to that same database rather than starting another island.

Our eCom Store and Dashboard build for a Melbourne experimental glass studio is this idea in practice. The storefront customers browse and the dashboard the studio runs on are one web app sharing one set of records, so an order placed on the site is already sitting in the system that prints the postage label and already counted against stock. That removed more than eight hours of weekly admin, not by making anyone work faster, but by deleting the step where a person carried information between screens.

None of this requires understanding how any of it is built. It requires knowing that the website and the business system were never two different species, and asking for them accordingly.