Before commissioning a web application or admin panel: 7 things that determine time and cost

The first question of businesses that want a web application or admin panel built is always the same: "How long will it take and how much will it cost?" I have been developing this kind of project for 12 years. Across fields from banking to payment systems, from e-commerce to cooperative management, what I have seen is this: what determines time and cost is less the choice of technology and more the answers to a few basic questions. In this article I go through those questions one by one. If you clarify them before asking for a quote, you will get a more accurate price and avoid surprises in the middle of the project.

1. How many screens and which user roles are there?

The number of screens best describes the size of a web application. Counting the list, detail, add and edit screens one by one solves half of the job. Next come user roles: administrator, operations team, customer, dealer... If each role has different screens and permissions, the job grows. For example, a payment institution system I developed had three separate panels, about 90 screens and more than 130 permission definitions. Between this scale and an internal tool with 15 screens, the difference is months.

2. Which systems will it integrate with?

Payment institutions, ERP and accounting software, SMS operators, e-invoicing, shipping companies... Each integration is a separate work item. If the other side's documentation is good and there is a test environment, the work moves fast. If the documentation is lacking or there is no test environment, the time gets longer. Before getting a quote, it helps a lot to prepare the list of systems to integrate with and their API documents, if any.

3. How critical is the data?

In applications that work with data involving money, stock or legal consequences, validation, audit logging and error scenarios take much more effort. In a financial system, calculating amounts correctly, being able to trace every transaction retroactively and never letting a wrong record into the data are at the center of the design. This safety net increases cost, but the price of its absence is much higher.

4. Is real-time updating needed?

Having screens update instantly when a transaction happens (live transaction tracking, notifications, operators working simultaneously) requires extra infrastructure. It is not needed on every screen. Deciding from the start on which screens it is really needed reduces both time and cost.

5. Is the design ready?

In a project with a ready Figma design, development starts directly. If there is no design, either a separate design phase is planned or a simple, consistent interface is built with a ready-made component library. For admin panels, the second way is often both fast and sufficient.

6. From scratch, or on top of an existing system?

If development will be done on top of an existing system, that code needs to be examined first. Sometimes the existing structure is in good shape and adding to it is the fastest way. Sometimes every new feature runs into old problems and cleanup is needed first. It is impossible to say this without seeing the code, so a short review phase is a good start.

7. Going live and afterwards

Server setup, automated deployment, backups, error monitoring and maintenance after the project ends are also part of the job. Be sure to ask whether these are in the quote.

So what are realistic timelines?

• A small internal tool or simple panel: a few weeks
• A mid-sized admin panel or web application: 2 to 4 months
• Multi-panel products with many integrations: between 6 months and 2 years

My recommendation is to split the work into phases. First, analysis and technical design are done, then a working version is delivered at the end of each phase. That way you control the budget and see early that the project is moving in the right direction. Tying the payment for each phase to the delivery of that phase builds trust for both sides.

What to prepare when asking for a quote

A short job description, a list of user roles, a rough list of screens or similar example applications, the systems to integrate with, and design files if any. A much more realistic time and price can be given to a request that comes with this information. If information is missing, that is fine too: answering these questions together in the first meeting and putting the scope in writing is one of the most valuable steps of a project. A written scope is the most solid way to make sure that you and the developer expect the same thing.