Services
Custom software development for processes no product fits
Every organisation has a process that differentiates it: a pricing model, an approval chain, a production schedule. When generic software forces it into the wrong shape, people work around the system. We engineer software that fits.
Custom software is justified in fewer cases than most vendors admit
Buying is usually cheaper than building. Accounting, payroll, email and standard CRM are solved problems, and no one should be paid to rebuild them. Custom software earns its cost when the process is a genuine advantage, when workarounds consume hours every week, or when critical systems cannot exchange data.
A typical case: a manufacturer runs Tally for accounts, a spreadsheet for production planning and messaging groups for shop-floor updates. A new ERP is neither wanted nor needed. What is needed is one planning system that reads orders from Tally, schedules machines and pushes updates to supervisors’ phones. That is the class of system we build.
What we build
What custom software means in practice
Operations platforms
Production planning, job tracking, quality checks and dispatch in one system, modelled on how your operation actually runs.
Extensions to existing systems
Modules alongside Tally, Zoho, SAP Business One or Shopify that handle what those platforms do poorly, with two-way synchronisation.
Pricing and quotation engines
Rule-based pricing for businesses whose quotes depend on materials, dimensions, distances or customer tiers.
Legacy system replacement
Retiring an ageing desktop application or Access database without losing a decade of data or the business rules embedded in it.
Compliance and records systems
Platforms that hold the documents, approvals and audit trails your regulators and customers require.
How we work
How we keep a custom build under control
Custom projects fail when scope drifts unnoticed. Most of our delivery governance exists to prevent that.
Step 1: Paid discovery
One to three weeks of workshops, process mapping and data review, producing a written specification you own whether or not we build it.
Step 2: Phased roadmap
The system divided into releases that each deliver value. The first targets the most expensive problem, not the easiest feature.
Step 3: Recorded architecture decisions
Concise decision records for hosting, data model and integrations, so future engineers understand why the system is built as it is.
Step 4: Build and review
Two-week cycles, each closing with a review. Change requests are documented with cost and schedule impact before acceptance.
Step 5: Parallel running
Where an existing process is replaced, old and new run side by side until outputs reconcile.
Step 6: Handover
Documentation, administrator training and a technical walkthrough with your IT lead or successor vendor.
Deliverables and tools
Deliverables and technology
What you receive
- Functional specification and process maps
- Phased delivery roadmap
- Working software, released in stages
- Data migration with reconciliation reports
- Technical documentation and architecture decision records
- Source code and deployment scripts in your repository
Typical stack
- TypeScript and Node.js
- Python for data-intensive work
- PostgreSQL, MySQL or SQL Server
- REST APIs, webhooks and file-based integrations
- Background job queues
- Docker-based deployment
Engagement model
We almost always begin with a short, fixed-price discovery phase. It protects you from an estimate built on assumptions, and the specification it produces is yours to take to another vendor if you choose.
The first release is then usually quoted at a fixed price, over two to six months depending on scope. Later phases can be fixed-price or delivered by a dedicated team on a monthly retainer. Cost is driven by the volume of business rules, integrations, data migration effort and the number of user roles.
Often paired with business automation, business process consulting and a scoping exercise you can run internally.
Indicators that custom software is premature
- The process changes monthly and stakeholders disagree on how it should work.
- An existing product covers most of the requirement and the gap can be managed manually.
- The underlying issue is that the current process is not followed, not that the tool is wrong.
In these cases, process consulting or better configuration of an existing product is usually the better investment.
FAQ
Questions about custom software development
Why is discovery a paid phase?
A reliable estimate requires real work: interviews, process mapping and a review of your data. Free discovery tends to produce optimistic estimates that grow later. You keep the specification either way.
Who owns the code?
On full payment, ownership of the custom code we write passes to you, as set out in the contract. Open-source libraries remain under their own licences, and we list the significant ones.
Can you take over a system another vendor built?
Often. We start with a paid code and infrastructure review, then recommend whether to maintain, refactor or replace it, with reasons.
How are mid-project changes handled?
Every change is documented with its cost and schedule impact and approved by you before work begins. Smaller changes can often be traded against lower-priority items in the same release.
Which process does your current software not fit?
Explain how it runs today and where it breaks. We will tell you whether custom software is the right remedy.