Loading…
Fintech
## The challenge The brief was unusually broad: architect the entire cloud environment, staging through production, and own reliability, security, and evolution thereafter. Not a migration, not a specific fix. The whole platform, from nothing, with the authority to decide what it should be. Three constraints shaped every decision: One engineer, permanently. There was never going to be an infrastructure team. Whatever got built had to be operable by people whose job was the product, and had to keep working during the weeks when the infrastructure engineer was working on something else. That rules out a large class of otherwise reasonable designs. No inherited standard to follow. With greenfield authority comes the absence of anything to copy. Every convention, from how environments are separated to how a secret reaches a running container, had to be decided once and then held to, because the second and third exceptions are what turn a platform into a collection of special cases. Security posture as a starting condition, not a later project. A SaaS business is asked about its security posture by every serious customer during procurement. Building private database access and centralised secrets from the beginning costs almost nothing. Retrofitting them into a live platform is a quarter of the work.
Client: ChargeAutomation
Secteur: fintech
ChargeAutomation is a Canadian SaaS business. Like most companies at its stage, it had a product team that could ship features and no one whose job was the platform underneath them. That is the ordinary version of this problem. Engineering teams reach a point where the infrastructure that carried them through early development stops being adequate, and the choice is to hire a senior infrastructure engineer they cannot yet justify full-time, or to keep improvising. This engagement was the third option.
We designed and built the EKS clusters and the surrounding AWS environment, delivered exclusively through Terraform.
Not mostly. Exclusively.
Nothing was created in the console and then documented afterwards, which is the usual compromise—and the usual source of drift.
The practical consequence is that the platform’s actual state and its described state never diverged. There was no gap between the architecture diagram and reality for someone to discover during an incident.
No public endpoints on the data tier, at any point in the platform’s life.
This is straightforward to do on day one and expensive to introduce later, because by then something depends on the shortcut.
Credentials were centralised in AWS Parameter Store. They never lived in the repository, environment files, or developers’ local setups.
One place to grant access. One place to revoke it. One place to look during an audit.
Both decisions are unremarkable individually. Making them at the start, and never taking the exception, is what makes them worth writing down.
We built end-to-end, multi-stage pipelines on Bitbucket Pipelines with automated quality gates in front of production, bringing deployment time under ten minutes end to end.
The number matters less than what it changes.
Deployment speed determines how a team behaves. Above about half an hour, releases get batched, batches get riskier, and rollback stops being the obvious first response to a problem.
Under ten minutes, shipping a fix is faster than debating whether to, and that changes the culture around production more than any policy does.
We built the full monitoring stack:
This materially reduced incident detection time.
Detection time is the part of an incident that nobody sees on a status page and that dominates the total. A team that finds out from a customer has already lost the expensive minutes.
For a platform with one infrastructure engineer, this layer is not a convenience. It is the mechanism by which the other engineers can act without waiting.
Architecture records and runbooks were written as part of the work rather than after it, and became the team’s operational reference.
They measurably reduced incident resolution time.
This is the piece most consultants skip, and on a fractional engagement it is the piece that matters most.
A platform that only its author can operate is a liability disguised as an asset.
The test of this engagement is not what worked while we were engaged. It is what kept working when we were not in the room, and documentation is the mechanism that makes that possible.
| Area | Technologies |
|---|---|
| Cloud | AWS, EKS, RDS, S3 |
| Infrastructure as Code | Terraform |
| CI/CD | Bitbucket Pipelines, multi-stage with automated quality gates |
| Observability | Prometheus, Grafana, AlertManager, New Relic |
| Secrets | AWS SSM Parameter Store |
| Practice | Architecture decision records, runbooks, incident response |
This engagement ran concurrently with two others, and that is the point rather than a caveat.
A company at this stage needs senior infrastructure judgment, not senior infrastructure presence.
The value is concentrated in a small number of decisions:
Those decisions take a fraction of a full-time role to make and determine years of operational cost. The hours spent maintaining the result are far fewer, and much of that work does not need a senior engineer at all.
Nothing depended on being present.
A platform defined entirely in Terraform can be read, reviewed, and changed by the product team without the infrastructure engineer in the room.
As an external consultant, no engineer on that team reported to us.
Every standard that stuck did so because it was adopted voluntarily. That is a different discipline from mandating one, and it produces platforms that survive the consultant leaving.
Decide the conventions once, then hold them.
Platforms do not degrade through bad decisions; they degrade through exceptions to good ones.
All infrastructure as code, with no exceptions.
The moment some of it is console-built, the description and the reality begin to diverge, and the gap is discovered during an incident.
Security at architecture time.
Private data tiers and centralised secrets cost nothing on day one and a quarter of the work on day five hundred.
Optimise deployment time early.
It determines team behaviour more than any process document.
Write the runbook as part of the build.
On a fractional engagement, the documentation is not an artifact of the work; it is a large part of the deliverable.
