Create
Custom software, when the process is genuinely yours.
Building software is the most expensive way to solve a business problem, and occasionally the only honest one. The useful work happens before any of it: deciding which parts of your process are genuinely distinctive, and which are a standard product you have not bought yet.
- Capability group
- Create
- What that group is for
- Build what your business needs
- Who it is for
- Operations, finance and technology owners running a core process in spreadsheets, email threads, or a tool that has been bent into a shape it was never meant for.
- Where it stops
- Bespoke applications, portals, operational platforms and product-like systems — things people log into to do work. A public site that people read is a website project; connecting tools you already pay for is an automation project.
The decision before the build
Most requests for custom software arrive as a solution. Someone wants a portal, a dashboard, an app. Underneath there is usually a process that grew without a system: a spreadsheet three people edit, a shared inbox that acts as a queue, a report someone assembles by hand every Monday. It works until volume, staff turnover or an audit finds it.
The question we start with is not what to build, but what is genuinely specific to your business. Approvals, pricing rules, scheduling constraints and compliance steps often are. User accounts, file storage, notifications and reporting almost never are. Building the second category from scratch is where custom software projects quietly go wrong — you end up maintaining a worse version of a product you could have configured.
Common signals
- A critical process runs in a spreadsheet that only one or two people fully understand.
- Staff re-key the same data into two or three systems that do not talk to each other.
- The monthly report is assembled by hand, and nobody entirely trusts it.
- An existing tool has been customised so heavily that upgrading it is now risky.
- Growth is limited by how many things a person can process in a day.
What we can help with
Scope is set by the process, not by a feature list. Several of these are frequently the whole engagement.
- Process and requirements work
- Mapping what actually happens today — including the undocumented exceptions people handle informally — and separating the parts that need building from the parts that need a decision or a product.
- Internal platforms and admin systems
- The system staff work in: records, states, permissions, queues and audit trails, designed so the process is visible rather than living in someone’s head.
- Customer-facing tools and portals
- Where your customers do something themselves — check status, submit information, book, order or manage an account — instead of emailing someone who then does it for them.
- Workflow and approval systems
- Multi-step processes with real-world complications: conditional routing, approvals, exceptions and the ability to correct a mistake without editing a database by hand.
- Dashboards and reporting
- Reporting built on the system that owns the data, so the numbers reconcile. We build these where the underlying data is trustworthy, and fix the data first where it is not.
- Integrations
- Connecting the platform to the tools you already run — CRM, accounting, messaging, payments — with explicit boundaries, so a change on either side does not silently break the other.
- Maintainability
- Typed code, automated checks, structured data and documentation, so the system can be handed to another developer without an archaeology phase.
How a platform project usually runs
Deliberately front-loaded on the decision, and deliberately staged so the first release is small enough to learn from.
Process mapping
What happens now, who does it, where it breaks, and what a better version would concretely look like. Includes the exceptions, which is usually where the complexity is hiding.
Build-or-configure decision
A written recommendation on what to build, what to buy and configure, and what to leave alone — with the reasoning, so it can be challenged rather than assumed.
System design
The data model, states, permissions and integration boundaries. Getting this right is what keeps the second year of the system cheaper than the first.
Staged build
The smallest genuinely useful version first, in real use, before the rest is built on assumptions about how it would be used.
Handover and support
Documentation, access, and an agreed arrangement for changes — because a system with no named owner degrades regardless of how well it was built.
Where it connects
A platform is rarely the whole answer. The same engagement usually touches automation — the routing, follow-up and reporting around the system — and sometimes the public site, where customers first arrive. Deciding those boundaries once, at the start, is cheaper than discovering them during integration.
If the honest answer is that an existing product configured properly would do the job, that is the recommendation you will get, even where it means a smaller engagement.
What to expect from us
- A written build-or-configure recommendation before anyone writes code.
- A first release small enough to be genuinely used and corrected.
- A documented data model and integration boundaries, not just a working screen.
- Plain language about what a system will cost to run, not only to build.
Related
Work that usually sits alongside this
Have a process that has outgrown its spreadsheet?
Describe what happens today and where it breaks. You will get a straight view on whether this needs building, configuring, or simply deciding.