Bespoke Custom Engineering
Software built for the process you actually run — cloud-native, documented, tested, and handed over without a debt you inherit on day one.
What bespoke custom engineering is
Bespoke custom engineering is building software specifically for one organisation's process, rather than configuring a product built for a general market. It is the right choice when the process being automated is a source of competitive advantage, when no product fits without changing how the business works, or when licence and customisation costs for an off-the-shelf system exceed the cost of building exactly what is needed.
Bespoke versus off-the-shelf
We start most conversations by trying to talk clients out of a custom build, because for a large share of business problems a product already exists and configuring it is cheaper than building. Accounting, payroll, CRM, helpdesk and email marketing are solved markets; a bespoke version is usually an expensive way to end up with fewer features.
Custom becomes the better economics in four situations.
The process is the advantage. If how you do something is why customers choose you, encoding it in a generic product means adopting someone else's version of it, and your differentiator becomes a set of workarounds.
Nothing fits without distortion. When "implementing" a product means changing the business to match its assumptions, the true cost includes the productivity loss from that change, which rarely appears in the comparison.
Licence economics invert. Per-seat pricing at scale, or a product whose valuable feature sits behind an enterprise tier you otherwise do not need, can make a build cheaper within two to three years — including maintenance.
Integration is the product. Sometimes what is needed is not an application but the layer between applications. That is integration work, and it is covered on the integration pillar page.
We put the comparison in writing during scoping, including the case for not building. A client who buys a product on our advice is a better long-term relationship than one who builds something they regret.
Cloud-native and modular architecture
We build cloud-native by default: applications designed for the environment they run in rather than lifted onto it.
Microservices where they earn their place. Services are split along business capabilities that change at different rates and need to scale differently, not split for their own sake. A distributed system has real operational cost, and a well-structured modular monolith beats badly drawn microservices every time. We say which one we think you need and why.
Serverless for the right workloads. Event handlers, scheduled jobs, file processing and spiky low-baseline traffic run as serverless functions where paying only for execution beats paying for idle capacity. Steady, latency-sensitive workloads run on containers. The decision is made per workload, not per organisation.
Containers and infrastructure as code. Applications ship in Docker containers; environments are defined in version-controlled infrastructure code so staging and production are the same thing built twice, and a new environment is a pipeline run rather than a week of setup.
Data design first. Most applications are a database with an interface, and most that age badly do so because the data model was an afterthought. We model the domain in PostgreSQL before building screens — constraints in the database, migrations in version control, and money stored in integer minor units because floating-point arithmetic on currency is a defect waiting for an audit.
Modular replacement of legacy systems. Monoliths are replaced capability by capability behind a facade, with the old system live until each replacement has run a full business cycle. Big-bang rewrites are the most reliable way to spend a year and deliver nothing.
Security and compliance engineering
Security is a design input, not a pre-launch checklist.
Authentication and access control. Role-based access control designed against the actual org chart, enforced server-side on every request. Multi-factor authentication is standard for administrative access, and single sign-on integrates with the identity provider you already run.
Data protection under POPIA. Personal information is classified during data modelling. Retention windows, deletion paths, access logs and the ability to produce everything held about a person are built in, because retrofitting a data-subject request into an application that never planned for one is expensive and frequently impossible.
Application security. Parameterised queries, output encoding, CSRF protection, dependency scanning in the pipeline, secrets in a managed store rather than configuration files, and least-privilege service accounts. None of this is exotic; all of it is what separates an application that survives a penetration test from one that does not.
Auditability. Who changed what, when, and what it was before. In regulated environments this is a requirement; everywhere else it is what makes an incident explicable rather than a mystery.
Encryption and transport. TLS everywhere, encryption at rest for personal and financial data, and key management that does not depend on one person's laptop.
How a build runs
-
1
Discovery and scoping
We map the process, the people who run it, the systems it touches and the rules it must obey. Output is a scope, an architecture, a cost range and an explicit recommendation — including a recommendation not to build, where that is the honest answer.
-
2
Architecture and data model
Domain model, service boundaries, integration points and the PostgreSQL schema are designed and reviewed before feature work starts. This is the cheapest point at which to be wrong.
-
3
Iterative delivery
Two-week increments, each ending with something running in a staging environment you can use. Test coverage and documentation are part of the increment, not a phase at the end that gets cut when time runs short.
-
4
Security review and hardening
Access control, data classification, dependency scanning and audit logging are reviewed against the design before go-live, not after a client asks whether it is safe.
-
5
Go-live and stabilisation
Deployment through the same pipeline used throughout, with monitoring, alerting and rollback in place. Stabilisation is planned time, because the first fortnight of real use always finds things no test environment would.
-
6
Handover
Source code, infrastructure code, runbooks, architecture documentation and a walkthrough with the team who will own it. Whether you keep us afterwards should be a commercial decision, not a technical necessity.
Engagement models
Fixed-scope build. A defined outcome, a fixed price and a fixed schedule. Suits work where the scope is genuinely knowable up front — a replacement for a system that already exists, or an application with a well-understood process behind it. Changes go through a written change process, which is what keeps a fixed price meaningful.
Dedicated capacity. An agreed engineering capacity for a period, working a prioritised backlog you control. Suits ongoing product development where the direction is clear but the next quarter's features are not.
Architecture and review. Our architects work with your existing team — designing the system, reviewing the build, unblocking decisions — without us writing the majority of the code. Suits organisations with engineering capability who need senior architecture rather than more hands.
Rescue and recovery. A project that has stalled, or a system whose original team is gone. We assess honestly, including when the finding is that the code should be replaced rather than repaired, and we say so before taking the work.
The zero tech-debt-carryover commitment
Technical debt is not a moral failing; it is a financing decision, and it is legitimate when taken deliberately and repaid on schedule. What is not legitimate is a supplier who hits a deadline by borrowing against a system you are left holding.
Our commitment is specific and checkable. Documentation, test coverage and infrastructure-as-code are delivered inside each increment, not deferred to a phase that gets cut. Any shortcut taken to meet a date is recorded in writing, with the cost of repaying it, and the decision to carry it is yours rather than ours. Dependencies are current at handover. And handover includes everything required to run and change the system without us — source code, infrastructure definitions, runbooks and a working local development environment. If we have done this properly, you are free to leave.
Custom engineering questions
- When is bespoke software the right call over an off-the-shelf product?
- When the process is a competitive advantage and a generic product would flatten it; when implementing a product would mean changing the business to fit its assumptions; when per-seat licence economics at your scale exceed a build within two to three years; or when what is really needed is the integration layer between existing systems. Outside those cases, configuring an existing product is usually cheaper, and we will tell you so during scoping.
- What does the zero tech-debt-carryover commitment mean in practice?
- Documentation, tests and infrastructure-as-code ship inside each two-week increment rather than as a final phase. Any shortcut taken to meet a date is written down with the cost of repaying it, and carrying it is your decision. Dependencies are current at handover, and handover includes source, infrastructure definitions, runbooks and a working local environment — enough to run and change the system without us.
- Which technology stack do you build on?
- Predominantly PHP and Laravel for application work, PostgreSQL for relational data, Docker for packaging, and AWS for infrastructure, with serverless functions for event-driven and scheduled workloads. Where an existing estate dictates otherwise — an in-house .NET or Java platform, a specific cloud — we work in it rather than arguing you into a rewrite.
- Who owns the intellectual property in a custom build?
- You do. Intellectual property in commissioned work transfers to the client, stated in the engagement agreement. Pre-existing components and open-source libraries stay under their own licences, and we list what those are before the build starts rather than at handover.
- Can you take over a system another supplier built?
- Yes, starting with an assessment of the code, data model, infrastructure and deployment process. That assessment produces an honest answer, which is sometimes that a rewrite of a component is cheaper than repairing it. We give you the assessment and the reasoning whether or not you continue with us.
- How do you price a build?
- Fixed-scope work is priced from a scoped architecture after discovery, with a written change process. Dedicated capacity is priced per period. Neither is quoted from a feature list alone, because a price given before the data model is understood is a guess that someone eventually pays for.
Scope a build
Bring the process, not the specification. We will map it, tell you whether it should be built or bought, and price the version worth doing.
Book a scoping session