An app is not a small website. That is exactly why it works.

The most honest question to start with is whether you need an app at all. In the vast majority of conversations Plaincodelab has, the question behind the question turns out to be better solved with a good website or a web application. That is not modesty but arithmetic: an app costs more to build, more to maintain and asks your customer to install something. That barrier is higher than people think. Building an app for something that happens once a year means building an icon that gathers dust on the third page of a phone.

An app pays for itself through repetition. If someone uses your service weekly, if you want to send notifications that are genuinely read, if work has to happen offline or if you need access to camera, location, bluetooth or biometrics, it becomes interesting. A gym with members checking in four times a week, an installation company whose engineers fill in work orders in attics without signal, a wholesaler with reps taking orders on the road: those are situations where an app genuinely adds something a website cannot.

There is a third category that is often forgotten: the internal app. It is not in a store, not downloaded by consumers and needs no marketing. It replaces a stack of forms, a spreadsheet nobody understands any more or a package you pay for monthly that still does not do what you want. Internal apps are often the most profitable, because the gain is directly measurable in hours you no longer lose.

Plaincodelab therefore always starts with the question of what exactly has to happen, how often and by whom. Only when that is sharp does the choice of form follow. Sometimes that is an app, sometimes a web application with an icon on the home screen, sometimes an extension of the site you already have. In every case you get that reasoning explained before a single euro is spent on building.

There are four ways to build an app, and the difference between them determines your budget and what is possible later. They are often used interchangeably, agencies included, which produces quotes that cannot be compared. Below is what each form is, what it costs and where its limits lie.

Native means building two separate apps: one in Swift for iOS and one in Kotlin for Android. You get the best performance, the newest capabilities on the day Apple or Google ship them, and an app that feels exactly the way users of that platform expect. You pay for that with building twice and maintaining twice. For most business apps that is overkill; for apps built around heavy graphics, camera processing or complex animation it is the right choice.

Cross-platform means one codebase for both platforms, these days usually with React Native or Flutter. You ship two real apps in the stores, with access to camera, notifications, location and the rest, but you write the work once. In practice such a project shares eighty to ninety percent of its code; the rest is platform-specific. For the vast majority of commissions this is the sensible route, and it is what Plaincodelab builds most often.

A web app runs in the browser. No store, no installation, no approval from Apple. You send a link and everyone can start immediately, on any device. For internal use — planning, time tracking, records, dashboards — this is almost always the fastest and cheapest path. The limit lies at hardware access: some things a browser cannot do, or only halfway.

A PWA is a web app with a shell around it: it gets an icon on the home screen, can work offline and can send notifications. It is the compromise between reach and cost. On Android a PWA behaves almost like a real app; on iOS the capabilities are more limited, though that has improved in recent years. For a delivery service, a client portal or an internal tool a PWA is often enough.

Building an app is not a straight line from briefing to delivery. It is a series of decisions in which every step makes the next one cheaper or more expensive. Plaincodelab therefore works in short rounds with a working version at the end of each round, so you do not discover at the end of the project that something should have been done differently.

Step one is discovery. Who uses the app, how often, under which conditions and what happens now without one. That last part matters more than it sounds: the current way of working always contains exceptions nobody mentions spontaneously, but which the app has to handle. This step ends with a list of features, split into what the first version needs and what can wait.

Step two is design. Not pretty pictures but screens that hold up: which information sits where, what happens on an error, how it looks with real data instead of sample data. Plaincodelab delivers this as a clickable prototype so you can walk through it on your own phone before anything is built. Changes cost minutes here; later they cost days.

Step three is building the foundation: the data structure, the integrations with systems you already use, logins and permissions. This is the part you do not see and it determines whether the app can still be extended later. Cutting corners here is paid back with interest.

Step four is the app itself, screen by screen, with a version along the way that you can install on your own device. Step five is testing with real users in real conditions — an engineer on a roof, a colleague at the desk during rush hour. That is where the things emerge that you never think of behind a desk.

Step six is launch: submission to the App Store and Google Play, or rollout inside your own organisation. Both stores review an app before it appears; how long that takes differs per submission. Submission requires listing copy, screenshots and a privacy policy both stores demand.

App prices vary so widely that the word alone says little. An internal tool with three screens and one integration is a different project from a consumer app with accounts, payments, notifications and an admin. What drives the price is rarely the number of screens, but the number of rules: who may do what, what happens on an exception, and which systems it must talk to.

The relative order is predictable. A simple web app or PWA for internal use is the lightest form: no store process and one environment to maintain. A cross-platform app in both stores, with accounts, notifications and a link to an existing system, asks clearly more. Fully native, with two separate codebases, asks more again because the work doubles. What that means for a concrete plan is fixed before building starts — including what is and is not in that first version, so the bill does not quietly grow along the way.

What pushes the price up: payments inside the app, multiple user roles with different permissions, offline work with later synchronisation, integrations with systems that have no modern interface, and anything involving documents or signatures. What brings it down: starting with the core and deliberately postponing the rest, reusing components PCL has already built, and one clear decision-maker instead of three parties deciding together.

Also budget for fixed costs after launch. Apple charges periodically for a developer account, Google once. On top of that come hosting, monitoring and the maintenance required because operating systems keep changing. An app nobody maintains stops working at some point — that is not a threat but how the platforms operate.

How long an app takes depends entirely on what it has to do. Plaincodelab therefore quotes no averages and no standard terms: they say nothing about your project and create expectations that have to be corrected later. As soon as it is clear what is being built, the schedule is agreed together with the price — and that happens before anything is built, not along the way.

What sets the pace is almost never the programming itself. It is the decisions: approval of the design, supplying logo, copy and imagery, access to the systems that must be integrated, and creating the developer accounts in your company's name. In projects that overrun, the delay in most cases sits in that column and not in the code.

There is also a part of the process nobody controls: review by Apple and Google. How long that takes differs per submission and per period, and cannot be shortened by working harder. It is included in the schedule as a separate moment instead of being buried in the build time.

What shortens the project: starting with a smaller first version, appointing one decision-maker who settles questions, arranging test users in advance, and answering the question of who will manage the app right away. What lengthens it: features added during the build, integrations with parties that respond slowly, and copy or imagery that arrives at the last moment.

Plaincodelab therefore works with a schedule in two columns — what PCL does and what you do — so that from the start it is visible which step is waiting on whom. If something shifts in your column, you see immediately what that means, instead of it surfacing only at the end.

Technology is a means, not an end. The choice of framework must still be explainable to the next developer later on, and they must still be able to find people for it. Plaincodelab therefore deliberately picks tools with a large community around them and without quirks only one agency can maintain.

Which toolkit it becomes depends on what the app has to do. For most business apps a cross-platform setup with one codebase and real native components is enough, topped up with native code where the operating system demands it: a specific bluetooth link, a scanner that has to be fast, a background task that is policed strictly. If motion, imagery or performance is the point, fully native is the better choice. Plaincodelab settles that per project instead of pushing every project into the same shape.

Behind the app sits a backend: a database, a programming interface the app talks to, and an admin environment where you can change things without calling a developer. Which language and database sit underneath depends on what has to happen; a relational database is the obvious pick as soon as data has relationships. Where that runs is your own choice: for European companies a server inside the EU is the obvious one. Relational because business data has relationships — an order belongs to a customer, an invoice to an order — and you want the database to guard those relationships rather than good intentions.

It also comes with a test environment separate from the real one, a pipeline that automatically checks on every change whether everything still works, and remote error reporting so PCL knows before your customer calls. In a quote those things look like overhead. They are the difference between an app you dare to change and an app everyone is afraid of.

On a website someone decides within seconds whether to stay. With an app they decide at the third opening whether to keep it. That difference shapes how you design: not for the first impression, but for the tenth. A screen that impresses the first time and then costs two taps too many every day loses to a screen that looks dull and immediately does what you want.

Plaincodelab designs from the action that happens most often. It gets the biggest button, the shortest path and the most thumb-friendly place on the screen — at the bottom, where the hand already is, not at the top where designers like to put it. Everything that happens rarely may sit one tap deeper. That sounds obvious, but most apps are organised around the structure of the company rather than the day of the user.

The state the app is in matters too. An app is almost never neatly filled: there is no connection, the list is empty, loading takes a while, the input is wrong, the session has expired. Each of those situations deserves a screen that explains what is going on and what you can do now. This is exactly the part that gets skipped in cheap projects, and exactly the part where users drop out.

Accessibility belongs here. Sufficient contrast, text that scales when someone sets a larger system size, touch targets that are big enough, labels a screen reader can announce, and motion that switches off when someone has indicated in their settings that it bothers them. For public and semi-public organisations that is a legal requirement; for everyone else it is simply decent work, and it makes the app nicer for people without any impairment too.

PCL uses motion functionally: a transition that shows where a screen came from, a list that builds up neatly, a button that confirms the tap landed. Animation that only shows the builder can animate costs battery and attention. The rule is simple: if the motion can be removed without anyone missing anything, it should go.

An app that stands alone creates double work. The gain is in the integration: orders landing straight in your package, hours flowing onto the invoice by themselves, stock that is correct because there is one source of truth. In practically every Plaincodelab project the integration layer is the hardest part in substance — and the part that earns back the most time.

Payments usually run through Mollie, Stripe or Adyen, with iDEAL, credit card, Bancontact and pay-later as options. Important to know: if you sell digital things inside the app — a subscription, extra features, credit — Apple and Google in many cases require their own checkout, with the commission that comes with it. If you sell physical products or services delivered outside the app, you may simply use your own payment provider. Misjudging that line is one of the most common reasons for App Store rejection.

Beyond that PCL integrates with what already runs: accounting packages such as Exact, Moneybird or Twinfield, planning and time systems, stock and point-of-sale systems, CRMs, calendars, and the mail systems confirmations have to come from. Where a supplier has a modern interface that goes smoothly. Where it does not — and in smaller businesses that happens regularly — PCL builds an intermediate layer that absorbs the mess and passes it on cleanly, so the app stays tidy.

What the phone itself offers belongs on this list too: camera and scanning of barcodes or documents, location and routes, notifications, calendar, contacts, files, bluetooth for equipment, biometric login with face or finger, and offline storage with synchronisation as soon as there is signal again. For field work that last one is often the reason it becomes an app rather than a website.

Every integration comes with the question of what happens when the other side is down. An app that hangs because an external system does not answer is an app that breaks at the worst possible moment. PCL therefore always builds a safety net: retry, queue, and a clear message to the user instead of a spinner without end.

Building an app is half the work; getting it published is the other half. Apple reviews every app by hand before it appears in the App Store, Google does so largely automatically with spot checks. Both have guidelines that are not negotiable and that change regularly. Those who know them usually get through in one round; those who ignore them run into rejections.

The rejections Plaincodelab sees most often are always the same ones. An app that is really just a website in a shell, with no functionality of its own. A sign-up screen that is mandatory while the app would be useful without an account. A mandatory account without the option to delete that account inside the app — that last one has been a hard requirement for a few years. Digital purchases routed around the store's checkout. Asking permission for camera or location without explaining why. And incomplete or misleading listing copy and screenshots.

For submission itself you need more than the build: an icon in the right sizes, screenshots per device type, a short and a long description, keywords, an age rating, a privacy policy on a public page, and at Apple a completed privacy label stating per type of data what you collect and why. That label has to match what the app actually does; it is not marketing copy.

It is wise to distribute test versions first through TestFlight at Apple and the Google Play testing tracks. A small group of real users finds more in practice than a test department does. Only when nothing else comes out of that does the app go to public review.

And then there is the part people forget: the listing itself is discoverability. The name, the subtitle and the first lines decide whether someone searching the store comes across your app. That is a field of its own — App Store Optimisation — and it pays to think about it at submission rather than finding out afterwards.

An app sits closer to the user than a website. It lives on a personal device, often has access to camera and location, and can hold data while the device is offline. That makes privacy not a side issue but a design question from day one. GDPR calls that privacy by design, and in practice it comes down to one habit: do not collect anything you do not need.

Concretely that means a short list of agreements. Ask permission at the moment the feature is used and explain in one sentence why — not everything at once on first opening. Keep data on servers inside the EU. Encrypt traffic between app and server and encrypt sensitive data on the device itself as well. Never store passwords as text but as a hash with a modern algorithm. Log who saw what and when where personal data is involved. And agree how long data is kept, with a button to delete it.

Apps handling special categories — health, children, finance, biometrics — face a heavier regime: often a data protection impact assessment up front and stricter agreements with everyone involved. If you work with external parties such as a hosting provider or an analytics service, a processor agreement belongs with it. Those documents belong with the project rather than being thrown over the fence to you.

Security is the second track. Login with two-step verification where possible, sessions that expire, permissions fixed per role and checked on the server side — never only in the app, because anything on a device can be read out. Keys and passwords do not belong in app code; they live in a vault and are handled through the server. External components are updated periodically, because most leaks come not from your own code but from an outdated component nobody touched for years.

Finally: be honest in the store. Both stores ask you to declare which data you collect and whether you share it or use it to track people. A declaration that does not match is not just worth a rejection, it is a regulatory risk. The honest answer is usually more favourable than people think: apps that collect little score better with users who now pay attention to this.

The day an app appears in the store, the real work starts. Apple and Google regularly release a new version of their operating system, change their guidelines and switch off older ways of working. An app that does not keep up eventually drops out of the store or stops working on new devices. With apps, maintenance is therefore not a luxury but a condition for continued existence.

Maintenance should therefore be arranged up front and covers three things: keeping the platform and the components used up to date, watching whether everything runs, and resolving incidents within an agreed response time. Alongside that should sit a budget for further development, because an app that does not change turns by itself into an app nobody opens.

Measurement is inseparable from that, but done properly. Not sending every tap to an ad network, but knowing how many people complete an action, where they drop out and which screens load slowly. That is possible with privacy-friendly tools that work without a consent banner because no personal profiles are built. What you gain is direction: you know which screen needs attention instead of guessing.

Remote error reporting belongs with it: if the app crashes for someone, a report comes in automatically with the place in the code, the device type and the version. In practice that resolves half the complaints before anyone calls. The same goes for performance measurement — a screen that loads in half a second on a new device can take five seconds on a four-year-old phone, and you only notice that if you measure it.

Finally, release policy. Depending on the setup chosen, small improvements can be rolled out directly without a new review; larger changes go through the store again. Those moments are better planned in advance than afterwards under time pressure. And every version comes with a short note for users about what changed — almost nobody reads it, but it does save complaints from the people who do.

Plaincodelab builds three-dimensional work — this site is an example of it — but holds to one rule: 3D must explain something flat imagery cannot. A worktop projected into your own kitchen before you order, a machine you can inspect from every angle with its parts, a building you can walk through virtually: those are cases where a user understands faster and decides more confidently. A spinning sphere on the home screen is not.

In apps a product configurator is the most common worthwhile use. Colour, size, finish and accessories visible directly on the product itself, with the price moving along. That lowers doubt and therefore returns, and it saves conversations in which someone tries to explain how it will look. For companies with many variants that is often the part that pays for itself fastest.

Augmented reality — a virtual object in real space — works well for anything large, expensive or hard to imagine. Furniture, sun shading, installations, signs and lettering. Both iOS and Android now have a decent foundation for it, so a special device is no longer needed. It does hold that the heavier the rendering, the heavier the battery drain, so PCL always builds a simple view as a fallback.

On the web that runs on the 3D capabilities the browser itself offers, in apps on the layer the platform provides for it — or on an engine when it becomes genuinely game-like. Models are optimised before they reach the app: fewer faces, merged textures, and levels of detail so a phone does not have to draw what a workstation draws. Without that step 3D looks beautiful on the designer's laptop and stalls on the customer's device.

And then the fallback, which matters as much as the effect itself: every 3D element gets a variant without 3D. For old devices, for people who have switched off motion in their settings, and for the moments something goes wrong. The content must always remain reachable; the imagery is an addition, not a condition.

The word app covers too much ground, so below are the kinds that come up most often in practice. They differ greatly in size, but the question behind them is always the same: something that now happens on paper, in email or in a spreadsheet has to be faster and more reliable.

Field service apps are the classic. Engineers, installers, gardeners and cleaners receive their schedule, fill in a work order on site with photos and a signature, and that lands with administration automatically. Offline work is nearly always a requirement here, because basements and roof structures rarely have signal.

Customer and member apps are about repetition: checking in at a gym or club, booking and moving an appointment, tracking a pass or credit, notifications for new schedules. The gain lies in fewer phone calls and fewer no-shows.

Ordering and stock apps connect the floor to the system: scanning on arrival, taking orders at the customer, counting without paper. Here the app pays for itself in mistakes that are no longer made.

Beyond that PCL builds internal business apps that replace processes with no standard package, portals where clients see their own file, progress and documents, and public apps around a service or product — with accounts, payments and notifications. And regularly the most honest variant comes out of it: not an app, but a web application that does the same for a fraction of the budget.

In most companies the website and the app exist as two separate worlds, built by two parties, with the same data twice and never quite in sync. That is more expensive than it needs to be and it is why a customer sees something different in the app than on the site. Plaincodelab therefore prefers to build one system with two faces: the same data, the same rules, the same admin environment, and on top of that a website for people searching and an app for people returning.

Practically that means one place where products, prices, copy, opening hours and availability are maintained. If something changes, it changes everywhere at once. That saves not only mistakes but also the tiring discussion about who maintains which list. For a shop with stock, a club with schedules or a service business with calendars that is nearly always the decisive reason to design them together.

The division of roles then becomes logical too. The website exists to be found: it sits in Google, loads fast, explains what you do and moves visitors to contact or purchase. The app exists for people you already know: faster login, notifications, saved preferences, offline access. Mixing the two produces an app nobody finds and a website that is too slow because it wants too much.

There is an in-between form that is often overlooked and saves a lot of money: building the website so it can be installed as an app. Frequent visitors put it on their home screen, receive notifications and keep working offline, while you maintain only one thing. Only when something is genuinely needed that the browser cannot do does it become a store app. That is not the cheap solution; it is usually simply the right one.

Almost every app project that gets out of hand does so for the same reasons. They are listed below, not to scare anyone but because they are easy to avoid once you know them in advance.

The biggest is starting with everything. A first version with thirty features costs a lot and only produces information about what people actually use very late. Almost always it turns out afterwards that a third of those features were never touched. Start with the action that happens most often and build the rest based on what you then see.

The second is not thinking about who owns the data. Who manages the developer accounts, where does the code live, who holds the keys, and what happens when the collaboration ends? If the answer is 'the agency', you are stuck. Accounts belong in the client's name and the code should be delivered with documentation, so switching remains possible. That is not a special favour but how it should be.

The third is skipping the hard screens. Error messages, empty lists, expired sessions, failed payments, dropped connections. Nobody sees them in a demo; in real use they are half the experience. Adding them later costs more than designing them straight away.

The fourth is making an app without a plan to get users into it. An app in the store is not findable the way a website is in Google; people have to know it exists. Without a simple plan — a page on your site, a QR code at the desk, an email to existing customers, a reason to open it — it stops at a few dozen downloads.

And the fifth is not budgeting maintenance. Building is an investment, running is a subscription. Budget only the first item and in a year you face the choice of paying after all or stopping.

An app is not a shop on a busy square but a unit on a street nobody wanders into. For smaller businesses, downloads rarely come from the store itself; they come from your own channels. That is why the launch belongs in the design, not as a separate action afterwards.

The starting point is a page on your own website explaining what the app does, with buttons to both stores and a QR code that opens the right store directly on a phone. Alongside that: a message to existing customers, a QR code at the desk, on the invoice or on the receipt, and staff at the counter who can say one sentence about it. In practice that last one does more than all the advertising combined.

Different rules apply inside the store. The name and the subtitle weigh heavily in search, the first screenshot decides whether someone clicks through, and ratings decide whether they install. So ask for a rating at a good moment — not on first opening, but after someone has successfully completed something — and reply to reviews, including the critical ones. Those get read.

The real work starts at first opening. Anyone who immediately faces a registration form with ten fields is gone. Let the app do something useful first, ask only for what you need now, and explain permissions at the moment they come up. That first use decides whether someone returns.

Notifications are then your strongest instrument and simultaneously the fastest way to get deleted. The rule: only send what is relevant to that one person at that moment — your appointment is tomorrow, your order is on its way, your schedule has changed. No general newsletters as notifications. Let people choose per type what they want to receive, and track how many people actually open the app after a notification. If that drops, you are sending too much or the wrong thing.

An app is company property, not a subscription with the agency that happened to build it. Yet Plaincodelab regularly encounters situations in which an owner cannot access their own developer account, cannot see where the code lives and does not know which external services sit under the app. Switching is then not expensive but impossible, and the supplier knows it.

The agreement should be simple. The developer accounts at Apple and Google are in your company's name. The code sits in a repository you have access to and may take with you. The keys and certificates the app is signed with are yours and are stored safely, because whoever loses them can no longer publish a new version under the same app. Domains, hosting and external services are likewise in your own company's name, even when someone else does the day-to-day work.

Delivery comes with documentation: how to set up a development environment, how a new version is built and released, which external services are used and for what, where the data lives and what the data structure looks like. Not a hundred pages, but enough for another developer to continue without a handover meeting. That is the fairest test of a good handover: can somebody else take it over without calling you.

The same applies to the end of a collaboration. There should be no barrier holding you except satisfaction. In practice that also turns out to be the pleasantest way to work: if a client can leave at any moment, attention stays where it belongs — on the work.

Quotes for apps are full of words that are obvious to the builder and not to the client. That is unfortunate, because those very words determine what you get and what you can do later. Below are the terms that come up most often, in plain language, so you can put two quotes side by side and see where they genuinely differ.

One tip up front: for every term you do not know, ask what it means concretely for your project, not what it means in general. A supplier who cannot explain that in two sentences will not explain it during the project either. Plaincodelab therefore writes quotes in plain language, with the jargon in brackets behind it rather than the other way around.