Services / Build
We design, build and operate bespoke software: discovery, architecture, delivery and run. Engagements are led by a named architect, priced as a fixed scope or a capped ceiling before work starts, and committed to your repository from day one. Legacy replacements use parallel-run and strangler-fig patterns so there is never a single irreversible switch.
At a glance
Lifecycle
Four phases, each with a defined exit condition and a deliverable you can take to another vendor if you choose to. Nothing about our process depends on you being locked in.
The four phases
Every engagement moves through discovery, architecture, build and operate. Discovery establishes what is true about your current systems. Architecture fixes the material decisions in writing. Build ships working software in two-week increments against a signed scope. Operate covers hypercare, runbooks and either handover to your team or a support agreement.
Process walkthroughs with the people who do the work, not just the people who sponsor the project. Inventory of source systems, integration surfaces, data volumes and quality. Non-functional requirements pinned to numbers: concurrent users, peak transaction rate, retention period, recovery point and recovery time objectives. Output is a scope specification and a risk register.
Component and data-flow design, data model, authentication and authorisation model, integration contracts, environment topology, and an architecture decision record for each material choice recording the alternatives rejected and why. Threat model produced at this stage, not retrofitted before launch.
Working software every fortnight in an environment you can log into. Trunk-based development, pull request review by a second engineer, automated tests in the pipeline as a merge gate, and infrastructure as code from the first environment. Demo, then a written increment report covering what shipped, what slipped and what changed.
Thirty days of hypercare with the build team still on the engagement. Runbooks, alert thresholds, on-call rota and dashboards handed over with paired shadowing shifts so your engineers respond to a real incident with ours watching, not after we have gone.
Decision
This is the first question we ask, and we lose work by asking it honestly. Custom software is expensive to own forever. If a product fits, buy the product.
Build vs buy vs configure
Build when the process is a source of commercial advantage or no product fits without heavy modification. Buy when the process is a commodity that thousands of firms run identically, such as payroll or accounting. Configure a platform when the domain is standard but your workflow is not. The deciding factor is rarely licence cost, it is the total cost of owning the difference.
| Signal | Points to build | Points to buy or configure |
|---|---|---|
| Process differentiation | The workflow is how you compete or price differently from rivals | Every competitor runs the same process the same way |
| Product fit | Best available product needs more than 30 percent customisation | A product covers 80 percent or more out of the box |
| Integration depth | Six or more systems must exchange data with transactional guarantees | One or two integrations with published, stable connectors |
| Data ownership and residency | Contract or regulator requires data in a jurisdiction no vendor offers | Vendor already holds the residency and certifications you need |
| Rate of change | Rules change quarterly and vendor release cycles cannot keep up | Rules are set by statute or industry standard and move slowly |
| Ten-year cost | Licence plus per-seat growth exceeds build plus maintenance | Build cost plus lifetime maintenance exceeds subscription |
| Team capacity to own it | You have or will hire engineers to maintain it after launch | No internal engineering function and no plan to create one |
If four or more signals point to buy, we will say so in writing during discovery. We have ended several engagements at that point and been re-engaged later for the integration work instead.
Commercials
Our estimation approach
We estimate bottom-up from a decomposed scope: each user-facing capability broken into engineering tasks, sized by the engineer who would do the work, then loaded with integration risk and a contingency we disclose rather than hide. A fixed price is only responsible where scope is written down. Where it is not, we cap time and materials instead.
A fixed price on vague scope is not a favour. It is either padding you cannot see or a change-request pipeline you have not been told about yet.
Real bands from our own delivery history, in US dollars, excluding cloud infrastructure and third-party licences. Every proposal restates these against your actual scope.
| Engagement shape | Indicative range | Elapsed time | Typical team | What is included |
|---|---|---|---|---|
| Discovery and architecture only | USD 6,000 – 14,000 | 2 – 4 weeks | Architect plus BA | Scope specification, architecture, risk register, costed plan |
| Single-workflow internal tool | USD 18,000 – 45,000 | 6 – 10 weeks | 3 engineers | One or two roles, one integration, basic reporting |
| Departmental application | USD 45,000 – 110,000 | 3 – 5 months | 4 – 6 engineers | Multiple roles, SSO, audit trail, two to four integrations |
| Customer-facing platform | USD 110,000 – 260,000 | 5 – 9 months | 6 – 9 engineers | Public sign-up, billing, notifications, reporting, mobile-responsive |
| Multi-tenant enterprise platform | USD 260,000 – 600,000 | 8 – 14 months | 8 – 12 engineers | Tenant isolation, RBAC, SLA-backed operations, compliance evidence |
| Legacy replacement programme | USD 180,000 – 750,000 | 8 – 18 months | 6 – 12 engineers | Parallel run, data migration, reconciliation, phased decommission |
| Post-launch support and evolution | USD 4,000 – 22,000 per month | Rolling | 1 – 4 engineers | Tiered support, patching, small enhancements, monthly review |
Cloud infrastructure typically adds USD 400 to 6,000 per month depending on architecture and traffic. Penetration testing, if required for procurement, is quoted separately at USD 4,000 to 12,000 per assessment.
Staffing
Ratios from our standard delivery pods. Named individuals with CVs appear in the proposal before you sign, and substitutions require your written agreement.
| Role | Allocation | Ratio to build engineers | Accountable for |
|---|---|---|---|
| Solution architect | 25 – 40 percent | 1 per pod | System design, architecture decision records, technical risk, integration contracts |
| Delivery lead | 50 percent | 1 per pod | Scope, schedule, burn reporting, escalation, single point of contact |
| Senior backend engineer | Full time | 1 per 2 – 3 backend engineers | Data model, service boundaries, code review, production readiness |
| Backend engineers | Full time | 2 – 4 per pod | Services, APIs, jobs, integrations, unit and contract tests |
| Frontend engineers | Full time | 1 – 3 per pod | Interface implementation, accessibility conformance, client-side performance |
| QA automation engineer | Full time | 1 per 4 – 5 engineers | Test strategy, end-to-end suite, release gating, defect triage |
| DevOps engineer | 30 – 60 percent | 1 per 5 – 8 engineers | Infrastructure as code, pipelines, environments, observability, cost guardrails |
| Product designer | 40 percent in early phases | 1 per pod for customer-facing work | Journeys, interaction design, design system, usability review |
| Business analyst | Heavy in discovery, tapering after | 1 per pod | Requirements, acceptance criteria, process mapping, user acceptance support |
Architect, DevOps and design time is allocated fractionally because full-time allocation of those roles on a six-engineer pod would be billing you for idle capacity.
Deliverables
Phase deliverables
Every phase produces artefacts that are useful independently of us: a written scope specification, an architecture pack with decision records, working software in an environment you control, and an operations pack containing runbooks, alert thresholds and a dependency bill of materials. If you terminate at any gate you keep everything produced up to that point.
Phase 1
The evidence base. Written so a different vendor could act on it.
Phase 2
The decisions, with the rejected alternatives recorded.
Phase 3
Every fortnight, in an environment you can log into yourself.
Phase 4
What your team needs to run the system without us.
Legacy
Legacy replacement fails at cutover, not at build. Every replacement we run keeps the old system answering traffic until the new one has proved itself against real data.
Strangler fig and parallel run
We use the strangler-fig pattern: route traffic through a facade, move one capability at a time behind it, and keep the legacy system authoritative until reconciliation is clean. For financial and transactional systems we add a parallel run where both systems process the same inputs and outputs are compared daily until variance is explained, not merely small.
The facade is what makes each step reversible. Reverting a route is a configuration change, not a rollback.
Honest section
From engagements we have rescued and from our own mistakes. Almost none of these are engineering problems.
| Failure mode | Early signal | What prevents it |
|---|---|---|
| No empowered decision maker | Decisions take more than a week and get revisited | One named product owner with authority to accept scope, in the contract |
| Scope grows without budget moving | Change requests approved verbally, never priced | Written change control with price and schedule impact on every item |
| Data quality discovered late | Nobody can produce a real data extract in week one | Profile actual production data during discovery, before pricing migration |
| Users first see it at user acceptance testing | No end user in any demo for the first two months | Real users in fortnightly demos from increment one |
| Integration partner is not ready | No sandbox credentials and no named contact at the third party | Sandbox access as an explicit discovery exit gate; mock plus contract tests otherwise |
| Non-functional requirements never quantified | "It must be fast" appears in the requirements document | Numeric targets for latency, concurrency, retention, RPO and RTO before build |
| Maintenance never funded | No line in the budget beyond go-live | Twelve-month run cost presented alongside build cost in the proposal |
| Big-bang cutover | Go-live plan is a single weekend with no rollback step | Strangler fig, parallel run, reversible route changes at each gate |
| Vendor knowledge never transferred | Only the vendor can deploy the system | Client engineers on-call with ours during hypercare; runbooks tested by your team |
Answers
Custom software development is the design and construction of an application built for one organisation's specific processes, data and constraints, rather than configuring a packaged product. It is the right choice when the process being automated is a source of commercial advantage, when no product on the market fits without heavy modification, or when integration and data-ownership requirements rule out SaaS.
Our engagements typically run from around USD 18,000 for a single-workflow internal tool to USD 350,000 and above for a multi-tenant enterprise platform. The variables that move the number most are the count of integrations, the number of distinct user roles, regulatory evidence requirements and whether the data has to be migrated from a live system. Indicative bands are published on this page.
Yes, once scope is unambiguous. A fixed price is a transfer of risk, and we price that risk. If the requirements are still moving, a fixed price is either padded to protect us or thin enough to guarantee change requests, and neither serves you. For unclear scope we recommend a two-week paid discovery first, then fix the price against a written specification.
A focused internal tool reaches production in six to ten weeks. A customer-facing platform with authentication, billing, reporting and two or three integrations typically takes four to seven months to first release. Legacy replacements are governed by data migration and parallel-run duration more than by feature count, and usually run eight to eighteen months.
You do. Our master services agreement assigns all IP in deliverables to the client on payment, and the code lives in your repository from the first commit, not in ours. Third-party open-source licences are inventoried in a bill of materials so you know exactly what is in your codebase and under what terms.
Frequently. We begin with a two to three week code and infrastructure audit: dependency currency, test coverage, deployment reproducibility, secret handling, data model integrity. You get a written assessment with a repair-versus-rebuild recommendation. Roughly a third of the time the honest recommendation is to keep more of the existing code than the client expected.
You choose. Some clients take full ownership after a structured handover including runbooks, architecture decision records and paired on-call shadowing. Others move onto a managed support agreement with tiered L1 to L3 coverage and contractual response targets. Either way we run a 30-day hypercare period after go-live at no additional charge.
Yes, and mixed teams are common. In that arrangement we agree code ownership boundaries, a single shared definition of done, and one technical decision forum so architecture is not negotiated twice. What does not work is two teams building against the same module with separate backlogs, and we will push back on that structure.
Send a short brief and you get a 45-minute call with the architect who would lead the work, then a written proposal with a real number within five business days. If building is the wrong answer, we will tell you that on the call.