A custom web application is not priced by the number of screens - it is priced by the number of rules it has to know by heart. The question that lands in my inbox is usually some version of “what does a custom web application cost”, and it almost always arrives framed around appearance: how many pages, what kind of dashboard, whether there is a nice chart on the landing screen. What a custom web application costs is decided somewhere else entirely - in places no mockup ever shows. Who is allowed to approve a discount. What happens when the warehouse returns an error. How you correct a document issued yesterday. Those are hours of work, not screens.
Below I break it into specifics: what hides under the word “application”, what the realistic budget levels are, which features push the quote up hardest, and how to slice the project so you are not paying for everything at once. One caveat up front: I am not quoting anyone else’s price list here, because in this category there is no such thing as a market price - two applications with the same name can differ tenfold in the work they take.
Before any number comes up, it is worth settling what we are talking about, because that one word usually covers three different things.
The first is a portal for customers or trade partners bolted onto a site or store you already run: login, their own data, history, documents to download. The second is an internal tool your team uses instead of a spreadsheet - jobs, rotas, ticket flow, records. The third is a product in its own right, meant to be sold to other companies on a subscription, with sign-up, payments and many client accounts.
That distinction decides the order of magnitude more than anything else. A partner portal builds on what you already have. An internal tool has to be built around a process that currently lives in people’s heads. A product for sale also has to handle cases you will never see yourself, because someone else’s customers will bring them. If you are still weighing an application against a well-built website, I mapped that line separately in the piece on a mobile website versus an app for your business.
What a custom web application costs - three budget levels
In practice I meet three levels, and it helps to know which one you are standing on before you start collecting offers.
Level one - a module on a system you already run. You have WordPress or WooCommerce and you add login, custom fields, an order panel, document generation. You are not building an engine from scratch, you are adding logic to one. This is the cheapest sensible start, and that kind of scope usually fits inside my fixed-bid range of around 5,000-10,000 PLN net.
Level two - an application built around one process. Its own database, its own roles, an integration with one or two systems you already use. Here the figure follows directly from the feature list, and I always put it in writing before we start, itemised - so that something can be taken out if the budget does not close on the first pass.
Level three - a system the company runs on. Many roles, settlements, two-way integrations, change history, legal requirements. That is a project billed in stages, with each stage quoted separately, not one number handed over at the start. Honestly: if someone gives you a hard price for a system like that after one conversation, they have priced their own mental picture, not your process.
On top of that sits the choice of technology, which affects the developer’s rate - I compared the cost of work in one of the popular frameworks in the piece on what a Laravel developer costs.
What pushes the quote up hardest
Here is the list of things that make the biggest difference in my own quotes, most expensive first. None of them is visible on a mockup.
- Roles and permissions. One type of user is cheap. Four types, each seeing different data and each able to approve different things, is a separate layer to design, build and test. Every new role multiplies the number of cases to check.
- Integrations with other people’s systems. Stock, accounting, couriers, payment gateways, CRM. The cost comes not from the connection itself but from what happens when the other side does not answer, answers with an error, or answers late. An application that “usually works” is dramatically cheaper than one that never loses data - and that is a real choice, worth making deliberately.
- Exceptions to the rules. The most expensive sentence in any project is “well, almost always, but…”. The wholesale client on different terms from everyone else. The job that sometimes skips approval. Every exception has to be written into the code and kept from colliding with the rest.
- Data migration. Moving a few years of history out of spreadsheets and an old program can take longer than building the application itself. Company data is inconsistent, missing fields, full of typos in names and duplicates - and somebody has to clean it before the import.
- Documents and printouts. A quote, a job sheet, a label, a summary for the accountant. It always looks like a detail, and it always turns out the layout has to be exactly as it is today, because customers are used to it or the accountant insists.
- History and accountability. A record of who changed what and when, the ability to undo a change, a view of last month’s state. In companies where someone carries financial responsibility for an entry, that is not an extra, it is the foundation - but it is priced separately.
- Work in the field. An application used on a phone, on a shop floor or at a customer site where signal is patchy, is a different set of requirements from a panel used at a desk.
The rule I apply in every conversation: count the hours a month this task currently eats by hand. A feature that does not cut that time can comfortably wait for stage two.
The costs you only remember after launch
The build budget is not the whole bill. The recurring lines look like this:
- The server and running it - an application that calculates something on every click needs more than the cheapest shared account, plus backups you can genuinely restore from.
- Maintenance - with me that is Basic 1,000, Pro 2,000 and Premium 3,500 PLN net a month, depending on whether the system only has to run or also has to keep growing.
- Keeping integrations alive - the most common source of failures after a year. A supplier changes their interface version, your application stops talking to the warehouse, and somebody has to fix it within hours, not weeks.
- Changes after launch. The first weeks of real use always produce a list of fixes, because only then can you see what people actually do as opposed to what they said they do. Budget for it rather than pretending the project ends on go-live day.
- Work on your side - cleaning up data, filling in records, training the team. You cannot buy that, and without it the best system will simply display the mess it was meant to tidy.
How to bring the price down without gutting the project
The cheapest application is not the one with the shortest feature list, it is the one that starts narrow and grows on the strength of what users actually do. The order I recommend:
- One process, end to end. Pick the task that eats the most time today and handle all of it. One thing that works completely beats five things done halfway.
- One role to start with. Split the permissions once it is clear who really uses what.
- An import instead of a live integration in stage one. Uploading a file once a day is many times cheaper than a live connection, and it is often enough for the first few months.
- Off-the-shelf parts wherever you are not building an advantage. Login, sending email, payments, PDF generation - there is no sense writing those from scratch.
- Leave the styling for last. A clean, plain layout is enough to work in. Polishing the interface makes sense once you know which screens get used daily.
After each stage you have a working tool rather than a building site. If the budget runs out after stage two, what you are left with still does its job instead of being an abandoned investment.
An off-the-shelf tool or your own application
The cost question almost always has a second layer: is it worth building at all when there is a ready-made subscription tool on the market. The honest answer is that off-the-shelf wins everywhere your process is typical, and loses where your advantage rests on doing something differently from your competitors.
A practical test: write down five things you would have to work around in the ready-made program to be able to work in it at all. If the workarounds come down to changing habits, buy off the shelf. If they mean part of the team will keep a spreadsheet open on the side anyway, because the system cannot cope with your rules - price your own build. I ran the same calculation for wholesale selling in the piece on what a B2B system is, with its pros and cons, and the brackets for one specific trading-platform case in what a B2B platform costs.
How I quote it
I start with a free conversation about the process, not about features. I ask who does what today, where that data sits, and at which point things most often go missing. Out of that comes a list split into stages with a figure against each line - so you can see what costs what, and move something to later instead of negotiating one large number.
Fixed-bid projects usually land in the range of around 5,000-10,000 PLN net; on a wider scope the figure follows directly from the feature list. Always in writing and always before we start, so there is no situation where the cost grows mid-project without the scope changing. And if the conversation ends with the conclusion that your problem is solved by a ready-made tool at two hundred PLN a month, I will say so - I stand to lose one job, you stand to lose several months.
FAQ
How much does a simple web application for a small company cost? If “simple” means a portal with login, the customer’s own data and a few documents to download, added to a site or store you already have, that scope usually fits within around 5,000-10,000 PLN net plus server and maintenance costs. The number grows with the count of roles and integrations, not with the count of screens.
Is an application on WordPress cheaper than one written from scratch? At the start, usually yes, because a lot of it comes ready: accounts, permissions, an admin panel, sending email. The line is crossed where there is so much logic that you end up fighting the system instead of using it. For a tool people work in for hours every day, a custom build normally comes out cheaper over a few years.
How long does it take to build a web application? The first working stage is usually a matter of weeks rather than months - provided it is cut narrowly. The time sink is not the programming but agreeing the rules and cleaning up the data on your side, so the real timeline depends mostly on how fast decisions come back.
Do I get the code, and will the application be mine? It should be, and with me it is. After payment you get the code, the database and the full set of credentials, and the server sits on your own account. Ask that question in writing on any custom system offer, because the difference between “you have an application” and “you have access to someone else’s application” only surfaces on the day you want to change developers.
Building an application, a panel or an integration rather than a website? I write B2B systems to order - backends, APIs, client panels, billing modules. Tell me what it has to do and a quote with scope and a date comes back.