Web app development.

The dividing line runs not through design or budget but through what your users do: read, work, or use the device. People who read need a website. People who work need a web app. People who need the camera, sensors, reliable push notifications or offline operation cannot avoid a native app.

Website. Content is delivered, the same for every visitor. There is no sign-in, no roles, no state that persists beyond the visit. A contact form, a newsletter sign-up and a simple booking link do not change that. This is the territory we describe under web design prices, at CHF 3,000 to CHF 25,000.

Web app. As soon as there is a sign-in, different roles with different views, a database of its own and workflows across several steps, we call it a web app. Typical cases in Swiss SMEs: a customer portal showing orders, documents and invoices; an internal tool replacing a grown spreadsheet landscape; a booking or reservation system with rules of its own; a platform where two user groups meet.

Native app. An application installed from the App Store or Play Store and written in the language of the respective platform. It means two development streams, two review processes and continuous adaptation to new operating system versions — a multiple of the effort of a web app, which only a concrete reason can justify.

An example from our own work makes the boundary tangible: for a tax return provider in the Zurich area we built a system as a web app — package selection, sign-in, document upload and appointment booking in one flow. As a website it would not have been possible; a native app would have added nothing, because the service is used once a year on a laptop. Further projects are in our work.

You need a web app as soon as people regularly move data by hand that the system ought to be moving. That shows up in the same five patterns almost every time, and all five are observable — you do not have to answer a technology question, only watch a working day.

• An inbox is the operating system. Orders, status questions and documents run through email, and nobody knows without searching where a case currently stands.
• The same information is entered more than once. Once in the form, once in the spreadsheet, once in the accounting system. Every duplicate entry is a source of error and a place where numbers start to diverge.
• Customers ask for things they could see themselves. "How far along is my order?", "Could you send the invoice again?" — every one of those enquiries costs your time and argues for a portal.
• Rules live in one person’s head. Who may grant which discount, when an approval is needed, in which order things have to happen. That knowledge belongs in a system, not in a job description.
• Growth produces linear extra work. Twice the orders means twice the administration. This is precisely where software pays off, and nowhere else.

If none of these patterns applies, you do not need a web app but a better website — and there our premium websites serve you faster and more cheaply. If the bottleneck sits between the website and the sales conversation, a calculator or configurator is sometimes the much smaller solution with the larger effect.

We build web apps with React and Next.js on the front end, Node.js on the back end and PostgreSQL as the database — not because it is the newest combination but because it is widespread, documented and understood by many professionals. For an application meant to be with you for ten years, the availability of people who can keep working on it is the most important technical criterion.

The reasoning in detail, so you can check the choice rather than take it on trust. Next.js renders pages on the server — which is why the publicly accessible parts of a web app also appear in search engines and in AI answers, while pure browser applications stay invisible there. What sits behind that is explained in our glossary under Next.js and server-side rendering. PostgreSQL is a relational database with no licence cost and strict consistency rules — for business data, where a wrongly posted figure does real damage, that is the right trade-off. Node.js lets front end and back end be written in the same language, which in small teams reduces handovers and sources of error.

What we deliberately do not do is build a web app on a content management system. WordPress and similar systems are excellent at managing content and poor at domain logic, role models and transactions. What starts with a few plugins ends two years later as a system nobody dares to update. Where the sensible boundary between content management and application runs is set out in our article headless CMS versus WordPress.

One intermediate step deserves its own mention: the progressive web app. Technically it is a web app, but it can be placed on the home screen, starts without a browser bar and can work offline within limits. For many ventures that initially sound like a native app, that is the right answer — with one important caveat, which is in the next section.

A native app is worth it when push notifications, offline operation, device features or presence in the app store are core to your offering — in every other case you are buying double the effort for nothing in return. These four reasons hold up; the others rarely survive scrutiny.

• Push notifications as the central channel. The most important point and the one most often overlooked: on iPhones, web push only works once the application has been added to the home screen from Safari’s share menu and permission has been granted. There is no automatic install prompt; you have to guide users through it. Anyone who does not take that step is unreachable by push. With a native app the channel is reliably there from installation onwards.
• Genuine offline operation. A progressive web app can cache content, but a field team capturing data for hours without reception and syncing later is served more reliably by a native app.
• Deep device access. Bluetooth devices, background location, biometric unlocking, continuous sensor access: here the browser hits limits that differ from platform to platform.
• The app store is your distribution channel. If your customers look for your offering there, or you want to sell through store billing, the question is already settled.

Against the native app stand the follow-on costs that rarely appear in the first quote: two platforms, two review processes with waiting times, continuous adaptation to new operating system versions, and users who never install updates, so that you maintain old versions for years. A web app you update once, and at the next visit everyone is on the same version.

Our usual advice: start with a web app that works cleanly on mobile and can be installed as a progressive web app. Once usage has established itself and one of the four reasons demonstrably applies, the native app follows on a data model that has already been proven — instead of on an untested assumption.

Effort is driven by roles, interfaces and edge cases — not by the number of screens, and certainly not by the design. That is the most common misjudgement in first conversations: two applications with the same number of pages can differ in effort by a factor of five.

Roles and permissions. An application where everyone sees the same thing is a fraction of the work compared with one that has a role model, approval stages, deputising rules and an audit trail of who changed which value and when. Every additional role multiplies the cases that have to be built and tested.

Interfaces. Every connection to an existing system — ERP, accounting, warehouse, point of sale, payment provider — is its own small project with someone else’s documentation, someone else’s error messages and someone else’s maintenance windows. With two systems comes the further question of which one wins in a conflict.

Edge cases and states. The main workflow is built quickly. Partial cancellations, refunds, extensions, two people editing at once, and the sentence "we just handle that by hand" account for the larger share of the budget.

Data migration. Legacy data is rarely as clean as it looks in the meeting. Cleaning, mapping and several test runs regularly take more time than planned.

Legal requirements. Personal data, access logging, retention periods, a deletion policy and a register of service providers under the revised Data Protection Act create effort that is visible on no screen. Plan it in only after launch and you pay for it twice.

What barely drives the effort, by contrast: the number of users. A cleanly built web app for 20 people differs technically very little from one for 2,000. Only well beyond that, and with real-time requirements, does scaling become a subject of its own — and then we are talking about complex web solutions.

A prototype costs a fraction of the full project and answers the most expensive question first: whether what you have in mind actually works in daily use. We recommend one even when a full contract is already on the table — the smaller engagement now reliably produces the better project later.

The reason lies in the nature of software projects: the biggest cost driver is not poor programming but built functionality nobody later uses. A prototype with usable screens but no complete domain logic behind them exposes misunderstandings in weeks rather than months. It shows whether the imagined workflow matches the lived one, whether the order is right and which fields are missing — and it shows all of that on something you can touch, not in a concept document.

With us a prototype for idea validation starts at CHF 10,000 and is a genuine exit point: you can carry on building with us, take the result to another supplier, or drop the venture — the last of which is the most valuable outcome when the idea does not hold. The background is set out in full in our article on fast, affordable MVP development.

Only after the prototype can anyone quote seriously. Name a fixed price for an extensive system beforehand and you have either rounded up generously or will renegotiate in month three. Both cost more than the two to four weeks a tested foundation takes.

We work in four stages with an exit point after each: requirements, prototype, first production version, expansion in cycles. After every stage you hold a result that has value even without the next one — that is the core, everything else is detail.

In the requirements stage we talk to the people who will work with it daily, not only to management. The output is an ordered list of workflows, a rough data model and an honest split between "must exist at launch" and "can come later". The prototype makes that usable. The first production version contains sign-in and roles, the data model, the main workflow and one interface — no more, so that it goes into use quickly. Expansion follows in two- to three-week cycles at a fixed capacity, prioritised by what real operation reveals.

Two points we settle in writing before the contract starts, because they decide your freedom of action later. First, the rights in the source code written for you, including the right to modify it — in Switzerland those rights do not pass to the client automatically under a contract for services. Second, the credentials: code repository, database, hosting and domain run on your accounts, and we work on them as invited members. Both are explained in full on our page about custom software in Switzerland.

After launch comes operation: monitoring, backups with tested recovery, security and library updates, fault fixes. We bill that by effort or through a monthly allowance you split freely between upkeep and further development.

In four situations we advise against a web app — before a quote is written, not after. A project that starts for the wrong reasons costs both sides more than a cancelled first meeting.

• A suitable off-the-shelf product exists. For appointment booking, invoicing, time tracking, project management or an ordinary online shop, mature products exist for a few francs per person per month. Rebuild that and you pay a multiple for less functionality. The trade-off in detail is on our page about custom software.
• The process is not settled internally. When two departments describe differently how a case moves through the company, the software settles the question silently — and usually wrongly. Settle it first, then build.
• Nobody on your side is accountable. A web app needs a person with decision-making authority and genuinely available time. Without them the project drifts between cycles, however good the development is.
• The budget covers development only. An application with no funds for operation and upkeep is a security risk after two years and unchangeable after three. A subscription is then the more sensible decision.

And a self-assessment that belongs here: we are a small digital agency with our own development team. Our strength is applications with a clear cut — customer portals, internal tools, booking and configuration systems, platforms for two user groups. For ventures that occupy a team of twenty for two years, require certified industry standards or reach deep into an existing ERP, we are not the right partner. We say that in the first conversation, not in month four.