How we work
The method, and how we make money
Independent advice is only valuable to an engineering team if the financial incentives behind it are completely transparent. The method and the incentives are both on this page.
Four steps
You describe the problem
Through the intake form or a short call. Tell us what is going wrong, what is slowing you down, or the decision you are stuck on — not a product name.
No cost and no commitment. If we are not the right team for it, we say so at this point.
We ask the questions that matter
Workload type and shape, scale, latency and availability targets, what is fixed and what is negotiable, what you have already tried, and what a good outcome looks like in numbers.
Usually one call of about 45 minutes, plus any architecture diagrams or documentation you can share.
We deliver a written assessment
A document you can circulate internally and defend in a budget conversation — not a slide deck and not a phone call you have to take notes on.
Turnaround depends on scope and is agreed with you before we start.
You decide, and we can support delivery
Take the recommendation and run it in-house, or have us support the vendor evaluation, the proof of concept and the implementation review.
You are never obliged to buy anything through us. We do not resell hardware, capacity or licences.
What the assessment contains
Step 03 produces a document, not a conversation. This is what is in it.
Target architecture
The recommended design across compute, orchestration, data and networking, with a diagram, and what changes from where you are today.
Cost model
Projected monthly cost for each option modelled side by side, with the assumptions written down so you can challenge them.
Shortlist and trade-off analysis
The products worth evaluating, what each one assumes you already have, and where each one breaks.
Risk and dependency notes
Lock-in, exit cost, single points of failure, and the operational commitment each option creates.
A migration sequence
What to do first, what can wait, and what should not be attempted at the same time as anything else.
The case for doing nothing
Where staying on your current stack is the right financial answer, that is what the document will say.
Engagement formats
Three shapes, depending on what you need. Scope and fee are agreed in writing before any work starts.
Single-decision review
One specific choice, validated before you commit. A platform selection, a capacity commitment about to be signed, or a build-versus-rent question.
Short, fixed scope. Usually one call and a written recommendation.
Architecture diagnostic
Your stack assessed end to end against your workload and constraints, with a target architecture and a costed migration path.
Fixed scope and fixed fee, agreed in writing before any work starts.
Advisory retainer
Ongoing support while you deliver — vendor evaluation, design review, and a second opinion when a decision comes up.
Monthly, with an agreed scope and an agreed exit.
Working across time zones
We work async-first. Written assessments, recorded walkthroughs and shared documents do most of the work, with scheduled calls where a live conversation is genuinely faster. That makes engagements across Asia-Pacific, Europe and North America straightforward rather than a scheduling problem.
Independence
How we make money
The short version: you pay us, vendors do not. Everything else follows from that.
- We are paid exclusively by our clients. Vendors do not pay us anything.
- No vendor can pay to be listed, ranked, reviewed or recommended.
- If we have a referral arrangement with a vendor we recommend, we say so on the recommendation.
- We tell you when the honest answer is that you do not need us, or do not need new software at all.
This is a commitment that will cost us money at some point — there will be a moment when a vendor offers to pay for placement and we say no. We are writing it down publicly now, while it is easy, precisely so that it is harder to quietly drop later.
What we look at before we say anything about a product
The same questions every time, so that two products can actually be compared rather than just described.
The problem it removes
The specific technical failure or operational bottleneck it addresses — not the marketing category. Many products in this space describe themselves identically and behave very differently.
Fit and scale
The workload type and scale where it works well, and where it stops working. A tool that suits a shared cluster of fifty accelerators is often wrong for five, and wrong again for five thousand. Whether it assumes a dedicated platform team matters just as much.
Deployment and operational overhead
Self-hosted, managed, or Kubernetes-dependent. Who operates it once it is in, and how it behaves at three in the morning.
Unstated prerequisites
The most common reason a good product fails is an assumption nobody mentioned — a platform team, an existing cluster, a particular network fabric.
Commercial model and exit cost
Open source, usage-based, or committed contract. What it costs to leave matters as much as what it costs to start.
Weaknesses and failure modes
Every product has a shape. We write the trade-off down, because a recommendation without one is not a recommendation.
How far our knowledge goes — the badges
Every product note on this site carries one of three badges. They exist so you never have to guess whether an opinion is informed by documentation or by experience.
- Desk Research
- Evaluated from public documentation, architecture material and source code. No vendor contact.
- Vendor Verified
- Technical briefing completed with the vendor’s engineering team, and the claims on this page checked with them.
- Hands-On Tested
- Deployed and benchmarked by us on a real workload. The notes reflect what we measured.
A badge only moves when the work behind it is genuinely done. They are worth something precisely because they are not given away.
Questions people actually ask
Are you reselling hardware, capacity or software licences?
No. We are not a reseller or a cloud partner, and we take no margin on anything you buy. Our recommendation and your purchase are separate transactions, deliberately.
Do vendors pay to be listed or recommended?
No. No vendor can pay to appear here, to rank higher, or to be recommended to you. If we ever hold a referral arrangement with a vendor we recommend, we disclose it on the recommendation itself.
How are engagements structured?
Three shapes, depending on what you need. A single-decision review validates one specific choice before you commit. An architecture diagnostic assesses the stack end to end and produces a target design and costed migration path. An advisory retainer supports you month to month while you deliver. Scope and fee are agreed in writing before any work starts.
What does it cost?
It depends on scope, and we would rather quote against your actual situation than publish a number that turns out to be wrong for you. Describe the problem and you will have a written scope and a fee before any work begins.
What do we actually receive at the end?
A written assessment containing a target architecture with a diagram, a cost model for each option with the assumptions stated, a product shortlist with trade-offs, risk and lock-in notes, and a migration sequence. It is written to be circulated internally and defended in a budget conversation.
Have you used every product you write about?
No, and we say so on every page. Each product carries its current verification level — Desk Research, Vendor Verified or Hands-On Tested — and a badge only moves when the underlying work is genuinely done.
Do we need to be running at large scale for this to be worthwhile?
No. The teams who gain most are usually the ones without a dedicated platform or infrastructure function, where these decisions land on whoever is closest to the problem and a wrong turn has to be absorbed by the same people who made it. If the honest answer is that you do not need outside help, we will tell you that.
How do you work with teams in other time zones?
Async-first. Written assessments, recorded walkthroughs and shared documents do most of the work, with scheduled calls where a conversation is genuinely faster. We work with teams across Asia-Pacific, Europe and North America, and time zone has not been a practical constraint.
Will you sign an NDA before we share details?
Yes. Infrastructure details are commercially sensitive and we treat them that way. Ask and we will sign a mutual NDA before you share anything detailed.
Tell us what you are trying to solve.
Describe your current setup and the problem in your own words. We reply within 2 working days with an honest assessment of whether we can help.