What Business Web Application Development Includes

What a business web application is and why it needs a different approach than a website#

A business web application is not a website that merely displays information; it is a system that carries out business processes: user login, role and permission assignment, data processing, and connections to other systems in the company. Business web application development therefore requires a different approach than building a presentation website, since the solution must support simultaneous use by a larger number of employees, preserve a traceable history of changes, and ensure employees only access data they are authorized to see.

In midsize and large organizations, such an application is used by different groups: employees in production, finance, HR or procurement, as well as external partners, suppliers or customers. Each group needs a different set of functions and a different level of access, so roles must be defined at the start of the project. Without a clear division of permissions, one department often ends up seeing another department's data, which in practice creates a data security and compliance risk.

Deciding to build a business web application is therefore not only a technical question but an organizational one. It affects how departments share data with each other, who is responsible for which part of the system, and how the application fits into the existing environment, from ERP and CRM systems to reporting tools. That is why it makes sense to define scope, responsibilities and the way of working with the contractor before development begins.

How does business web application development proceed from analysis to launch?#

Business web application development proceeds through clearly separated phases: requirements analysis, architecture design, UX/UI design, development, testing and deployment to production. On larger projects, phases are not executed linearly in one pass but in work packages that can be planned, tested and accepted separately. This approach lets the client check along the way whether the solution matches actual business processes, before the entire application is built.

On larger projects a project manager is appointed who is responsible for coordination between teams, deadlines and communication with the client. This matters when a project touches several departments at once, since someone needs to track whether the requirements of finance, production or HR are aligned with each other. A project can be taken on in full, from analysis to support, or as a single work package, for example only UX/UI design or only integration with an existing system.

A special case is taking over an existing or unfinished system. Here, development starts with a review of the source code, architecture, infrastructure and data, and only then is it decided which parts are kept and which need to be rebuilt. Such a review also uncovers technical debt and security gaps that need to be addressed before new features are developed. This review is part of a responsible handover and only after it can the next steps of the project be reliably estimated.

• Requirements analysis and inventory of existing systems
• Architecture and data model design
• UX/UI design of user roles and screens
• Development delivered in agreed work packages
• Testing: manual, automated and acceptance testing
• Deployment to production and user training
• Support, maintenance and further development

Which existing systems need to connect to the new application#

A business web application rarely operates on its own. A company with more than a million euros in annual revenue typically already has a system for running the business (ERP), a system for managing customer relationships (CRM), and systems for storing and processing documents. The new application must exchange data with them through interfaces (API), so the analysis phase has to map out which systems exist, what their interfaces look like, and where duplication or data loss could occur.

Companies commonly use one of the established systems for running the business or managing customer relationships; choosing the specific system is the client's decision and is not part of this offering. More important than the system's name is what interfaces it offers, how often data refreshes, and who owns each data field. These answers need to be gathered before integration development starts, otherwise the risk shifts to a later phase of the project.

Every integration also raises a question of responsibility: who maintains the interface, what happens if the data structure in the existing system changes, and how transfer errors are detected. It makes sense to settle these questions in a support agreement before the application goes live, since integrations between systems often turn out to be the most sensitive part of the entire project. That is why integrations should be planned and tested separately from the rest of the development.

• Enterprise resource planning system (ERP)
• Customer relationship management system (CRM)
• Document storage and processing systems (DMS, ECM)
• Business reporting tools
• Production or warehouse systems
• HR systems and time-tracking records
• Payment or accounting systems

What UX/UI design covers for different user roles#

UX/UI design for a business application differs from designing a public website, because it must serve people with very different tasks and levels of digital skill. A production worker will use the application differently than a finance analyst or a procurement manager, so screens, menus and workflows are designed around the specific role, not an average user. A poorly designed interface more often leads to incorrectly entered data than to dissatisfaction with how it looks.

Part of the design work is defining which actions each role is allowed to perform: who can only view data, who may edit it, and who approves changes before they are published. This division matters especially in processes that affect finance, HR or production, where an incorrect entry or an unauthorized change has real business consequences. Roles and permissions are therefore defined together with department managers, not by the project team alone.

When the application is also used by field or production staff, the design needs to work on smaller screens and in environments without a reliable connection. Such cases call for simpler screens with fewer steps and clear feedback on whether data was saved successfully, since errors in that kind of environment are often noticed only once it is too late for a quick fix.

What development of a business web application includes#

Development covers everything from enterprise information systems and business applications to SaaS platforms, portals and administration systems, with individual parts built and connected to each other through interfaces (API). In this part of a project, Epix covers software development, API integrations, and automation of business processes, workflows, reporting and notifications, meaning manual tasks such as copying data between systems or manually compiling reports are replaced with automated steps.

When part of the process involves document processing, content search or decision support, AI is included in development too: agents, RAG, semantic search or data extraction from documents. These elements are not a separate project but part of the same application, which, for example, automatically suggests the next step to the user or extracts data from a received document instead of an employee entering it manually. This shortens document processing time without changing who is accountable for the result.

On projects that touch specific areas such as cloud, high availability or cybersecurity, Epix assembles a project team from its specialist partner network, which covers cloud and DevOps engineering, security architecture and mobile development. This way the team's composition adapts to the project's complexity, instead of the client having to find and coordinate several separate contractors for individual technical areas. The client gets the right people without having to put together multiple separate contracts.

• Enterprise information systems and business applications
• SaaS platforms
• ERP, CRM, DMS and ECM solutions
• Workflow and administration systems
• Portals for employees, partners or customers
• Marketplace and booking solutions

Security and separate environments for development, testing and production#

In business web application development, development, test and production environments are always kept separate, since a change pushed directly to production could disrupt a system employees rely on daily. Every change therefore goes through review and testing first, and only then is it released to the production environment. This separation matters especially for companies where downtime disrupts production, finance or customer communication.

The test environment never uses real personal data, which reduces the risk of test data ending up in the wrong hands or being processed outside the rules on personal data protection. This matters particularly for applications handling data about employees, customers or business partners, since the GDPR framework within which such data may be processed applies regardless of environment.

Security matters that need to be resolved before launch include role-based access control, change logging and regular security updates. For projects requiring in-depth security assessment, such as penetration testing or vulnerability management, Epix covers these tasks through its specialist partner network, since this is a separate area of expertise that complements the development team rather than replacing it, as the assessment needs to stay independent from the team that built the application.

How is testing carried out before release to production?#

Testing runs on several layers: manual checks against prepared scenarios, automated testing, and testing as part of the CI/CD process, before a change is released. The goal is to catch an error before a user does, and to verify a new feature does not break what already worked. For business applications that connect several systems, testing integrations is often where the most serious problems surface.

On more demanding projects, testing is carried out separately from the development team, since independent QA more easily spots a deviation a developer who wrote the code might overlook. Acceptance testing is carried out at the end of a work package, against criteria agreed during the analysis phase, so the client knows in advance exactly what is being checked and when a package can be considered complete. This avoids disputes about whether a part of the project is actually finished.

Testing is not a one-off step before launch; it repeats with every subsequent change. Regression testing checks whether a new feature affected existing parts of the application, while performance testing checks whether the system handles the expected number of concurrent users. Both matter especially for applications used daily by several departments at once. This kind of testing is part of ongoing maintenance, not a one-time event at launch.

• Test scenarios for each user role
• Manual testing of new features
• Automated testing (functional, API, regression)
• Testing within the CI/CD process
• Acceptance testing against pre-agreed criteria
• Independent QA, separate from the development team

What does support after launch of a business web application include?#

Support after launch includes monitoring operation, fixing errors, an SLA with agreed response times, technical and security updates, and further development of the application. The scope of support is set per project, since the needs of a company with sizeable revenue differ from those of a smaller organization. It matters that support is agreed before launch, not only once the first error appears, since that moment shows most clearly how clearly responsibilities were divided in advance.

Dividing issues into classes helps treat a full system outage differently from a minor cosmetic error. Response times for each class are agreed in the support contract based on how critical the application is to the business, since there is no universal response time that fits every company equally. For an application that production depends on, expectations differ from those for an internal tool used by just one group of employees.

Support after launch is not only about fixing errors but also further development: new features, adjustments to legislation, or a connection to an additional system the company introduces later. That is why it makes sense for the same contractor who built the application to also know its architecture and be able to make further changes without re-reviewing the entire system from scratch. This matters especially when legislation or the company's organization changes faster than anticipated at launch.

• Class 1 — outage: the system or a key part is down, treated with the highest priority
• Class 2 — disruption: the system works, a single function does not
• Class 3 — defect: a minor error with no business impact, scheduled into the next release
• Class 4 — request: a change or upgrade, scope and timing agreed separately

Who owns the code and data after the project ends#

Source code and data belong to the client, not the contractor. This applies whether Epix built the application from scratch or took over an existing system. At the end of a project or a work package, documentation, access and passwords are part of the handover, so the client is not dependent on a single contractor for every future change to the system. This arrangement applies regardless of the size of the project Epix takes on.

This matters especially for companies with sizeable annual revenue, where changing contractors, reorganizing the IT department, or moving to an in-house team is not an exception but a real possibility over an application's lifetime. A clear handover of code, data and documentation means such a transition does not stop business operations and that a new contractor can continue the work without rebuilding the system from scratch.

The same applies to unfinished or inherited systems: before development continues, the source code, architecture, infrastructure and data are reviewed so it is clear what is kept and what needs rebuilding. This review is part of a responsible project takeover and prevents further development being built on unverified foundations. This practice matters especially when the previous contractor is unreachable or documentation is incomplete.

How to choose a contractor for web application development, and what determines the price?#

When choosing a contractor, the most important thing is whether they can take on the project in full, from analysis to post-launch support, or only a single work package, such as integration or UX/UI design alone. Equally important is whether, on larger projects, the contractor appoints a project manager with clear team responsibilities and an agreed way of reporting, since this affects how the project unfolds when several departments are involved and sometimes conflicting requirements need to be reconciled.

We do not publish general price ranges for business web application development, because the price depends on the scope of functionality, the number of user roles, the amount and condition of data to migrate, security and compliance requirements, and whether it is a new system or a takeover and upgrade of an existing one. It is also affected by whether a mobile component is needed, the scope of AI features, and the agreed level of post-launch support.

Before estimating a price, we therefore propose a short analysis that breaks the project scope into work packages, so each one can be estimated and delivered separately. This gives the client a clearer picture of which part of the project is needed right away and which can follow later, instead of pricing the entire project before its scope is even precisely known. This avoids an estimate that ignores the actual complexity of each individual package.

• Scope of functionality and number of user roles
• How many existing systems need to be connected
• Whether it is a new system or a takeover of an existing one
• Amount and condition of data to be migrated
• Security, audit trail and compliance requirements
• Scope of testing and need for independent QA
• Level of support and agreed response times after launch