SYS-04 · Business systems · Build
Custom software development
Web applications, internal tools and operational systems built around how the business actually runs. We research the problem before proposing a build, and we stay on after it ships.
The problem
Most software fails for reasons visible before it was written.
Custom software projects rarely fail on the code. They fail because the problem was defined by whoever commissioned it rather than whoever will use it, because scope was agreed before anyone understood the process, or because the thing was handed over with no plan for the day the person who understood it leaves.
The other common failure is building software for a process that should have been changed instead. Automating a bad workflow makes it permanent and harder to fix.
And a large share of what businesses ask us to build should not be built at all — an existing product does it, or a spreadsheet is genuinely fine. Saying so costs us a project and saves you a great deal more.
What we do
What we build, and how it is delivered.
Custom web applications
Internal tools, portals, dashboards and operational systems built for a specific job rather than adapted from a template.
Business process systems
Software that models a real workflow — approvals, scheduling, inventory, service operations — including the exceptions.
Client and partner portals
Where customers or partners see their own data, place requests and track progress without emailing someone.
System integration
Connecting the software you already run so data stops being re-typed between them.
APIs and webhooks
Documented interfaces so the system can be built on later, by us or by anyone else.
Data model and architecture
Designed before development. Data models are the expensive thing to change afterwards.
Documentation and handover
Written so a developer who has never met us can pick it up. This is the difference between an asset and a dependency.
Support and continued development
Software changes after launch because the business does. We plan for that rather than treating it as scope creep.
How we work
How a build is run.
Research
The problem, the current process, the people who will use it, and what we will deliberately not build. Scope with a boundary is scope you can hold.
Design
Architecture, data model, interfaces and a working prototype, so decisions are made against something real rather than a document.
Build
Delivered in stages you can see and use. Long silent development phases are where projects go wrong quietly.
Run
Deployment, monitoring, training and ongoing development. We operate what we build.
What it connects to
Software rarely stands alone.
Most builds touch at least one of these. Having them under one team is the point.
AI & automation
Where a manual step inside the system can be removed rather than digitised.
Learn moreSYS-04CRM development
The most common custom build, and usually the first one a business needs.
Learn moreSYS-01Website development
The public surface of the system, built by the same team that built the system.
Learn moreEvidence
What we can show, and what stays private.
Most custom software we build is internal, which means screenshots and client names are frequently confidential. Where that is the case we describe the problem and the architecture without identifying the client, rather than inventing a case study we cannot support.
Result — [ insert verified result ]
Questions
Common questions.
How do you price a custom build?
[CONTENT TO VERIFY — confirm pricing model, whether fixed-scope or time-based, before publishing.]
What we can say is that we do not quote before the research stage, because a number produced before the process is understood is a guess that someone eventually pays for.
What technologies do you build with?
Chosen for the problem rather than fashion, and biased toward boring, well-supported technology that another team could maintain. We will tell you what we plan to use and why before the build starts.
Will we be locked into working with you?
No, and the documentation is written specifically so you are not. Lock-in through obscurity is a business model we would rather not have.
Can you take over software someone else built?
Sometimes. It depends on the state of the code and whether documentation exists. We will review it and give you an honest read, including if the answer is that a rebuild would cost less than the rescue.
Do you build mobile apps?
[CONTENT TO VERIFY — confirm current native and cross-platform mobile capability before publishing.]
What if we are not sure we need custom software?
Then start with the research stage and nothing else. It is a small, bounded piece of work, and about a third of the time it concludes that an existing product or a process change solves the problem for far less money.
Not sure whether it should be built?
Describe what is breaking. We will tell you whether it is a software problem, a process problem, or something an existing product already solves.