Custom Software Development and Enterprise Software Solutions

What is custom software development?

Custom software is an application designed and built around a company's own process rather than bought off the shelf. Screens, rules, approval steps and reports follow the way you work: the software fits the process, not the other way round.

That does not mean everything is written from scratch. On most projects the result is an application that sits on top of your existing systems and exchanges data with them: it reads what is held in the ERP and writes transactions created in the field or the office back to it.

What we build are browser-based enterprise applications, mobile business apps, integration services, approval and workflow systems, and management dashboards.

When do you need custom software?

The signs below indicate a process that can no longer be run on spreadsheets and email. If several of them apply to you, there is something concrete to talk about.

Typical situations where custom software comes up

• The same data is keyed again into different files and systems
• A critical operation runs in a spreadsheet only one person can update
• Approvals happen over email and cannot be found again afterwards
• An off-the-shelf product covers part of the process but not the exceptions
• A side operation outside the ERP is managed on its own
• Data from the field reaches the centre days later
• The same information in two systems drifts apart over time
• Users re-enter the same details across several screens

We check what is genuinely needed before building

If the requirement can be met by configuring your existing system or by an integration, we will not build something unnecessary, and we will tell you so plainly. Where a custom application is genuinely needed, we design it around how the process really works.

Making that distinction early makes the project both smaller and faster. On most projects the output of the first meeting is a list of which requirements are met by configuration and which need development.

Web-based enterprise applications

Where a process is a flow of people doing work in turn, its natural home is an application running in the browser. The user signs in with their own account, sees screens according to their role, creates a record, and that record moves to the next person.

When a purchase request is raised it goes to the responsible manager for approval, and the user follows the outcome from the same screen. Who approved what and when, which amount went to which level, and whether the request became an order are all on record.

Because nothing is installed, updates happen in one place and everyone works on the same version. Our web application development page covers this in detail.

Mobile business applications

Where part of the work does not happen at a desk, data capture has to move to where the work is. The field representative enters the order while standing with the customer, and nobody types it again at the office.

In the warehouse, goods receipt, picking and counting are done on a handheld terminal by scanning barcodes, and the stock movement is created at the moment of the transaction. The service engineer sees the work order in the field, records the parts used and the time spent, and takes the customer's signature on the device.

Where the connection is poor, the app has to hold data on the device and send it once connectivity returns. Our mobile app development page goes through these scenarios.

Integration with your ERP and existing systems

Most of what we build does not work in isolation. It reads item, price, stock and account data from the ERP and writes the resulting order, delivery or service record back as a document. Without that flow the same data is kept in two places and drifts apart.

On the SAP Business One side we make the connection through the service interfaces shipped with the product, so the ERP's own business rules stay in force. For other systems we use whatever API the other side offers; where there is none, the route to the data is designed separately.

What happens on failure is defined for every transfer: a failed record does not disappear quietly, it collects in a visible queue and it is clear who acts on it.

Workflow and process automation

Once repetitive work and approvals run on rules inside the system, the process stops depending on people remembering. When a document is saved the condition is checked, it goes for approval if required, and the next step starts on its own once approved.

The value of automation is not only speed but repeatability: in the same situation the system behaves the same way every time, and the process can be audited afterwards.

Reporting and management dashboards

The data an application produces only supports decisions when it is shown at the right level of detail. We build list screens for the operation and dashboards tracking selected indicators for management.

Our practical approach is to deliver the lists the operation needs in the first release, then build the dashboard once real data has accumulated, around the indicators people actually look at.

Roles, permissions and user management

Permissions are as much a process question as a security one: what each person can do defines the business rules of the application.

• Users signing in with their own accounts
• Role-based screen and document permissions
• Approval levels that change with amount or category thresholds
• Users seeing only their own region, warehouse or customers
• Single sign-on where a corporate identity platform exists
• Permission changes recorded

Security and audit trail

Security is not a feature added later: authentication, permission separation, input validation and audit logging are in scope from the start of the design.

• Authentication and session management
• Input validation and controls against unauthorised access
• Visibility of who created a record, and when
• Traceability of the stages a document passed through
• Data isolation in applications opened to outside users
• Defined backup and hosting arrangements

Maintenance and further development after go-live

The project does not end when the application goes live. Browser and operating system updates, version changes in the systems you integrate with and new requests from users all generate work over time.

After go-live we keep working with you on support, improvements and new requirements. Who responds, within what time and covering what is put in writing from the start.

What determines custom software development cost?

What drives the budget is not the screen count but scope, role structure, the number of integrations, the condition of your data and technical requirements such as offline working. Two projects known by the same name can be very different sizes.

We set out each of those items, and what to settle before asking for a quotation, in our custom software development cost guide.

Frequently asked questions