Software Development
Cloud & DevOps
CI/CD, infrastructure and cloud migration
You notice infrastructure twice: when the site goes down, and when the bill arrives. The rest of the time good infrastructure is invisible, and that invisibility is the deliverable. Our job is to make deployments boring, recovery rehearsed, and cost proportionate to what you are actually running.
We do this both as part of the systems we build and as standalone work for teams who have an application already and no confidence in what sits underneath it.
What's included
What we set up and run
Cloud infrastructure
defined as code so an environment can be rebuilt from a repository instead of reconstructed from memory or from one person's knowledge.
Containerised deployments
with identical development, staging and production environments — which is what eliminates "it works on my machine".
CI/CD pipelines
that run the tests, build the image, deploy on merge and roll back automatically when a health check fails.
Zero-downtime releases
so shipping a fix at 11am is a normal act rather than a scheduled maintenance window.
Monitoring, logging and alerting
uptime, error rates, latency, queue depth and disk, with alerts that go to a person who can act and that are quiet enough to still be trusted at 3am.
Backups with tested restores.
An untested backup is a belief, not a backup; we prove the restore and document how long it takes.
Security hardening
TLS, secret management, least-privilege access, patching, firewall rules and audit logging.
Scaling
autoscaling where load is spiky, caching and CDN where it is cheaper, and load testing to find the real ceiling before your customers do.
Disaster recovery planning
a written, rehearsed answer to what happens if a region, a database or an account is lost.
Selected clients in Software Development
8 clients
Cloud cost is an engineering problem
Most cloud bills contain a large amount of waste: oversized instances chosen for a launch that never scaled, environments nobody turned off, snapshots kept for years, logs retained at full volume by default, and traffic paying egress charges it did not need to.
We treat cost as part of the architecture rather than as a finance issue. That means right-sizing based on measured usage, committing to capacity only where the usage is genuinely steady, setting budgets and alerts, tagging resources so spend can be attributed to something, and cleaning up what nobody owns. It also means telling you when a simpler, cheaper setup would serve you better than a distributed architecture built for a scale you do not have.
Migrations
Moving from on-premise servers or between providers is a project with real risk, so it is planned rather than attempted. We inventory what exists, map the dependencies nobody documented, rehearse the migration on a copy, plan the data cutover with a defined rollback point, and keep the old environment available until the new one has proven itself. Where a lift-and-shift is the sensible first step we say so — re-architecting during a migration doubles the risk for benefits that can be captured afterwards, in daylight.
When something breaks
Outages happen to everyone. What separates a well-run system is how quickly the cause is known and how little is lost. That comes from monitoring that points to the failure rather than announcing it, logs you can search, alerting with a defined escalation path, and a rollback that is a routine action rather than a decision. Afterwards we write a plain-language post-incident review: what happened, why, what was affected, and what changes so it does not recur — without blame, because blame is what stops people reporting problems early.
On working with Codigoo
The first thing they did was tell us to stop two campaigns we were proud of. That is when I knew they were reading the numbers and not the brief.
Questions we are usually asked
- Which cloud provider should we use?
For most applications, all the major providers are capable and the decision comes down to your existing commitments, the data-residency requirements you have to meet, and where you can hire. We pick for those reasons, tell you the trade-off in writing, and avoid designs that make leaving unnecessarily expensive.
- Can you take over infrastructure someone else set up?
Yes, and it usually begins with an audit, because undocumented infrastructure is a business risk regardless of who built it. We produce a written map of what exists, what it costs, where the single points of failure are, and what should change first — and you keep that document whether or not you continue with us.
- Do we need Kubernetes?
Probably not. It is excellent at a scale and organisational complexity most businesses never reach, and it is a lot of operational burden before then. Managed container services or straightforward server deployments run a great many successful products, and we would rather you spend that budget on the product.
- What about data residency and compliance?
If your data must stay in a particular country, that constrains the provider, the region and the backup destinations, and it needs deciding before anything is built rather than discovered during an audit. We ask early, and we document where every copy of your data lives — including the backups and the logs, which are the copies people forget.
If nobody at your company can say confidently how you would restore last night's data, that is the place to start a consultation.
More in Software Development
All of this discipline- Web Application DevelopmentScalable web platforms and customer portals
- Mobile App DevelopmentNative and cross-platform iOS and Android
- E-Commerce DevelopmentOnline stores built to convert and scale
- Custom Software & Internal ToolsAdmin dashboards and operations tooling
- API & Systems IntegrationConnect ERP, CRM and third-party systems
- AI & AutomationIntelligent workflows and predictive models
Talk to us about Cloud & DevOps
Thirty minutes with an engineer and a strategist who do this work — not a sales team. You will get an honest answer about whether it is the right thing to buy, and what it would realistically cost.