Custom software development
Complex operations. One system built around them.
Complex work is not simplified by a handsome screen. It is simplified by knowing exactly who does what, when, with what authority — and what happens when a request is turned down. We start from that understanding, and we write it down before we build.
First sketch
- Requester
- Reviewer
- The record
- Who may approve?
- What if it is refused?
From the first discovery session
Project Book
Internal approval request
- Objectives
- User roles
- Permissions
- Workflows
- Data relationships
- Integrations
- Priorities
- Acceptance scenarios
Permissions
- The requester creates the request and attaches the document.
- The reviewer approves or returns the request for clarification.
- A requester may not approve their own request.
One request through the system Request 042
- Requester Submits the request with its document
- Reviewer Examines it within their authority
- Decision The request is approved
- Record The decision is stored with who made it and when
Or: returned for clarification
It goes back to the requester with a written reason, and the attempt stays in the record.
What the system resolves
The kind of complexity that earns a purpose-built system
-
Permissions that are not just “manager” and “staff”
Who sees which data, who approves what, and what changes when the person with the authority is away.
-
Interlocking data where one record depends on another
Changing one record has to be reflected correctly in what depends on it, not leave a silent contradiction.
-
Paths with real exceptions
The ordinary case is easy. A system is tested by refusals, returns, escalations and urgent cases.
-
Connections to systems you already run
Integration depends on what the other systems expose, and we establish what is available while scoping.
The Project Book
We write the system down before we build it
The Project Book is a planning document we work on with you. It turns what your team knows implicitly into written text that can be reviewed and argued with — before it becomes code that is expensive to change.
-
Discovery and first sketch
Clarifies who works the process, what the real steps are, and where it stalls today.
-
The Project Book
Clarifies objectives, roles, permissions, workflows, data relationships and acceptance scenarios.
-
Architecture and prototype
Clarifies what the screens look like and how the data is organised, before the logic behind them is built.
-
Phased implementation
Clarifies what becomes usable first, and what follows it.
-
Integration and scenario testing
Clarifies how the system behaves in the exceptional cases, not only the ideal one.
-
Rollout planning
Clarifies the order in which teams and data move onto the new system.
The Project Book is a working document produced within the project. It is not a file to download, and not a complete specification handed over before the scope is agreed.
The technical architecture
Each layer and what it is responsible for
-
Interfaces
- React
- Next.js
The day-to-day working screens: lists, records and forms that handle changing data without reloading the page.
-
Business logic and APIs
- PHP · Laravel
- Node.js · NestJS
The rules, the permissions and the approval paths — what actually happens after someone presses the button.
-
Data
- MySQL
- PostgreSQL 16
- MongoDB
The database is chosen to suit the shape of your information and its relationships, not a fixed preference.
Considerations we design for
- Permission boundaries between roles
- Data relationships and their integrity
- Work that runs in the background
- Maintainability and later change
- Behaviour when an external integration fails
Connected applications
Many systems need a web interface or a mobile app for staff or customers. We build those in the web and app development family and connect them to the same system.
Web & app developmentNot every project uses every technology. We pick what the requirements need and explain the choice before we start.
Application contexts
Project types this route suits
These are types of project that can be built this way. They are not a client list or a record of existing contracts.
- Government administrative workflows
- Education administration
- Internal approvals
- Booking operations
- Business-process automation
Every solution is quoted against its own scope, once we understand how you work and what you need.
Common questions
Questions before starting a project
How do we know our project genuinely needs a custom system?
We ask about the current process, who runs it, and what systems you use now. If we find a ready-made system covers your need with reasonable configuration, we say so — even though custom development is the larger piece of work for us.
What if our requirements are not clear yet?
That is the normal starting point. Discovery, the first sketch and then the Project Book exist precisely to turn what is implicit into something written. We do not need a finished specification to start the conversation.
Can the system connect to what we use today?
Usually yes, through an API, and it depends on what the other system exposes. We review what is actually available and establish what can be connected within the project scope before quoting.
Do we have to wait for the whole system before using any of it?
No. We implement in phases, ordered so the part with the most impact on your work becomes usable first and the rest is built on top of it.
Tell us about the process you want to put in order
Describe the current procedure, who uses it, what systems it touches, and whether a ready-made product has already been tried and did not fit. We will come back with the right route and a quote against the scope.