How Does Custom Software Development Work?

When Does Custom Software Make Sense?

Off-the-shelf software is a good choice when your processes are standard and you do not need to change the way you work. Custom software is more suitable when you have specific rules, several teams, complex approval processes or data that is transferred manually between Excel, email, ERP and CRM.

One example is a system that connects an enquiry, site visit, quote, installation and warranty. Another is a dispatch panel with orders, a GPS map, drivers and invoices. In such processes, a ready-made program often covers only part of the needs, while the rest is managed with spreadsheets and phone calls.

The solution may be a web system accessible through a browser, a mobile app, an internal portal, a customer portal or a combination of these. When needed, the system connects to payment services, couriers, telephony, accounting software and other services through an API.

How Are the Goals and Requirements Defined?

First, the way the company currently works is documented. The team’s roles, documents, approvals, exceptions and points where information is lost are reviewed. It is important to see not only what the manager does, but also what the operator, sales representative, accountant or technician enters.

The next step is to define the system’s goal. It should be specific: all enquiries should be visible in one place, quotes should be tracked, invoices should be created from a confirmed order, or manual copying between two programs should be eliminated.

Requirements are divided into essential and desirable. Essential requirements go into the first version. Desirable ones are planned for a later stage if they are not needed for launch. This limits the risk of the project growing out of control.

At this stage, access rights, required reports, data migration, mobile access, backups, the login method and integrations are also defined. If the system will process personal or financial data, access requirements and an activity log are planned from the outset.

How Is a Custom Web System Planned?

Once the processes have been defined, the main screens and actions are described. For each role, it should be clear what the user can see, what they can create, what they can approve and which notifications they receive. This establishes the system logic before moving on to visual design.

For more complex projects, a prototype of the key workflows is created. For example, the sales representative creates a quote, the customer opens it, the manager approves it and the accountant receives the invoice data. The prototype makes it possible to discuss these steps with the people who will actually use the system.

The technical foundation is also planned: database, users and roles, API, files, notifications, logs, hosting and backups. For a public-facing system, load capacity, form security and behaviour in case of an error are also considered.

Development rarely needs to start with every possible feature. It is more sensible for the first version to cover the core process and be used by the team. Automations, additional reports and new integrations can be added based on feedback.

What Does the Development Process Involve?

1. 01
   Building the Foundation

   The database, users, roles, core settings and project structure are created. An environment is prepared where new features can be tested separately from the live system.

2. 02
   Developing the Core Processes

   The modules that deliver the most value are built: enquiries, customers, deals, tasks, inventory, schedules, documents or other components depending on the process. Each module is connected to the others rather than being an isolated screen.

3. 03
   Integrations and Automation

   API connections are added for payments, couriers, telephony, email, accounting or external catalogues. Repetitive actions such as creating an invoice, sending a notification or changing a status are automated.

4. 04
   Incremental Demonstrations

   A working part of the system is demonstrated, not just screenshots. This allows you to confirm whether the logic matches the way you actually work and to request changes before all modules have been built.

5. 05
   Preparing for Real-World Use

   Users, data, settings, access rights and instructions are checked. It is determined who on the team will monitor the system and who will approve future changes.

How Is the Software Tested Before Deployment?

Testing is not just checking whether a button can be clicked. The entire process is tested with realistic scenarios: creating a customer, changing a status, a declined order, a partial payment, a missing inventory item or a user without permission for a particular action.

Different roles, mobile devices, browsers, notifications, files and integrations are tested. When the system is changed, the parts that are already working are tested again. This reduces the risk of a new feature breaking an existing process.

Before launch, it is useful for key employees to work with the system in a test environment. They notice things that cannot be seen in a technical specification: a missing field, an unclear status or an unnecessary step in a daily task.

How does implementation work?

Implementation includes configuring the live environment, importing data, creating users and checking access permissions. If information is being transferred from Excel or an old system, duplicate, incomplete and incorrectly formatted records are cleaned up in advance.

A go-live date and a clear contingency plan are usually set. Depending on the risk, there may be a short period during which the old and new systems run in parallel. The team receives instructions and specific examples related to its work.

After launch, errors, slow operations and user questions are monitored. During this period, small adjustments are often made to fields, notifications, permissions and reports. This does not mean the project was poorly planned. Real-world use reveals details that cannot be fully seen in a desk-based demonstration.

What does post-development maintenance include?

Maintenance may include monitoring, backups, updates, bug fixes and small changes to the system. For a web application, the server, SSL certificate, access permissions and external integrations are monitored.

Maintenance is not the same as new development. Adding a new module, role or major integration is planned separately. For ongoing technical support, the guideline price is €100–€350 per month, while the exact amount depends on the number of systems, the required response time and the scope of the included activities.

It is a good idea to clarify from the outset who owns the code, database, access credentials and documentation. With custom software development, the system is built around your process, and these questions should be included in the proposal and terms.

How are the timeline and price determined?

The timeline depends on the number of modules, the complexity of the rules, integrations, data migration and the speed of feedback. A project with several roles and standard reports is planned differently from a platform with a mobile app, payments, geolocation and external API connections.

The price is determined after a discussion, a review of the processes and a description of the scope. For custom software, the guideline price is €3,000–€29,300. The lower end is possible with a limited scope and ready-made components, while the higher end is reached with more roles, complex business logic, integrations, a mobile component, migration and special security requirements.

The table is a guideline, not an automatic quote. It is important to clarify what is included: analysis, design, development, testing, data import, training, hosting, warranty period and maintenance. This allows you to compare actual scopes rather than just final prices.

What does a real project look like?

With LiftexPro – ERP for elevator companies, the system covers inspection scheduling, building management, a mobile app for technicians and automatic invoicing. This is a good example of why development starts with the entire workflow, not with a single screen.

In a system like this, different roles have different tasks. The dispatcher plans, the technician works in the field, the manager monitors progress, and accounting uses the data for invoicing. If these parts are not connected, the company will still have to re-enter information.

When the main problem is information scattered across different programs, API integrations and software connectivity are planned. When the system needs to manage inventory, sales and roles in one environment, a good starting point is a custom ERP system.

How should you prepare a development enquiry?

• Describe which process takes the most time or leads to errors.
• List the roles that will use the system and what each role needs to be able to do.
• Specify the programs, files and services the system needs to connect to.
• Give a real-life example from start to finish.
• Note which features are essential for the first version.
• Specify which data needs to be transferred and which reports are required.
• Request a proposal covering the scope, stages, timeline, acceptance terms and maintenance.

The clearer the process is described, the more meaningfully the project can be assessed. You do not need to know the technical terms. What matters is showing how the company operates and what needs to change.