The price of a custom application cannot be calculated responsibly from a short feature list alone. Two projects may both be called a CRM or booking system while requiring very different roles, business rules, integrations, security controls and volumes of data.
A useful estimate starts with the workflow the application must support: who uses it, what information enters the system, which decisions it makes, what it sends to other services and what must happen when an exception appears.
The objective is not to choose the cheapest number before the scope is understood. It is to build the smallest reliable version that solves the central problem and can be expanded without paying again for avoidable architectural mistakes.
Key ideas in this article
- Cost is driven by business rules, data, roles and integrations, not only by the number of screens.
- A focused first release is usually safer than an oversized application built from assumptions.
- Testing, security, deployment and data migration belong in the project budget.
- AI integration is an optional feature whose data, limits and human validation must be designed.
- Maintenance and future improvements should be discussed before development starts.
Why similar applications can have very different prices
A simple booking application with one location, one calendar and email confirmations is not the same product as a multi-location system with employee schedules, deposits, cancellation rules, SMS, invoicing and external calendar synchronization. The label is similar, but the underlying logic is not.
The same applies to CRM projects. A contact list with statuses is relatively compact. A CRM that imports historical records, assigns leads, controls access by team, creates documents, connects email and produces management reports contains many more decisions that must be designed, developed and tested.
Indicative ranges for common project types
For the services currently offered by Web Hat Solutions, a focused booking application can start around EUR 1,000-4,000, a custom CRM around EUR 1,500-5,000, a reporting dashboard around EUR 1,500-7,000 and an internal company application around EUR 2,000-10,000.
More complex products move into wider ranges: a niche SaaS platform may require EUR 5,000-25,000, a marketplace EUR 8,000-30,000, a simple mobile application EUR 3,000-10,000 and an advanced mobile application with payments, maps or chat EUR 10,000-40,000.
These are orientation ranges, not fixed quotations. The lower limit assumes a controlled scope and few exceptions. The upper limit reflects more roles, integrations, data migration, custom interfaces, security requirements and operational complexity.
The elements that change the development budget
Roles and permissions create both interface and security work. A customer, operator, manager, accountant and administrator rarely see the same information or perform the same actions. Each permission rule must be clear and testable.
Integrations can reduce manual work, but they also introduce external documentation, authentication, limits and failure scenarios. Payments, invoicing, email, WhatsApp, maps, existing CRM systems and third-party APIs must be evaluated individually.
- Number of user types, permissions and approval levels.
- Business rules, exceptions and calculations handled by the system.
- Data import, cleanup, deduplication and migration requirements.
- Payments, notifications, document generation and external APIs.
- Custom design, accessibility and the number of responsive interfaces.
- Security, audit logs, backup, privacy and regulatory constraints.
- Performance expectations, traffic, storage and reporting volume.
- AI integration, model costs, data boundaries and human validation.
A useful MVP is not an unfinished application
A minimum viable product should complete one important workflow reliably from start to finish. It may have fewer reports, fewer integrations or a simpler administration area, but the functions it includes must be usable, secure and testable.
The first release is valuable because it replaces assumptions with real usage. Once the team sees where people hesitate, which exceptions occur and which reports are actually needed, the second stage can be planned with better evidence.
Costs that continue after launch
Hosting, monitoring, backups, security updates, support and small compatibility changes are part of operating an application. Products that use paid APIs, SMS, email delivery, maps, cloud storage or AI models may also have usage-based provider costs.
Maintenance should not be confused with permanent redevelopment. It protects the live system and handles controlled corrections. New modules, major workflow changes and integrations are estimated separately because they change the product scope.
How a credible estimate is prepared
The estimating discussion should begin with the business result, current process and people involved. Screens are designed after the steps, decisions, data and exceptions are understood. This order prevents attractive interfaces from hiding incomplete logic.
A useful offer separates discovery, prototype, development, testing, launch and optional items. It also states assumptions, dependencies and what the client must provide, such as API access, existing data, legal texts or approval from another supplier.
Warning signs in a software offer
A very precise price offered before anyone asks about users, data and exceptions is usually based on hidden assumptions. The risk is not only a later price increase; the application may be built around a simplified process that does not match daily work.
- The offer lists technology but does not describe the business workflow.
- Testing, data migration, deployment and access control are absent.
- Every possible feature is included in the first release without priorities.
- AI is presented as a shortcut without data rules or human review.
- Ownership, source code access, hosting and post-launch support are unclear.
What to prepare before requesting a quotation
A short process description is more useful than a long wish list. Explain who performs the work today, what information is used, where time is lost, which errors repeat and what result the application should produce.
Include examples of current documents, spreadsheets or tools, identify mandatory integrations and separate essential functions from ideas that can wait. This gives the development team enough context to propose stages instead of guessing a single large scope.
A sound application budget is the result of a clear workflow, explicit assumptions and a first release that can be verified in real use.
