Discovery and technical shaping
We turn an ambition into a buildable plan: domain model, service boundaries, integration points, the risky unknowns, and a sequence that puts the most uncertain thing first rather than last.
Product engineering from discovery to a system you can operate.
Software Development
Software becomes expensive when the early decisions were made quickly and never revisited. We start with technical shaping — the data model, the boundaries between services, the failure modes — then build in increments you can review and deploy continuously. That covers greenfield products, platform work behind an existing front end, and the careful modernisation of systems that are still earning money but have become difficult to change.
What you get out of it
- A working system in production, deployed through a pipeline your team controls
- A data model and service boundaries that still make sense after the second and third feature
- Test coverage placed where it pays: contracts, critical paths and known failure modes
- Infrastructure defined as code, reproducible across environments and documented
Capabilities
What the work involves
The concrete engineering that makes up a software development engagement.
Backend and API design
REST and GraphQL APIs with versioning, pagination, idempotency and sensible error contracts. Designed from the consumer’s perspective and documented in OpenAPI so integration is not archaeology.
Distributed systems and events
Queues, event streams, background workers and scheduled jobs built with retries, dead-letter handling and idempotent consumers, so a downstream outage degrades the system instead of corrupting it.
Data modelling and storage
Relational schemas that hold their shape, considered indexing, safe online migrations, and a clear decision on where caching, search and analytical workloads live.
Cloud infrastructure and CI/CD
Terraform-defined environments, containerised services, automated pipelines with gated deployments, secret management, and monitoring with alerts that map to real user impact.
Legacy modernisation
Incremental extraction rather than a rewrite gamble: characterisation tests around current behaviour, a strangler-fig boundary, and traffic moved across a slice at a time with rollback available.
Deliverables
What lands in your repository
Everything we produce is yours, in your accounts, documented well enough for your own engineers to carry forward.
- Source code in your repository with commit history, architecture notes and decision records
- OpenAPI or GraphQL schema documentation for every service interface
- Automated test suites: unit, integration and contract tests running in CI
- Terraform modules and environment definitions for dev, staging and production
- Monitoring, structured logging, alerting and an on-call runbook
- A handover with your engineers, covering architecture, operations and known trade-offs
Technology we reach for
Chosen per project against your constraints and what your team can maintain — never because it is new.
- TypeScript
- Node.js
- Python
- Go
- PostgreSQL
- Redis
- Kafka
- GraphQL
- Docker
- Kubernetes
- Terraform
- AWS
- GitHub Actions
- OpenTelemetry
Questions
Software Development, answered directly
Both, and most of our work is on systems that already exist. We start with a short orientation period: read the code, run it locally, review the deployment path, and write characterisation tests around the behaviour we must not break. From there we work in small, reviewable pull requests against your branching model. Inheriting an undocumented codebase is normal — we plan for it rather than treating it as an exception.
Rewrites fail when the old system still holds undocumented business rules, which is almost always. We prefer the strangler-fig approach: put a boundary in front of the legacy system, extract one capability at a time behind it, and move traffic gradually with rollback available at every step. A full rewrite is only sensible when the platform itself is unsupportable and the domain is small enough to re-specify with confidence.
We aim coverage at risk rather than at a percentage. Unit tests on domain logic and edge cases, integration tests against real databases and queues in containers, contract tests on every API boundary, and a small set of end-to-end tests over the flows that would cost money if they broke. All of it runs in CI on every pull request, and the suite has to stay fast enough that engineers do not start skipping it.
You do, from the first commit. Work happens in your repositories, your cloud accounts and your CI system, not ours. There are no proprietary frameworks, hidden licences or components that only we can maintain, and no vendor lock-in written into the contract. Every engagement ends with a handover session covering architecture, operations, deployment and known trade-offs, plus written documentation and decision records so your own engineers can continue without us.
Next step
Tell us what you are trying to build.
Send us the problem, the constraints and the deadline. We will come back with a technical approach, a shape for the team, and an honest view of what is achievable.