Loading
Product line
An internal system built around your actual workflow, its approvals and its exceptions — with an audit trail, real roles, and the handover documentation written while the work happens.
Internal system · in the build
Anatomy
Internal software is mostly a state machine and an answer to "who may change this". The screens follow from those two; they do not lead.
Followed end to end with the people who perform it, not only the people who manage it, with every exception someone mentions recorded. The exceptions are where estimates go wrong and where packages fail, so they are captured first.
The entities, the states they move through, the gates between those states and who holds each gate. Drawn as one diagram everybody can argue with before it becomes software, because arguing about a diagram is cheap.
Capability-based roles rather than job titles, enforced on the server, with an append-only record of every change: who, when, from what to what. This is what makes the system usable as evidence rather than only as a tool.
Where it reads from and writes to your ERP, accounting package, spreadsheets or machines — through a stable contract of our own rather than by pointing at somebody else's database and hoping the schema holds.
Why it matters
The same artefact described above, read as outcomes rather than as engineering. Each one follows directly from a decision already explained on this page.
Modelling the override, the rush job and the correction as approved, first-class actions removes the silent edits that make month-end numbers impossible to trust.
Approval gates checked on the server, not assumed from the interface, mean a stage genuinely can't be skipped, whatever a form on screen appears to allow.
Rolling out to one team or line first gets the issues that group finds fixed before a hundred more people hit the same one, instead of an unmanageable support queue.
Encoding the process as it is actually performed, exceptions included, replaces the spreadsheet three people maintain three different ways with one system everyone trusts.
Documentation written during the build, not summarised from memory afterwards, turns a handover into an actual handover rather than a hostage situation.
Key features
Behaviour of the built thing, not a list of adjectives. Every entry below is something you can check after delivery.
Custom software exists for the part of your operation that a package gets wrong. Not the whole operation — the part. The artefact is an internal system that encodes a real process including its exceptions, records who did what, and replaces the spreadsheet that three people maintain differently. If a package covers ninety per cent and the remaining ten per cent is not what makes you money, we will tell you to buy the package.
Technology
A stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Runs on
Before we quote
We would rather lose a project on this question than win one that should not have been built.
If a package covers ninety per cent and the missing ten per cent is not what makes you money, buy the package and integrate it — that is usually the cheaper and more durable answer. If the missing ten per cent is the actual business, a package will force you to change how you operate to suit software, and that cost is real but invisible on an invoice. We say which of the two we think applies, including when it costs us the work.
Not all of them. Some of what makes your process unusual is genuine competitive advantage and should be built properly. Some of it is an accident of who did the job in 2014 and should be removed rather than preserved in code. Separating the two is part of walking the process, and it is the single largest lever on the size of the build.
Rarely all of them, and rarely at once. The spreadsheet that three people maintain differently is the first target because it is where the factual disputes come from. A spreadsheet one analyst uses for their own working is often fine to leave alone. We name which ones the system is replacing so nobody discovers the answer during rollout.
Pricing and engagement
There is no fixed price for custom software because the scope varies by how many exceptions the real process turns out to have — here is how the work is actually engaged, and which of these usually fits this product line.
For work where the requirements are genuinely settled. A written scope, a phased plan and a price we hold. Best for a defined build, a migration, a security engagement or a design phase.
Named engineers at a monthly rate, working on your board and in your repository. The right shape when the roadmap is still moving, which is most products after their first release.
Ongoing maintenance, monitoring response, dependency updates and a block of hours for changes, under a written arrangement agreed before launch rather than during an incident.
Where it is used
Sectors where we are asked for this artefact most often. It is a statement about the fit of the shape, not a client list.
How the work is run
This page describes the artefact. Scope, delivery model and engagement terms live on the service pages, which is where they belong — follow whichever applies rather than reading it twice.
Questions
The honest answer depends on the number of exceptions in the process and the state of the data you already hold, which is why we walk the process before quoting rather than after. What we will commit to is that the core transaction path is working software on real data early, not a demonstration at the end — so you can judge progress by using it rather than by reading a status report.
It is normal, and discovering it is part of the work rather than a blocker. We follow one real case end to end with the people who perform it and write down what actually happens, including the steps that only one person knows. That document is frequently the most valuable early deliverable, because it is useful even if you never build the software.
Usually, and that is more often the job than a clean replacement. The practical question is what the ERP exposes: a documented API, a supported database view, a scheduled file exchange, or nothing usable. That answer sets both the cost and the fragility of the integration, so it is one of the first things we check. Where nothing is exposed we say so rather than building something that breaks on their next upgrade.
That is a supported outcome, not a failure. The repository, the infrastructure definitions and the documentation are yours throughout, the stack is deliberately mainstream so you can hire for it, and we will run a handover with your engineers rather than sending a zip file. We would rather be re-engaged later on merit than retained by making the code hard to leave.
That depends more on the rollout than the software, which is why we start with one team, one line or one branch and fix what the first group finds before extending. Screens are built with the people who will use them daily rather than signed off by a manager who will not, and the training is aimed at that group. A system that is technically correct and socially rejected is still a failure.
Also in products
Web platform
A signed-in system in the browser: records, roles, state changes and an audit trail behind them.
Supporting systems
The supporting builds around the main artefacts: integrations, portals, dashboards, automations and API layers.
Describe what the finished thing has to do and who has to use it. We will tell you which parts of a custom software build are the expensive ones in your case, and where a smaller first release would get you most of the value.
What happens next
