Infrastructure organization
Infrastructure that grew one urgent decision at a time is hard to change safely. We map what you actually have, retire what nobody owns, and write down the rest.
How infrastructure ends up like this
Nobody plans it. A project needs a database, so someone creates one on a personal account "for now". A contractor needs to change a DNS record, so they get an admin login because scoping the permission properly would take an afternoon. A staging environment is spun up before a launch and never switched off. Three years later there are a dozen services across four providers, two of them billed to a card belonging to someone who left, and nobody can say with confidence what happens if any single one is turned off.
That is the normal result of a company that has been busy shipping. It stops being harmless at a specific moment: when you need to change something quickly and find that you cannot, because nobody knows what depends on what.
What the inventory covers
The first pass is fact-gathering, not opinion. We take read access to your providers and build the list from the systems themselves rather than from what people remember: cloud accounts, domains and DNS zones, hosting, databases, third-party services holding API keys, repositories, deployment pipelines, mail sending and the billing behind all of it.
Then two columns get filled in for every entry. Who owns it, and what breaks without it. Those columns are where the surprises live. A service with no owner is the one whose certificate expires on a Saturday. A service with no known dependents looks like an easy deletion, right up until you check and find that the reporting spreadsheet the sales team lives in has been quietly reading from it for two years.
Access is where the risk concentrates
Permissions accumulate in one direction. People get added, projects get granted access, and almost nothing is ever revoked, because revoking is the action that has a downside if you get it wrong.
So we go through it properly. Who can reach production. Who can move money. Who can change DNS. Shared logins are replaced with individual accounts on any platform that supports it, admin rights are narrowed to the people who actually administer, and credentials sitting in chat threads move into a password manager. Offboarding gets a written checklist, so someone leaving means losing access that day rather than eventually.
None of this is difficult. It is work that never feels urgent until it is extremely urgent.
Environments that are genuinely separate
Plenty of teams have a staging environment sharing a database with production, or a development setup configured by hand years ago that nobody is willing to rebuild. Both make every release riskier than it needs to be, and both quietly discourage the team from testing things.
We pull them apart and make the configuration explicit: infrastructure as code where that fits, documented manual steps where it does not. The aim is not sophistication. The aim is that a new environment can be built from its description, and that something tested in a safe place behaves the same way when it reaches production.
What you are left with, and when to start
The output is not a report handed over at the end. It is an inventory you can open on any given Tuesday, an access map that matches how your team is organised, environments that can be recreated, and short documentation written for someone under time pressure.
That last point decides whether the work lasts. Infrastructure documentation rots faster than any other kind, so we keep it brief, put it where your team already works, and tie its updates to the changes that would otherwise make it wrong. A page describing how things used to be is worse than no page.
As for timing, cleanup is easiest to justify at a transition. A new technical hire who needs to become useful quickly. A migration. An audit or a due diligence process. The departure of the person who knew everything.
It is also the right answer to a specific symptom. If a routine change needs permission from three people and one of them is on holiday, the structure is the problem, not the people.
What you get
Inventory of accounts and services
A single current list of every cloud account, domain, hosting plan, database and third-party service you pay for, with the billing attached to each one.
Ownership map
Each service gets a named owner and a note on what breaks without it. Anything with neither is flagged, because unowned services are the ones that expire quietly.
Access and roles review
We check who can reach what and reduce it to what people need to do their jobs, replacing shared logins with individual accounts wherever the platform allows it.
Separated environments
Production, staging and development are pulled apart so a test can no longer touch live data, and each one can be recreated from its description rather than from memory.
Credential hygiene
Keys and passwords move out of chat threads and spreadsheets into a password manager the whole team uses, with a joiner and leaver checklist attached.
Operational documentation
Short pages describing how things are wired and what to do when something breaks, written for the person fixing it at an inconvenient hour rather than for a folder.
How we work
- 01
Read-only discovery
We take read access to your providers and build the list from the systems themselves: consoles, DNS records, repositories, CI pipelines and invoices.
- 02
Trace dependencies
For each service we work out what calls it and what it calls. This is where the surprises usually are, and it is what makes the removal step safe later.
- 03
Agree what stays
We go through the inventory with you and split it three ways: keep as is, keep but restructure, retire. Nothing is switched off without your sign-off.
- 04
Restructure access and environments
Roles are rebuilt around how your team actually works, environments are separated, and configuration that was set by hand is moved into version control where that is a reasonable fit.
- 05
Hand over the documentation
We walk your team through the result and leave the inventory, access map and runbooks somewhere they already work, not in a document nobody opens again.
Tools and technology
Where a solid open-source tool exists, we choose it over a closed one. No lock-in to a single vendor, and costs you can actually predict.
- OpenTofu
- Terraform
- Ansible
- Docker
- Supabase
- AWS
- Google Cloud
- Microsoft Azure
- Cloudflare
- Vercel
- GitHub
- 1Password
Frequently asked questions
Related work
More services in this category
Service management and environment configuration
Most outages start as configuration that drifted quietly out of date. We keep your environments consistent, updated and described well enough that changes stop being a gamble.
Support for existing solutions
Not every system needs replacing. Most of them need someone who knows how they work, keeps them updated, and fixes things before they become urgent.
Monitoring and rapid problem response
Monitoring only pays off if someone acts on it. We instrument the systems we maintain, keep the alerts trustworthy, and handle what they surface.
Read testimonials from companies that trusted us
Delivered well ahead of the deadline.
ZanReal's individual approach is impressive.
Knowledge and business intuition make them a valuable partner.
Quick solutions that reduced costs by 99%.
Latest
Technical guides, security insights, and what we've learned building with AI.
Do you know everything you are paying for in the cloud?
Message usList the providers and accounts you know about, and we will suggest where a read-only discovery should start and what the inventory needs to cover.
Can't keep up with changes in AI world?
Let us do the heavy lifting. Every week we distill the most important AI developments into a focused 5-minute briefing — so you stay ahead without the noise.
Find out more