Cloud & Infrastructure
Technology that keeps software running.
Design APIs, cloud infrastructure, deployment pipelines, observability and scalable technology platforms.
Shipping is the easy part. Running it isn't.
Software that cannot be deployed confidently, observed honestly or recovered quickly will eventually cost more to operate than it cost to build.
Sound familiar?
- Deploying takes a person, an evening and a certain amount of luck.
- The first report of an outage usually comes from a customer.
- Nobody has restored from a backup to confirm the backups work.
- One engineer is the only person who can deploy safely.
- Staging and production differ enough that testing proves little.
- Running costs are rising and nobody can say precisely which part is responsible.
What we do
How the work runs
Infrastructure design
Environments, networking, data stores and the boundaries between services.
Delivery pipelines
Build, test and deploy on every change, so releasing stops being an event.
Observability
Logging, metrics, tracing and alerting that tell you what is wrong before a customer does.
Resilience
Backups, recovery procedures and capacity planning, tested rather than assumed.
What you get
What you end up with.
Deliverables, not promises. Every one of these is something you own and can point at when the work is done.
Releases that stop being events
Build, test and deploy on every change, so shipping a fix takes minutes rather than a scheduled window.
You find out first
Metrics, tracing and alerting that surface a problem before a customer writes in about it.
Recovery you have actually tested
Backups verified by restoring them, and a recovery procedure someone other than the author has followed.
Environments that match
Infrastructure defined as code, so staging behaves like production and 'it worked locally' stops being a diagnosis.
Typical use cases
- Moving from manual deployment to a real pipeline
- Containerising and standardising environments
- Adding monitoring and alerting to a system already in production
- Preparing a platform for higher load or more tenants
Engineering capabilities
- REST API design and versioning
- Docker and containerised environments
- CI/CD with Jenkins and GitHub Actions
- Cloud and edge deployment, including Cloudflare
- Metrics and alerting with Prometheus and Alertmanager
- Error tracking with Sentry
- Database operations, backups and migrations
- Secrets management and environment configuration
Why Recode
Why bring this to us.
- We operate production systems of our own, with the pager attached, so reliability is not theoretical here.
- We work with what you have rather than mandating a rebuild onto a stack we prefer.
- We optimise for what running the system costs over a year, not just what it costs to stand up.
Relevant work
Built by Recode.
KalHR
HR & workforce management platform
A workforce management platform covering HR, payroll, recruitment, performance, attendance and employee self-service.
View projectProDriva
On-demand professional driver booking
A booking platform for hiring vetted professional drivers to drive your own car, with fares quoted up front.
View projectHow we work
From problem to production.
- 01
Discover
Understand the business, users, requirements and problem.
- 02
Design
Define the product experience and technical direction.
- 03
Build
Engineer, test and iterate.
- 04
Launch
Deploy, integrate and get the product into production.
- 05
Evolve
Monitor, maintain and continuously improve.
Ways to work together
How to start without committing to everything.
Most clients begin with a discovery sprint: a fixed fee, a few weeks, and a plan you own whether or not we build it.
Discovery sprint
Find out what it takes before committing to build it.
A short, paid engagement that turns an idea or a problem into something you can make a decision on. You keep everything we produce, whether or not you build with us.
- Scoped requirements and a defined first release
- Technical approach and architecture
- Delivery plan with phases and a cost range
- The risks worth knowing about before you spend
Best for
New products, or a build big enough that guessing is expensive.
Product build
A defined outcome, delivered end to end.
We design, engineer, test and launch the product. Work is phased so you see something real early and keep seeing it, instead of waiting months for one reveal.
- Product design and engineering
- Working software in your hands every phase
- Deployment, monitoring and handover
- Documentation your team can actually use
Best for
Getting a product, platform or internal system into production.
Embedded team
Senior engineering capacity that stays.
We work as part of your team — your board, your standups, your priorities — with the scope set by the roadmap rather than a fixed statement of work.
- A named team, not rotating contractors
- Your tooling, your process, your repository
- Capacity that flexes as priorities change
- Knowledge that stays documented, not siloed
Best for
Live products with more roadmap than delivery capacity.
Rescue and modernisation
Take on software that has stalled.
We start with an honest assessment of what exists — what is salvageable, what is not, and what it would cost either way. Then we stabilise it and make it changeable again.
- Codebase and infrastructure assessment
- Stabilisation of the most urgent failures
- An incremental path off what cannot be kept
- A system your team can safely change again
Best for
Inherited, stalled or legacy software still carrying the business.
Questions
Cloud & Infrastructure: common questions.
- Do we have to change cloud providers?
- No. We work with your existing provider and accounts. Migration is only worth recommending when the numbers or the constraints genuinely justify it.
- Can you do this without pausing feature work?
- Yes. Infrastructure work is usually incremental — pipeline first, then observability, then resilience — so delivery continues while it improves.
- What if we have no one to run it afterwards?
- We can hand over to your team with documentation and runbooks, or stay on to operate and monitor it. Both are supported; neither is assumed.
- How do you price work?
- Fixed fee for discovery, phased fixed scope for builds, and a monthly rate for embedded teams. You get a cost range before any build starts, and we would rather tell you a number you do not like than discover it together halfway through.
- Who owns the code?
- You do. All source code, infrastructure definitions and documentation are yours, in your repositories and your cloud accounts, from the first commit.
Other services
Need cloud & infrastructure?
Tell us the problem and the constraints. We'll come back with how we'd approach it, what it would take, and whether we're the right people for it.