Technology · Software Development
Custom software development.
We build business applications, internal systems, portals and information solutions for processes where off-the-shelf software isn't enough. We can take a single module or the whole project, from architecture to support.
We fit the system to your process, not your process to the system.
When clients usually bring us in
- the existing system no longer keeps up
- the work happens in spreadsheets
- data is duplicated across systems
- you need a new application
- you want to modernise an old system
- you're building a new digital product
You don't always have to build from scratch
If the existing system can be properly modernised or connected to others, that's usually faster and cheaper than a new application. We start by looking at what's worth keeping.
The system stays yours
- source code
- technical documentation
- data model
- environment access
- deployment instructions
- user documentation
- team training
What this means for you
- Fewer spreadsheets and manual status updates.
- Less duplicated data across systems.
- One view of the process for management and the team.
- A system that grows with the company.
- Less dependence on the one person who knows how it works.
Problem → solution
What we develop
- internal business systems
- web applications
- admin systems
- user portals
- CRM modules
- booking systems
- platforms
- data systems
- APIs
- system integrations
When custom development makes sense
- you run several disconnected systems
- a lot of the work happens in spreadsheets
- data is duplicated and contradicts itself
- a standard CRM doesn't fit your process
- you need very specific user roles
- you're building a new digital product
- the existing system can no longer be extended
What the work includes
Frontend
Modern interfaces that stay fast and need no training.
- Component system
- Responsive and accessible
- Large data tables
- Real-time views
Backend
Business logic, APIs, databases and background processes.
- Data model
- Business rules
- Background jobs
- Performance at scale
Architecture
We design the system so it can grow and be extended.
- Modules and boundaries
- Environments
- Integration plan
- Documented technical decisions
Integrations
We connect existing systems so data isn't entered twice.
- ERP and CRM
- Payment systems
- Registries and external APIs
- File-based transfers
Security
Permissions, authentication, audit trails and data handling.
- Roles and permissions
- SSO and 2FA
- Audit log
- Encryption and retention
Testing
QA, regression, automated and manual testing.
- Real-world test scenarios
- Regression suite
- Acceptance testing
- Defect report
Deployment
Separate staging and production with controlled releases.
- CI/CD
- Data migrations
- Staged rollout
- Rollback
Maintenance
SLA, monitoring and continued development after handover.
- Response times
- Error monitoring
- Regular updates
- Roadmap
How a project runs
Analysis
Mapping the process, users and existing systems.
Specification
Features, roles, permissions and phases.
Prototype
A clickable prototype of the key screens before development.
Development
A working build on staging at the end of every phase.
Integrations
Connecting existing systems and migrating data.
Testing
Test scenarios, regression and acceptance testing.
Handover
Production, documentation, training, access.
Maintenance
SLA, monitoring and continued development.
Use cases
Replacing spreadsheets
A process that outgrew Excel gets a system with roles, history and reporting.
Multi-location system
Shared data with per-unit permissions and a management overview.
Partner portal
Orders, pricing and documents for external users.
The full development lifecycle
Building a business system is not just programming. Between the first conversation and the day the system takes over real work, a sequence of steps has to happen in the right order: understand the process, write down the requirements, define the architecture, design the experience, build, test, migrate the data, deploy, document and take it into maintenance.
We can take on the whole project or a single workstream. If the client has an in-house development team, we can cover only the analysis, the architecture, the mobile part, the integrations, QA or the rollout. On larger projects we appoint a project manager and agree responsibilities, deadlines, communication and reporting.
Business analysis
Objectives, users, process, business rules, exceptions, existing systems and data sources.
Requirements
Functional requirements state what the system must do; non-functional ones state under what conditions.
Architecture
Modules, system boundaries, data model, integration layer, environments and documented technical decisions.
UX/UI
Information architecture, user journeys, wireframes, prototype and design system.
Development
Frontend, backend, database, APIs, integrations, permissions, notifications and reporting.
QA
Test scenarios, manual and automated testing, regression, integration and performance testing.
Migration and rollout
Data migration, a trial rollout, acceptance testing and the move to production.
Handover
Documentation, access, knowledge transfer and an agreed maintenance model.
Business analysis before development
Most project failures do not start in the code; they start earlier, with a process nobody wrote down. So before development we map who does what, in what order, where the process stalls, where data is retyped by hand, and which rules actually apply - including the exceptions that never made it into the procedure.
The output is a document a non-technical reader can follow: the process, the user roles, the business rules, the list of systems to connect to, and the list of open questions. That document is the basis for the scope of work and for the acceptance criteria.
- the goal of the system and the measure by which the project will be judged
- user roles and what each of them may see and change
- the process step by step, including steps that today happen outside any system
- business rules and the exceptions to them
- existing systems that will stay in use and how to connect to them
- data sources, their condition and their owners
- constraints: security, legal, infrastructure and organisational
Functional and non-functional requirements
A functional requirement defines what the system has to do. A non-functional requirement defines the conditions under which it has to do it. Projects that capture only the first kind tend to get into trouble late - when it turns out the system works, but not fast enough, not for enough concurrent users, or not securely enough.
| Requirement type | What it defines | Example |
|---|---|---|
| Functional | what the system does | a user submits a request and it goes for approval |
| Performance | response time and behaviour under load | a large list opens without a wait |
| Availability | when the system has to be available | business hours, maintenance windows, behaviour during an outage |
| Security | who may do what and what is logged | role-based permissions, audit trail, retention |
| Accessibility | usability without a mouse and with screen readers | keyboard, contrast, field labels, focus |
| Maintainability | how easily the system can be changed | documentation, tests, separated environments |
We write non-functional requirements in measurable form once they are known. Where numbers are not known or agreed, we do not invent them - we set them together with the client before development, not after.
A typical business-system architecture
Most business systems share the same backbone. The user works in a web, mobile or portal interface; that talks to an API protected by authentication and permission checks; behind it sits the business logic that enforces the rules; data lives in the database and the document store; an integration layer handles the conversation with external systems; reporting reads from those sources.
| Layer | Responsibility |
|---|---|
| Interface | screens, forms, lists and views for each user role |
| API | the entry point into the system; authentication, permission and input checks |
| Business logic | rules, record states, workflows, approvals and calculations |
| Data | the data model, change history, documents and attachments |
| Integrations | exchange with ERP, CRM, DMS, registries and external services |
| Reporting | dashboards, KPIs, exports and scheduled reports |
| Observability | logs, metrics, error tracking and alerts |
Technical decisions follow the project
Not every project needs microservices, a mobile app, AI, a data warehouse or complex cloud infrastructure. We choose the architecture based on the number of users, the volume of data, the integrations, the security requirements, the expected growth and how the system will be maintained after go-live. Over-engineering a small system is as much a mistake as under-designing a large one.
| Decision | When the first option | When the second option |
|---|---|---|
| Single system or modules | smaller scope, one team, one release cycle | several independent domains, separate teams, different cycles |
| Cloud or on-premise | fluctuating load, fast environment setup | data-location requirements and existing infrastructure |
| Web or mobile app | desk work, complex forms and tables | field work, camera, scanning, location, offline use |
| Cross-platform or native | similar functionality on both platforms | tight coupling to hardware and platform features |
| Synchronous or asynchronous integration | the user needs an answer immediately | processing takes time or the external system is not always available |
| Central or distributed data | one source of truth, less synchronisation | systems with their own lifecycle and their own data |
| Build or integrate | the process is specific and is a competitive advantage | a proven system already covers the process |
What the scope of development can include
The list below is not a mandatory package. It is an overview of the workstreams a project can contain; what is actually in scope is decided after the analysis and written into the contracted scope.
Analysis and specification
Process mapping, functional and technical specification, and acceptance criteria for the important features.
UX/UI and prototype
Information architecture, wireframes, a clickable prototype and a design system the build then reuses.
Architecture and data model
Modules, system boundaries, the data model, the integration plan and documented technical decisions.
Frontend and backend
The user interface plus business logic, APIs, background processing and the database.
Mobile
A mobile app where field work is part of the process - with notifications, offline use or device hardware.
Integrations
Connections to ERP, CRM, DMS, registries, payment systems and other external services.
Authentication and permissions
Login, single sign-on, user roles, access rights and an audit trail.
Reporting
Dashboards, KPIs, scheduled reports and exports for further processing.
Data migration
Transfer from existing systems with cleaning, validation and reconciliation.
QA and acceptance testing
Test scenarios, regression, integration testing and user acceptance testing.
Rollout and environments
Development, test and production environments, controlled releases and the ability to roll back.
Documentation and handover
Technical and user documentation, transfer of access, training and an agreed maintenance model.
New system, extension or takeover
New system
We build from scratch. The advantage is that the architecture and data model are designed for the requirements you actually have; the cost is more time in analysis and in migrating data from the systems that stay.
Extending an existing system
We keep the existing core and extend it. First we review the code, the architecture, the dependencies and the state of the data, so we know what is worth keeping and what has to be replaced.
Takeover from another supplier
We take the system into maintenance and further development. We need access to the source code, the infrastructure, the database, third-party services and the documentation; the review produces findings, a risk list and a stabilisation plan.
Environments, releases and observability
Development, test and production environments are separate. We do not use real personal data in the test environment. Changes go through review and testing before they reach production, and for larger changes there is a way back to the previous version.
After go-live it matters that you can see what the system is doing: application logs, infrastructure metrics, error tracking, integration health and alerts. Without that, problems surface when a user reports them - usually too late.
QA, acceptance criteria and user testing
“Built” and “accepted” are not the same thing. For the important features we write down in advance what the input is, what the expected output is, how the system behaves in edge cases and under which conditions the feature is accepted. That removes most later arguments about whether something works correctly.
Testing follows written scenarios, manual and automated, including tests in CI/CD. Where required, QA can be run by a team separate from the developers. User acceptance testing is done by the client's key users, following scenarios from their everyday work; defects are logged, fixed and retested before sign-off.
- acceptance criteria for the important features
- functional and regression testing
- integration and API testing
- browser and device testing
- performance testing where it is a requirement
- a security review before go-live
- user acceptance testing and defect tracking
Security and personal data
Security is not a section at the end of the project. Authentication, user roles, least-privilege access, an audit trail, secret handling, dependency updates and backups are part of the design.
In systems that hold personal data, the purpose of processing, access rights, retention, export, deletion and the audit trail have to be decided at design time. This is not legal advice; the legal assessment is the client's, and we implement the agreed requirements technically.
- login, single sign-on and two-factor authentication where required
- user roles and least-privilege permissions
- an audit trail for changes to important records
- encryption in transit and at rest according to the agreed requirements
- separate handling of secrets and credentials
- regular security updates and dependency management
- backups and a restore that has actually been tested
A typical project team
The team is put together for the project; not every project includes all of the roles below. On a smaller system one person covers several of them; on a larger one the roles are separate and each has an owner.
Project manager
Owns scope, schedule, risk and client communication; makes sure decisions are written down and taken by the right person.
Business analyst
Translates the business process into requirements, rules and acceptance criteria that both the client and the developers understand.
Solution architect
Defines the architecture, the data model, the integration approach and the technical decisions, with the reasoning behind them.
UX/UI designer
Designs user journeys, screens and the design system so the work is fast even without training.
Frontend developer
Builds the interface, large data views, forms and real-time displays.
Backend developer
Builds the business logic, the APIs, the data model and background processing.
Mobile developer
Builds the mobile part when it is in scope - including notifications, offline use and device hardware.
QA engineer
Writes test scenarios, runs manual and automated testing and manages the defect log.
DevOps and cloud engineer
Sets up environments, releases, observability, backups and restore.
Data specialist
Covers migration, data quality, reporting and analytics when they are part of the project.
Security specialist
Reviews the architecture and access model and works on requirements for regulated environments.
For larger projects we extend the core Epix project structure with vetted specialist and partner delivery teams. Across the wider delivery network more than 190 professionals can be available; who is brought in depends on the required skills, technologies, scope, deadlines and the client's conditions. The client still works through one clearly defined project structure.
What we need from the client
A project moves faster when decision-makers and access are clear on the client side. A deadline does not depend on the development team alone: access, external integrations, third-party suppliers, approvals, the state of the data and changes in requirements all affect it.
- an owner who can take decisions on content and scope
- key users who actually run the process
- a list of existing systems that will stay in use
- existing documentation, even if it is incomplete
- access to the APIs and test environments of external systems
- sample data for testing and migration
- business rules and the exceptions that are not written down
What the client receives
- a working system in the production environment
- the source code under the agreed project model
- technical documentation: architecture, data model, integrations, environments
- deployment instructions and the release procedure
- user and administrator documentation
- test results and the defect log at handover
- access, secrets and details of third-party services
- a list of known limitations and open items
The source code and the data belong to the client; documentation, access and credentials are part of the handover. Licences, usage rights and access to individual components are set out in the contract according to the project model. The final list of deliverables is part of the contracted scope.
What usually goes wrong, and how we handle it
| Risk | How we handle it |
|---|---|
| unclear or unfinished requirements | analysis before development, written rules and acceptance criteria for the important features |
| an integration nobody mentioned until late | an inventory of systems and data flows during the analysis |
| poor data quality in the existing systems | an early trial migration, cleaning and reconciliation before the final cutover |
| no test scenarios and no clear approver | scenarios and a named approver agreed before development |
| no separate test environment | separate environments and no release before testing |
| outdated dependencies and security holes | dependency review and regular security updates |
| scope changes during delivery | a change request with an impact assessment on scope, timeline and dependencies |
| dependency on a single person | documentation, code review and more than one person who knows the system |
Maintenance after go-live
After go-live we can take on monitoring, defect fixing, technical and security updates and further development. The scope of support is agreed contractually; issues are classified by severity, and response times are set according to how critical the system is and what is agreed with the client.
| Class | What it means |
|---|---|
| 1 - outage | the system or a key part is down; highest priority |
| 2 - degradation | the system runs but a feature does not; handled at the agreed priority |
| 3 - defect | a minor defect with no business impact; goes into the next release |
| 4 - request | a change or an enhancement; we estimate the scope and agree a slot |
We do not publish universal response times, because they depend on how critical the system is and on the agreed level of support.
How we build the system
Architecture
We define the data model, modules and system boundaries before development, so later growth doesn't require a rewrite.
UX/UI
You approve the user journeys and a prototype of the key screens before any feature is written.
Frontend and backend
The interface and the server side are built to one standard: readable code covered by automated tests.
Integrations
Connections to ERP, CRM, document systems and registries, with logging and retries.
Data
Migration, cleanup and data quality rules, so the new system doesn't inherit the old errors.
Security, quality, rollout
Security
Authentication and permissions, encryption in transit and at rest, an audit trail and a review before go-live.
Testing
Automated tests, regression and acceptance testing against your criteria, not ours.
Deployment
Separate environments, phased release and the ability to roll back within minutes.
Handover
Code, access, documentation and team training. The system stays yours.
Maintenance
An agreed response time, monitoring and a monthly allocation for enhancements.
Related work
Technologies
Sub-pages
FAQ
How long does development take?
A smaller internal system typically 6-12 weeks, a complex platform several months. After discovery you get a phased timeline.
Can our own team take the system over?
Yes. Code, documentation and environments are yours; handover and training are part of the project.
What about migrating data from the old system?
Migration is part of the project: inventory, cleanup, a test run and the final cutover.
Related reading
Related solutions
Sounds like your project?
Send us the project description, your existing system, the tender documents or the event date.