You're one person. What happens if you're unavailable?
It's a real risk, and I'd rather address it structurally than reassure you about my health.
Everything I produce is written and handed over as it is made, not at the end. Assessments are documents rather than meetings. Architecture decisions get recorded with the reasoning attached, so a successor inherits the why, not just the diagram. If I disappeared mid-engagement, you would hold everything up to that point in a form your team could act on.
The stronger commitment is the one about scope: I don't take work where I would become the only person who understands the system. That's a failure mode I've watched play out from the inside, and it is bad for the client every time. Where a piece of work genuinely needs a team, I'll tell you that instead of stretching to fill it — which does cost me engagements, and is still the right call.
We already have a data team. Why bring in an outside architect?
Usually you shouldn't. Most teams asking this question are right to be sceptical.
There are three situations where an outsider earns the fee:
- A decision that's expensive to reverse and the team is split on. Storage format, catalog, streaming engine, build-versus-buy. The cost of getting it wrong dwarfs the cost of the review.
- A problem the team is too close to. Not a competence gap — a perspective one. Everyone has blind spots about a system they built.
- A recommendation that needs to carry weight upward. Sometimes an executive discounts internal advice and will hear the same thing from outside. That's a political fact, not a flattering one, but it's often the real reason.
If your team already agrees on the answer and just lacks capacity, you need hands, not an architect. Hiring one is an expensive way to get the wrong kind of help, and I'll say so on the first call.
How do I know your recommendation isn't just your favourite technology?
Check the public record rather than taking my word for it. That's the whole reason it exists.
The Architecture Radar carries eleven scored assessments with the methodology, the scoring rubric, and a Known Biases section written by me about me. The underlying scores are published as machine-readable JSON so you can re-weight the axes for your context and see whether the conclusion survives.
Several of those conclusions run against tools I write about frequently. The real-time OLAP assessment concludes most teams asking about Druid and Pinot should evaluate ClickHouse first. The techniques assessment declines to put medallion architecture in Adopt. I publish the ones I got wrong too.
On the commercial side, plainly: no vendor partnerships, nothing resold, no referral fees, no affiliate links. There is no arrangement under which a recommendation pays me differently depending on which way it goes.
How do we avoid this becoming an open-ended consulting engagement?
By structuring the first step so that it can't be.
| Term | What it means |
|---|---|
| Fixed duration | Two weeks. Not "roughly two weeks." |
| Fixed fee | Agreed in writing before anything starts. No hourly meter. |
| Named deliverables | Four: current-state baseline, target state, use-case feasibility matrix, gap analysis and roadmap. |
| The exit | If it doesn't change a decision you were about to make, we stop and you owe nothing further. |
| No lock-in | No retainer, no notice period, no obligation to continue. |
Delivery work is scoped only after both sides share a written understanding of the problem — which is the only sensible moment to scope anything, and the step most engagements skip on the way to a number everyone later argues about.
Your background is heavy on healthcare and life sciences. Does that transfer?
The part that matters transfers. The part that doesn't, I won't pretend about.
What transfers: regulated-industry discipline. Lineage you can defend, auditability designed in rather than retrofitted, privacy handled at the architecture level, and the habit of building systems that assume someone will review them. Those are the same problems in retail and finance and logistics — healthcare just enforces them harder and earlier, so the reflexes are stronger.
What doesn't transfer: knowledge of your business. I won't arrive understanding your margin structure or why that one legacy system can't be touched. The first week of any engagement is spent learning the domain from people who already know it, and an architect who skips that step produces confident, irrelevant advice.
The genomics and clinical work also isn't the whole picture — cloud migrations, warehouse modernisation on Teradata and Oracle, analytics platforms, and a stint in cryptocurrency are in there too. The track record panel has the shape of it.
What does it cost?
The two-week assessment is a fixed fee, agreed before it starts. I don't publish a rate card, and I'd rather explain why than pretend it's an oversight: the number moves with scope, with travel, and with how much of the work is discovery versus delivery. A published figure would be wrong in one direction or the other for almost everyone reading it.
What I will commit to is that you'll have a fixed number in writing before any work begins, and the exit clause caps your downside at exactly that number. If the assessment doesn't earn its fee, you don't pay for what comes after — because there is no "after" unless you want one.
🚫 Who I'm not a good fit for. Staff augmentation where you need a pair of hands on a defined backlog. Work where the decision has already been made and the engagement exists to validate it. Anything requiring a delivery team rather than an architect. And full-time on-site — I work remotely with periodic on-site sessions where that helps. Saying no to these quickly is more useful to you than a discovery call that arrives at the same place three weeks later.
💬 Question not answered here? Ask it directly — dmansh@gmail.com, answered within one business day — or schedule a briefing. Bring an architecture problem and you'll leave with an opinion on it either way.