Loading
Enterprise applications · Platforms · Modernisation
Some businesses run a process no packaged product models correctly. We build the system for that process, in typed code you own, with the handover documentation written while the work is happening rather than after it.
The problem
Buying software is almost always the right first answer. Accounting, payroll, email, storage: these are solved, and a custom version is an expensive way to end up with less. The case for building starts when the process that makes you money is the process the package handles worst.
You can usually recognise it by the workarounds. A spreadsheet that lives beside the ERP because the ERP cannot express your job-work stages. A WhatsApp group acting as the approval queue. A monthly ritual where somebody exports three CSVs and merges them by hand because no single system holds the whole picture. Each of those is a business rule that exists in someone's head and nowhere else, and the cost of it is invisible until that person is on leave.
The second trigger is licence arithmetic. Per-seat pricing on a tool that forty operators touch for six minutes a day gets expensive quickly, and the escape route is usually a thin internal application that does those six minutes properly and reads from the system of record for everything else.
The trigger that is not a good reason to build is dissatisfaction with an interface. If the package models your process correctly and people simply dislike using it, a configuration project or a training week is the cheaper fix, and we will point that out before quoting a build.
What is included
7 areas of work. Most engagements start with one or two and widen once the first release is in use.
Operations systems, admin consoles, approval workflows, scheduling tools and the internal applications that sit between two packaged products. Built for the people who use them all day, which means keyboard-first, fast list views and no modal dialogs where a page would do.
Domain modelling, database design, background job processing, event handling and the service boundaries that decide how painful year three will be. We favour a well-structured monolith until the load or the team size genuinely argues for splitting it.
REST and GraphQL APIs with versioning, typed contracts and generated documentation, plus the integration work into ERP, Tally, payment gateways, logistics providers and whatever else already holds your data. Retries, idempotency keys and reconciliation jobs included, because integrations fail in production.
Assessing what to rewrite, what to replatform and what to wrap behind an API and leave alone. Strangler-pattern migrations where the old system keeps running while functionality moves across module by module, so there is no weekend big-bang cutover with no way back.
Typed languages, code review on every change, automated tests at the levels where they pay for themselves, and static analysis in CI. We write integration tests around business rules and skip the ceremonial unit tests that only assert the framework works.
A fixed-scope project when the requirements are stable, a dedicated pod when the roadmap is still moving, or named engineers embedded into your existing team and your board. The model is chosen from how settled the scope is, not from what is easiest to invoice.
A written support arrangement agreed before launch rather than negotiated during an outage: response windows, escalation path, who is on call, and what counts as a defect versus a change. Dependency updates and security patching run on a schedule.
How we work
Discovery happens with the people who do the work, not only with the person signing. We map the process as it actually runs, including the exceptions, because the exceptions are where custom systems earn their money and where most failed projects were scoped wrong. The output is a written scope, an architecture sketch and a phased plan you can read without a translator.
Delivery runs in two-week cycles with a working demo at the end of each one, on a real environment you can log into. Not a slide with a percentage on it. A shared board stays open the whole time, and change requests are priced when they arrive rather than accumulating into an argument at the end.
Every build ships with a test suite, a README that a new developer can follow, environment setup scripts, and deployment notes. That is not diligence for its own sake. It is what makes it possible for you to take the work in-house, or to another vendor, without a rescue project. Code that only its author can run is a liability regardless of how well it works today.
In practice
Discovery happens with the people who do the work, not only with the person signing. We map the process as it actually runs, including the exceptions, because the exceptions are where custom systems earn their money and where most failed projects were scoped wrong. The output is a written scope, an architecture sketch and a phased plan you can read without a translator.
Where it comes up
04 situations
If none of these is quite your situation, describe it in your own words — that is a better starting point than picking a service off a list.
Stack
We pick from 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.
Sector context
Domain knowledge shortens discovery. These are the sectors where we already understand the vocabulary and the failure modes, so the first version of the build is closer to right.
Shift-based production data, downtime causes, quality records and the daily gap between what the ERP holds and what the floor actually did.
Lot and parcel movement, job-work with karigars, grading records and the reconciliation that follows a stone through five pairs of hands.
Appointments, records, billing and reporting, where patient data handling and clinical workflow set the constraints before anything is designed.
We have not published a case study for this service yet. When we do, it will name the client with written permission and quote numbers the client can defend. Nothing else is worth reading.
Until then, the useful version of proof is a conversation about your problem. Ask us how we would approach it, what we would refuse to do, and where the estimate is soft.
Ask about comparable workQuestions
By breaking it into pieces small enough that each one resembles something we have built, then being explicit about which pieces are uncertain. Estimates come with the assumptions written next to them, and the parts we cannot size confidently are called out as such rather than padded silently. If a third of the scope is genuinely unknown, the honest answer is a short paid discovery phase before a number, not a number with a large invisible buffer in it.
You do, from the first commit. Work happens in your repository under your organisation account wherever possible, and IP assignment is written into the agreement before development starts. We do not hold source, credentials or infrastructure back as a bargaining position, and there is no scenario where ending the engagement means losing access to what you paid for.
Yes, and it is often the better arrangement because they know the domain. In that model our engineers join your board, follow your review process and your conventions, and the split of ownership is agreed at the start so nobody is guessing who is responsible for a module. We would rather leave your team more capable than more dependent.
That is planned for from the beginning. The repository, the environment setup, the deployment pipeline and the architecture notes are all in your accounts, and a handover phase includes walkthrough sessions with your engineers and a period of overlap where we answer questions while they take over. It is a scheduled transition, not a cliff.
Both, matched to how settled the scope is. A well-understood build with stable requirements can be fixed price, and we will hold it. A product still finding its shape is better served by a dedicated team at a monthly rate, because a fixed price on a moving target simply moves the argument to the change-request process. We will tell you which one your project actually is.
We say so and reduce it. This happens more often than clients expect, usually when discovery reveals that two of the requested modules are already handled adequately by an existing tool. Shipping a smaller system that people adopt is a better outcome for both sides than delivering scope that will never be used.
Works well with
Send a paragraph about what is not working today. You will get a written reply from someone who would be on the build, covering how we would approach it, roughly what a first phase looks like, and whether software development is even the right place to spend the budget.
What happens next
