How long does a custom system take to build?

It depends entirely on scope. A focused internal tool is a much shorter engagement than a multi-role platform. We give a considered estimate only after discovery, and we would rather revise an estimate honestly than commit to a date we cannot support.

Who owns the source code?

You do. Ownership and repository access are written into the engagement agreement before development starts.

What happens after launch?

We can continue on a support arrangement covering fixes, small improvements and dependency updates, or hand the project over with documentation if you have an internal team.

Service

Custom Software Development

Off-the-shelf tools cover common needs well. They rarely cover the part of your operation that makes you different. We design and build software around your real workflow, so the people using it every day spend less time working around the system.

The problem

Situations this service addresses

If more than one of these sounds familiar, this is usually the right place to start.

Teams maintain critical processes in spreadsheets that only one person fully understands.
An existing internal system works, but nobody is willing to change it because it was never documented.
Different departments record the same information twice because the tools do not talk to each other.
Growth is limited by manual approvals, manual data entry and manual reporting.

Capabilities

What we can design, build and support

Internal business systems for operations, inventory, scheduling and approvals
Customer and partner portals with role-based access
Workflow applications that replace paper forms and email chains
API design and development for internal and partner use
Legacy modernisation, carried out in stages rather than in one risky rewrite
Ongoing maintenance, bug fixing and incremental improvement

Business value

What this work is intended to change

Written as intentions rather than promises. We do not quote guaranteed savings, revenue increases or delivery times we cannot support.

Less manual handling

Routine steps such as data entry, status updates and document generation can be automated so staff time moves toward work that needs judgement.

One reliable record

A single system of record reduces the disagreements that arise when three departments hold three versions of the same figure.

Room to change

Systems we build are documented and structured so that a future change is a planned task, not an emergency.

Typical deliverables

Discovery notes and an agreed scope document
Solution architecture and data model
Working application, deployed to an environment you control
API documentation where APIs are part of the build
Automated test coverage for critical paths
Handover documentation and a walkthrough session for your team

Security and quality considerations

Access control is designed at the start, not added once the system is live.
Input validation happens on the server as well as in the browser.
Sensitive fields are identified during discovery so storage and logging decisions are deliberate.
Critical business logic is covered by automated tests before release.

Technologies we commonly use

TypeScript
Node.js
React and Next.js
Python
PostgreSQL
MySQL
REST and GraphQL APIs
Docker

Delivery process

How the work runs

The same five stages apply across services. Depth varies with the size of the engagement; the sequence does not.

01
Discover
Understand the operation before proposing anything.
- Interviews with the people who perform the work daily
- Review of existing systems, data and integrations
- Constraints recorded honestly — budget, timeline, team capacity
02
Define
Turn findings into a scope that can be costed and agreed.
- Written requirements with clear boundaries
- Success criteria agreed before development begins
- Sequenced releases rather than one large delivery
03
Design
Shape the experience and the architecture together.
- Interface design reviewed with real users where possible
- Data model, integrations and access control designed up front
- Security and privacy decisions recorded as part of the design
04
Develop
Build in short iterations with something reviewable each time.
- Code review and automated testing on critical paths
- Regular demonstrations instead of a single reveal
- Documentation written alongside the code, not afterwards
05
Improve
Release, observe and refine based on real use.
- Monitoring and error reporting configured before launch
- Post-release review of what usage actually shows
- Planned maintenance for dependencies and security updates

Read the full delivery method

Questions