About Aviaurum
Who you actually get.
The long answer to how this firm is put together, how an engagement runs from first conversation to handover, and what we are willing to put in a contract.
The firm
How we are built
A small firm, on purpose.
Aviaurum Technologies is a senior engineering practice serving mid-market companies and the technical teams inside larger ones. The person who scopes your work is the person who does it. That one sentence dictates almost everything else about how we are organised.
The default shape of this industry is a pyramid. Experienced people sell the work, less experienced people deliver it, and the gap between the two is bridged with process — status decks, RAG ratings, a weekly call where nobody says anything load-bearing. It is an efficient way to run a large firm. It is a poor way to fix an estate that has quietly become too complicated for the people who own it.
We do not run that pyramid. There is no bench to keep occupied and no utilisation target that rewards putting an unfamiliar engineer on your problem. The practical consequence is that we take on fewer engagements at a time and we sometimes have a queue. When the queue is the honest answer, we will say so at the first conversation rather than the fourth.
Mid-market companies
Large enough to have real infrastructure, real compliance obligations and fifteen years of accumulated decisions; small enough that nobody's full-time job is keeping all of it coherent. This is where a senior pair of hands changes the trajectory fastest.
Technical teams inside larger organisations
Platform, security and data teams who need a specific capability for a specific period — a migration designed properly, an audit finding closed, a pipeline rebuilt — and who will still own and run the result long after we have gone.
What we are not
Not a staffing agency, not a reseller, and not a firm that bills for the meeting about the meeting. We are engineers who write things down. If what you need is bodies against a backlog, there are firms that do that well and we are not one of them.
The name
Avi · Aurum
The name is the brief.
Avi, from the Latin avis — bird, flight, the root under aviation and ascent. Aurum, Latin for gold; the element Au, atomic number 79. Innovation with enduring value, in two words. We chose it as a constraint, not a slogan.
The useful thing about gold is not its price. It is that gold does not oxidise. Pull it out of the ground, out of a fire, out of a shipwreck three hundred years later, and it comes back as gold. Almost nothing else in the periodic table behaves that way, which is why assayers built an entire vocabulary around testing it: assay, weigh, stamp, then value.
Set those two halves against each other and you have the standing argument of technology work. Most projects optimise one at the expense of the other. Pure ascent produces the impressive new platform that nobody outside the original team can operate, abandoned about eighteen months after the launch post. Pure permanence produces the system that has not been touched since 2016 because touching it is now a board-level risk. Both failures are common and both are expensive.
“A system that cannot be operated by the people who own it has not been delivered. It has been demonstrated.” Aviaurum engineering principles — §2
So we test every engagement on both axes, and we ask you to test us the same way. Did it move the business somewhere it could not previously go? And will it still be worth something once the people who built it have moved on — legible, documented, portable, and cheaper to keep than to replace? A yes to only one of those is not a success we are interested in claiming.
Engagement
Four stages
What the four stages actually involve.
Every engagement runs Assay, Design, Build, Operate, in that order, whether it is a two-week review or a three-year programme. The durations below are typical rather than contractual; the sequence is not negotiable, because skipping a stage only moves its cost later.
-
Assay
Two to four weeks · Fixed fee
The lead engineer who would run the engagement does this personally, alongside the people who actually keep the estate running — not only the people who own the budget. We take read-only access, inventory what exists, read the billing and the licence position, and ask what broke most recently.
Produces
A written finding: current state, risks ranked by what they would cost you, options costed, and a recommendation that may well be “do less than you were planning”. It is yours whether or not you continue with us.
-
Design
One to three weeks · Your architects in the room
Target architecture, sequencing and budget, worked through with whoever will inherit it. Every significant decision is recorded with the alternatives we rejected and the condition that would make us revisit it. Cheap to write now; very expensive to reconstruct in three years.
Produces
Architecture and phasing with real dates and dependencies, a risk register with owners, a set of decision records, and the statement of work that follows from all three.
-
Build
Weeks to quarters · Named engineers
Delivered in increments that each stand on their own, so a change of priority costs you a phase and not the programme. Everything is infrastructure-as-code, in your repositories and your cloud accounts, from the first commit. Reviews happen on a fixed cadence against working software rather than percentages.
Produces
The running system, its tests and pipelines, runbooks written as the work lands, and decision records updated where reality disagreed with the design.
-
Operate
Ongoing or time-boxed · One named owner
We run it, or we train your team to run it and stay on call while they find their feet. Either way the handover is a scheduled deliverable with a date and an acceptance test, not a conversation that keeps getting postponed. The test is simple: someone who did not build it follows the runbook, unaided.
Produces
A handover pack, an on-call rota and escalation path, a review cadence, and an exit that does not require our involvement to execute.
Practice
Engineering principles
How we work, in more detail.
These are not aspirations pinned to a wall. Each one has a cost we pay — in revenue turned away, in hours spent writing rather than shipping — which is the only reason to believe any of them.
We work in your accounts, under your licences.
Code, infrastructure definitions, pipelines and documentation live in your repositories and your cloud tenancy from day one. There is no Aviaurum tenancy holding your state, no shared runtime, no intermediary console. We ask for scoped, time-boxed access and we hand it back at the end of each stage. If this firm disappeared overnight, you would still hold everything that matters and nothing would stop.
Documentation is a deliverable, not a favour.
Runbooks, architecture decision records and diagrams are line items in the statement of work with acceptance criteria attached, which means they are scoped, estimated and paid for like anything else. A runbook counts as complete when someone who did not write it can follow it. If your team cannot operate the system without us, we have not finished, regardless of what the system does.
Decisions get written down with their alternatives.
Every consequential choice is recorded as what we picked, what we rejected, why, and what would make us change our mind. Most technology debt is not a coding failure — it is a decision nobody wrote down, made by someone who has since left, now defended by people who are guessing at the reasoning. Decision records are the cheapest insurance in this trade and almost nobody writes them.
We say no to work we would do badly.
We are six practices deep, not sixty wide. When something falls outside that, we will tell you and, where we can, point you at someone who does it properly. The harder version of the same principle: sometimes the honest finding is that the project you asked us to price should not happen at all, and we would rather say that in week two than invoice for eighteen months of it.
One named engineer is accountable for the relationship.
Not an account manager who relays questions to the people doing the work. A named engineer who was in the assay, who understands your estate, and whose number you have. Escalation is a phone call, not a portal. We support distributed estates and follow-the-sun cover where the work needs it, but accountability never gets distributed with it.
We argue for boring technology, and for removing things.
The interesting choice and the correct choice are occasionally the same, and we will tell you which one you are looking at. More often the highest-value change in an estate is a deletion: a service nobody calls, a tool bought for a problem that no longer exists, a second way of doing something that already has a first. We count those as delivery.
Verification
Hold us to it
Commitments, and how to check them.
Three of these appear on the homepage in summary. Here they are in full, with two more and the evidence you should ask for before signing — including from the firms you are comparing us against.
-
Senior delivery
The engineers named in the proposal are the engineers who do the work. Substitutions require your written agreement, which means we cannot quietly rotate your engagement onto whoever is free this month. It is also why our capacity is finite and we say so.
How you verify it
Named CVs attached to the statement of work, and a substitution clause you can point at. Ask any firm to show you both before you sign; the answer is informative either way.
-
Exit-ready by design
Every asset we produce is portable, documented and owned by you. No proprietary runtime, no configuration only we can read, no agent phoning home. Leaving us should cost you a handover meeting, not a replatforming project.
How you verify it
Ask for a handover pack from a completed engagement and read it cold, without us in the room. If you cannot follow it, neither can the engineer you hire next year.
-
Fixed-scope assay
The opening assessment is a fixed fee with a fixed date and a written deliverable, independent of whatever follows. It is not a free discovery call dressed as consulting, and it does not oblige you to buy the recommendation.
How you verify it
It is priced separately on the first page of every proposal, with its own dates and its own acceptance criteria. The finding is yours if you stop there.
-
Vendor-neutral recommendations
We do not take referral fees or resale margin on the products we recommend, so a recommendation costs us nothing and earns us nothing. Where we hold a vendor partnership, we disclose it before the conversation about that vendor, not after.
How you verify it
Ask for the disclosure in writing, and ask the question that usually settles it: what would you choose here if the licence budget were coming out of your own pocket?
-
Handover has a date
Handover is a planned deliverable with an owner, a date and an acceptance test, agreed before Build starts. It is not the last conversation of the engagement and it is not contingent on goodwill at the end of a difficult project.
How you verify it
It appears in the plan, with its date, before you sign anything. If a proposal has no handover milestone, that is a finding in itself.
Working with us
Careers
We hire rarely, and slowly.
Senior infrastructure, security and platform roles. There is no graduate scheme and no bench, because a firm that promises the engineers in the proposal cannot also be hiring ahead of the work.
The honest description of the job: you scope your own work and then you deliver it, you write down what you decided and why, and you carry the pager for what you built. You will spend more time in other people's estates than in a greenfield repository, and more time writing prose than most engineering roles ask for. In exchange, nobody hands you a specification written by someone who has never seen the system.
If that reads as a fair trade, write to us directly. Tell us about something you built that is still running, and what you would do differently now. That is more useful to us than a list of technologies, and it is what we will want to talk about anyway.