Custom Software Development
Off-the-shelf software is cheaper until the day your team starts keeping a spreadsheet beside it. Custom software is worth paying for when the way you work is the thing that makes you money, and no product fits it without bending.
We build business applications: order and job management, booking and scheduling, customer portals, internal tools that replace spreadsheets and email chains. Before writing code we will tell you if a product you can buy would do the job, because sometimes it would.
Signs you have outgrown bought software
Nobody commissions software for fun. These are the situations that usually bring people to us.
The spreadsheet that runs the company
One file, several tabs, a few people who understand it. It works until two of them edit at once or one of them leaves.
Paying for seats you cannot use
A large platform licensed for everyone, used for a tenth of what it does, and still missing the one screen you need.
Typing the same data twice
Orders entered in the shop, again in accounts, again in the warehouse system. Every re-typing is a delay and a chance of error.
A process nobody else has
Your pricing rules, approval chain or production flow is unusual, and it is the reason customers choose you.
An old system nobody dares touch
It still works, the person who wrote it has gone, and it runs on a server that should have been retired.
Customers asking for a login
They want to see their orders, documents or job status without ringing you. You want that too.
How a build runs
Four stages. You can stop after any of them and keep everything produced so far.
Discovery
We sit with the people who do the work, map the process as it is, and write down what the software must do. You receive a scope, a data model and a cost range.
First release
The smallest version that is useful to real users, not a demo. Built in two-week cycles, each ending with something you can click.
Roll-out
Data migration from the old system, user accounts, training notes, and a period of running both side by side if the risk warrants it.
Running it
Hosting, monitoring, backups and changes. With us on a retainer, or handed to your own team with the documentation to do it.
Stop after any stage and keep everything so far
Each stage ends with something you own outright. The next one is a separate decision.
- Discovery1–2 weeksYou keep: Scope, data model, cost range
- First releasetwo-week cyclesYou keep: Working software real users can use
- Roll-outplanned windowYou keep: Migrated data, accounts, training notes
- Running itmonth to monthYou keep: Hosting, monitoring, documentation
What discovery hands you
Discovery is a purchase in its own right. You can take its output to us, to another supplier, or shelve it.
- The current process as the people who run it describe it, including the workarounds
- Who uses the system and what each role may see and do
- Every system it must exchange data with, and what state that data is in
- The scope of a first release that real users could work in
- Who on your side accepts each release, and how acceptance is recorded
- The main risks and what we propose to do about each
- A cost range for the first release, with the assumptions written down
- A plain recommendation: build, buy a product, or wait
Illustrative example — not client work
A discovery decision example
In this fictional scenario, an order desk takes requests by email and tracks them in a shared workbook. Accounts uses a separate package. This sample turns those inputs into a proposed scope, rather than a promise to build everything.
Inputs and open questions
- Proposed decision owner
- Operations lead, with accounts reviewing the export.
- User roles to validate
- Request handler and approver, with different permissions.
- Unverified dependency
- Whether the accounts package accepts the required export.
Decision: prove one order flow first
Propose request entry, approval and status tracking, with a reviewed export to accounts. Keep invoicing and stock allocation outside the first release until their rules and integration access are confirmed.
Read the scope and acceptance excerpt
Proposed acceptance checks
- A request handler cannot approve their own request.
- Changing an approved request creates a new version for approval.
- An invalid export explains which records need attention and leaves the approved orders intact.
- Accounts can reconcile an agreed sample against the source orders.
Build, buy or defer
Test an existing product against these rules before choosing a build. If it fits and exports correctly, buying remains an option. If representative data or an accounts reviewer is unavailable, leave that decision open and record the dependency.
What you hold at the end
Everything below is yours. None of it depends on continuing to work with us.
- Source code in a repository under your account
- A written description of how the system works
- The database schema and a copy of your data
- Automated tests for the parts that handle money or stock
- Deployment scripts, so a release is one command
- Backup and restore procedure, tested once before hand-over
- Administrator and user guides in plain language
- A list of known limitations and what we would do next
What we build with
We choose boring, well-supported technology on purpose. You should be able to hire someone else to maintain it.
- Back end
- PHP / LaravelNode.jsPython / Django.NET
- Front end
- ReactVue.jsNext.jsTypeScript
- Mobile
- FlutterReact NativeKotlinSwift
- Data
- PostgreSQLMySQLRedis
- Operations
- DockerGitHub ActionsAWSAzure
What custom software costs
Our rates are published. Pick the role and move the sliders for an indicative budget.
Rate card
| Role | Hourly | Monthly* |
|---|---|---|
| Frontend / WordPress | $30 | $4,800 |
| Backend / API | $32 | $5,120 |
| Full-stack | $35 | $5,600 |
| Mobile (React Native / Flutter) | $35 | $5,600 |
| DevOps / Cloud | $40 | $6,400 |
| AI / Automation engineer | $45 | $7,200 |
| QA / Test engineer | $25 | $4,000 |
| UI / UX design | $28 | $4,480 |
*160 hrs/month full-time. Rates are indicative for planning, in USD (other currencies are converted at an indicative rate), and depend on seniority, contract length and timezone overlap. Longer engagements and multi-role teams are discounted — ask.
Should you build at all?
Building is reasonable when
- The process is specific to you and gives you an advantage.
- You have tried existing products and can say exactly where they fall short.
- Someone on your side can give a few hours a week to answer questions.
- You expect to keep changing the software as the business changes.
Buy a product instead when
- The need is standard: payroll, bookkeeping, email marketing.
- You need it live next month and a product exists today.
- Nobody in the business has time to be involved.
- The budget covers the build but not the years of upkeep after it.
Before you commit
Who decides what goes into each release?
You name one person as the product owner. They attend the fortnightly demo, accept or reject each release in writing, and settle questions of priority. We do not start a build without that person, because without them scope is decided by whoever shouted last.
Can you give a fixed price?
After discovery, yes, for a defined first release. Before discovery any fixed price is a guess with a safety margin added, and you pay for the margin.
How long does a first release take?
It depends on scope, which is why discovery comes first. We would rather give you a range we can defend than a date that sounds good.
What happens if we stop working with you?
You already hold the code, the data and the documentation. Another team can pick it up. We will hand over properly.
Can you take over software someone else built?
Yes. We begin by reading it and writing down how it works, then agree what to fix first. Expect the first weeks to be investigation rather than new features.
Where will it be hosted?
Wherever suits you: your own cloud account, your existing server, or an account we set up in your name. We do not host client systems under our own account.
Do you sign a confidentiality agreement?
Yes. Confidentiality and ownership terms are part of the agreement signed before discovery begins.
Describe the problem, not the solution
Tell us what your team does today and where it hurts. You do not need a specification. We reply within one business day.