Work
How we work, and what we’ll show you.
Our client work is under NDA while we agree what can be published. Here is how we engage, the sectors we know, and the standard every case study will meet when it goes up.
Engagement models
Four ways we work together.
Which one fits depends on how well the problem is understood, not on the size of the budget. We will tell you if a cheaper model suits you better.
Fixed-scope project
A defined deliverable, agreed in writing after a paid discovery, built to an agreed date. You know the total before we start, and scope changes are re-estimated openly rather than absorbed into a growing invoice.
- Best when
- Requirements you already understand
- Commercials
- Fixed price, milestone-based payment
Time and materials
An agreed rate and a capacity commitment, with direction set as you go. Suited to exploratory work where fixing the scope in advance would mean fixing it wrongly. We report time against outcomes each month, not just hours logged.
- Best when
- Work that will change shape as you learn
- Commercials
- Day rate, monthly invoicing, 30-day notice
Continuous product team
A team that stays with the product across quarters — discovery, roadmap, and delivery together. The value comes from accumulated context, which is why the minimum commitment is six months.
- Best when
- A product that needs sustained ownership
- Commercials
- Monthly retainer, six-month minimum
Managed support
Ongoing maintenance under agreed response times, with reserved capacity each month for improvements. Applications we did not build start with a paid audit, because committing to response times on unread code would be a promise we could not keep.
- Best when
- Systems already in production
- Commercials
- Monthly retainer by tier, 90-day notice
Our standard
What every case study here will contain.
Publishing this in advance is a commitment. If a case study appears on this site missing any of it, hold us to it.
The actual problem
What the client was trying to do and why it was hard — in their terms, not reframed to flatter the solution.
What we did, including what failed
The approach taken, the decisions made, and the approaches we tried that did not work. A case study with no wrong turns in it is marketing, not evidence.
Measured outcomes
Real numbers against a real baseline. Where an outcome cannot be measured honestly, we say so rather than substituting a softer claim.
The technology, specifically
The stack, the architecture, and why those choices over the alternatives — enough detail that an engineer could assess the reasoning.
Sectors
Where we know the constraints.
Domain knowledge shapes the architecture more than the technology does. These are the sectors whose specific constraints we design around.
Healthcare & life sciences
HIPAA and equivalent regimes constrain where data lives, who reaches it, and what must be logged. We design de-identification, audit trails, and consent handling in from the start rather than retrofitting them.
Financial services
Reporting, audit trails, and data residency drive the architecture more than throughput does. Where PCI-DSS applies, scoping the cardholder data environment tightly is usually the highest-value decision available.
Retail & eCommerce
Spiky traffic and measurable downtime cost make capacity planning and graceful degradation central. We design for the failures that actually occur — a payment provider timing out, inventory drifting out of sync.
Logistics & supply chain
These are integration problems wearing a software costume. EDI feeds, carrier APIs, and warehouse systems that cannot be changed shift the answer toward an anti-corruption layer rather than a rebuild.
SaaS & technology
Multi-tenancy, usage metering, and per-customer configuration are decided early and expensive to revisit. We work through the tenancy model before it becomes load-bearing.
Professional services
Systems that encode how a firm actually operates — matter management, time capture, billing rules. The hard part is the exceptions, which is where off-the-shelf tools usually break down.
FAQ
Questions we get asked.
Why are there no case studies published yet?
Our client work is currently under NDA while we agree what can be published. Rather than invent examples or dress up generic descriptions as projects, we would rather show you nothing here and walk you through relevant work directly on a call — including the delivery standards and security controls every engagement runs under.
Can I see examples of your work before committing?
Yes. On a call we can talk through work relevant to your sector and problem, including architecture decisions and what went wrong, within the limits of what our agreements allow. We can also put you in touch with references at the appropriate stage.
How do you decide what goes in a case study?
Client permission first, then whether there is a measured outcome worth reporting. We do not publish case studies that say a project was delivered successfully without evidence of what it changed.
Do you work with startups or only established companies?
Both. The engagement model differs more than the work does — startups typically want a fixed-scope MVP or a continuous product team, while established companies more often need modernisation, support, or additional capacity.
What size of project do you take on?
Most engagements run from a two-week advisory piece up to a multi-quarter product build. Below about two weeks the overhead of context-loading outweighs the value, and we will tell you if that is the case.
Do you follow a defined delivery process?
Yes, and it applies regardless of project size: written scope with acceptance criteria before work starts, all changes via reviewed pull request, automated testing in CI, separate environments with controlled releases, documentation delivered alongside the code, and a written status report each cycle. You are welcome to audit any of it during an engagement.
How do you handle security and access to our systems?
Least-privilege access granted for the engagement and revoked on exit, secrets in a managed store with automated scanning on every commit, synthetic or anonymised data in non-production environments by default, and automated CVE monitoring with an agreed patching window. Mutual NDA before technical discussion, and all IP assigned to you.
Can you complete our vendor assessment or security questionnaire?
Yes. Send it over and we will complete it. Where we do not yet hold a certification, we say so plainly rather than answering around the question — you can then judge whether the underlying control satisfies your requirement.
Can you work with our existing engineering team?
Yes, and it usually goes better that way. Your team holds context no external review surfaces quickly. We work inside your repository, your process, and your definition of done rather than running a parallel one.
Ask to see relevant work
Tell us your sector and the problem. We’ll walk you through comparable work on a call, including what went wrong, within what our agreements allow.