Custom web applications for the process that sets your business apart.
The system nobody sells off the shelf, written at one fixed price and handed over with its tests. The source code is yours on full payment.
Build custom software when the process is part of why customers choose you, or when every package leaves a workaround your team repeats by hand. Buy for payroll, email and standard accounting. We build the first kind.
Build where the process is yours alone.
Martin Fowler divides software into strategic and utility. Where the way you work is part of why customers pick you, the software has to fit you exactly. For a utility every business needs, buy the package and change your process to match it.
Three signs point to a build:
- The same data is typed into two or three systems, and somebody reconciles them at month end.
- A spreadsheet has become the system, and one person understands it.
- Staff or customers follow a process no package supports without a workaround repeated every day.
A package wins in three cases: it covers almost all of the work and the rest is habit, the process changes every quarter, or nobody can yet say what done looks like. The first call tells you which side you are on.
Systems with rules, records and people in them.
Each one is built so that someone other than us can maintain it.
Internal operations tools
The screen that replaces four spreadsheets and the person who understands them.
Your customers see their documents, invoices, requests and progress, and nobody else's.
Approval and workflow apps
A request moves through people with rules, deadlines and an audit trail.
Integrations and middleware
The service between two systems that were never designed to talk.
Software your own customers sign up to and use. We run four products of our own, ticketing and a booking desk among them.
Something half-built or abandoned, tested first, then finished, refactored or replaced.
A stack you can still maintain in three years.
Every dependency we add is one you will still be maintaining in three years, so we pick technology whose failure modes are well understood. Most systems run on Node.js with PostgreSQL or MariaDB. Accounting-shaped work goes on ERPNext and the Frappe framework, and pages stay plain server-rendered HTML unless a single-page app earns its weight. The proposal names the stack and gives the reason.
Lineupo, our ticketing product, shows the habit. It keeps each organiser's data apart inside PostgreSQL itself, with row-level security forced, so a query that forgets the tenant comes back empty.
Security starts with who may see which record.
Broken access control is entry A01 of the OWASP Top 10:2025, so we design against it first. Every route that returns a record asks whether this caller may see this record, and a figure a role may not see never leaves the server.
Input is validated where it enters. A check that guards money fails closed, and secrets live in a vault, away from the repository. New behaviour arrives with its own test, one that has been seen to fail on the real defect.
Every milestone, approval and invoice is visible as it lands.
They appear in your client portal on the day they happen. The full engagement is on how we work, and launch runs through our release gate.
| Step | What happens |
|---|---|
| 1. Scope and fixed price | Milestones and one total, signed in the browser. A change of scope becomes a numbered change order and waits for your written approval. |
| 2. Design and data model | The screens and the schema, agreed before there is code anyone is attached to. |
| 3. Build in milestones | Each milestone arrives working, for you to review. |
| 4. Test and harden | Automated tests, error paths, input validation and authorisation on every record route, each checked by trying to break it. |
| 5. Launch | It goes live beside the old version and takes over only once it passes its checks, and the old one stays ready to fall back on. |
| 6. Warranty, then care or handover | The warranty period, then Base Platform Care, the Premium Subscription or a clean handover, as you choose. |
Defects in our work are fixed free under warranty.
The warranty covers any defect in what we built, at no cost, for 12 months from acceptance while we host the system, up to 24 with the Premium Subscription, and for 90 days on your own servers. After that, stay on our plans, set out under managed hosting and support, or take the source code and run the system without us.
We build scoped systems for the browser.
Three kinds of work sit outside that.
- Native iOS and Android apps. A phone reaches our systems through its browser.
- Design-only projects. We are engineers who care about the interface, and brand identity belongs with a brand studio.
- Staff augmentation. Our engineers work on systems we scope, and are never placed inside your team.
Frequently asked questions
When should you build a custom web application, and when should you buy off-the-shelf software?
Build custom software when the process is part of why customers choose you, or when every package leaves a workaround your team repeats by hand. Buy for payroll, email and standard accounting. We build the first kind.
How much does custom software development cost?
One fixed total against a written scope, so the figure follows what the system has to do: its screens, records, integrations and roles. The first call and the proposal cost nothing, and the proposal states the total and the milestone schedule before you commit.
What stack will our web application be built on?
Usually Node.js on PostgreSQL or MariaDB, with ERPNext for accounting-shaped work and server-rendered HTML unless the interface needs a single-page app. The proposal names the stack and why, so any competent team could maintain it after us.
Do we receive the source code of our custom application?
Yes, for everything you have paid for, and you can ask for it at any time. Anything we brought to the project stays ours, and you hold a perpetual, royalty-free licence to use it within your system, as our commitments set out.
Do you build native mobile apps?
No. We build web applications that work well in a phone's browser. An app that must live in the App Store or Google Play needs a different studio, and you will hear that from us before any proposal.
What if the scope changes halfway through the build?
It becomes a numbered change order stating what changes, what it costs and which dates move, signed the same way as the contract. Nothing is absorbed quietly and argued over at the end.
How long does a custom web application take to build?
We give no duration before the scope is written. Once it is, every milestone carries a date in the signed proposal, and a wait on your side moves only the dates it touches.