Ad Hoc Consultations and Ongoing Advisory
Some decisions are too small for a project and too consequential to guess at. This is a standing technical contact who already knows your systems and can give you a straight answer.
The decisions that fall between projects
Companies buy help for large, well-shaped problems. Build a system. Migrate a platform. Run an audit. What is harder to buy help for is the constant stream of smaller decisions that surround those, and those decisions are where a lot of avoidable cost accumulates.
Should we accept the supplier's proposal to rebuild the integration. Is this schema change safe to run on a live table. Is this database bill normal for our traffic. Is the candidate's take-home assignment good work. Was last week's incident a one-off or a symptom.
Each of these is too small to commission a project. Answered on instinct, under time pressure, without anyone who has seen the same situation before, they go wrong at a rate that is easy to underestimate because the failures show up months later and rarely get traced back.
Context is what makes advice worth having
Generic technical advice is available for free and it is worth roughly what it costs. Anybody can tell you the general tradeoffs of a message queue. Almost nobody can tell you whether your particular system needs one.
The difference is context, and context is expensive to establish. This is the actual reason ad hoc consulting so often disappoints: by the time an outsider understands the situation well enough to be useful, the question has been answered.
So the arrangement starts with reading. The codebase, the infrastructure, the deployment process, whatever documentation exists and how far it has drifted from reality. That work is done once. Afterwards, a question in a message can get a specific answer, because the answer can refer to your systems by name rather than to systems in general.
What a useful second opinion contains
A second opinion that only says yes or no is not much better than a coin toss with authority attached.
What is useful is the reasoning, the conditions and the counter-argument. The version worth having says something like: this is the right call given that your traffic pattern is spiky and your team is small, it would be the wrong call if you were planning to run this in two regions, and the thing that would change my answer is if the compliance requirement you mentioned turns out to be firm. That gives you something to check against, and it lets you notice later when the assumptions stop holding.
The same applies when the advice is against something. Recommending that you do not do something is only actionable if it comes with what would make it worth doing.
Where this format works well
The questions that come up most often in an ongoing arrangement cluster in a few areas.
Proposals and contracts. Reading what a supplier's quote actually commits them to, and which clause quietly decides who owns the result.
Changes that are hard to reverse. Schema migrations on large tables, changes to authentication, anything that touches billing data.
Cost surprises. An infrastructure bill that moved, and finding whether the cause is growth, a misconfiguration or a change that nobody connected to it.
Hiring. Working out what a role actually needs, and evaluating work samples honestly rather than by keyword.
Incidents. Reviewing what happened in a way that produces a specific change rather than a resolution to be more careful.
Where it stops being the right format
It is worth being direct about the limits. This works when your team has the capacity to act on the advice and the question is which action is right. It works badly as a substitute for people. If the real problem is that nobody has time to do the work, an advisor produces a well-reasoned list that nobody executes, and that is worse than useless because it also generates guilt.
It is also the wrong shape for something large and defined. When a question turns out to be a project (a migration, a rebuild, a serious performance problem), the right answer is to scope it as one rather than to keep addressing it in fragments.
What you get
A contact who already has context
Someone who has read your codebase and infrastructure once, so a question does not begin with three days of explanation. The value of ongoing advisory is almost entirely in this.
Written second opinions
For consequential decisions you get the answer in writing, with the reasoning and the case against it. A verbal opinion is forgotten or misremembered by the time it matters.
Architecture and code review on request
A review of a design document, a proposed schema change, or a pull request that worries someone. Outside eyes catch the assumption everybody on the inside stopped noticing.
Technical review of vendor proposals
What a quote covers, what it excludes, who owns the result, what the exit looks like. Contracts are where technical decisions get locked in without anyone technical reading the clause.
Incident review support
Help running a post-mortem that identifies the mechanism rather than a person, and produces changes specific enough to actually be made.
Support in technical hiring
Framing what the role really requires, reviewing candidates' work, or joining an interview. Hiring the wrong senior engineer is far more expensive than the time spent avoiding it.
How we work
- 01
Onboarding once, not every time
We read the code, the infrastructure and whatever documentation exists, and record how the system is put together. That reading is done once so every later question starts from context instead of from zero.
- 02
Agree the cadence and the channel
Whether that is a recurring call, a shared channel for questions as they come up, or both. What matters is that it is predictable enough that people actually use it rather than saving problems until they are urgent.
- 03
Answer in writing where it matters
Small questions get a quick answer. Anything with real consequences gets written down, including what we are uncertain about and what would change the recommendation.
- 04
Keep a path for urgent questions
Some decisions cannot wait for the next scheduled call. We agree in advance how to reach us when something is time-sensitive, so that path exists before the day you need it.
- 05
Review what keeps recurring
Periodically we look at the questions that came up. Repeated questions in the same area usually point at something structural: missing documentation, an unclear ownership boundary, a system nobody wants to touch.
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.
- Grafana
- Prometheus
- OpenTelemetry
- PostgreSQL
- Docker
- OpenTofu
- Terraform
- Sentry
- GitHub
- Linear
- Slack
- Notion
Frequently asked questions
More services in this category
Technology Strategy
Technology strategy is a short list of decisions that are cheap to make once and expensive to revisit. We help you make them deliberately, with the tradeoffs written down.
Current Solutions Audit
An audit turns a vague sense that something is wrong into a ranked list you can act on: what is actually risky, what is merely untidy, and what will break first as you grow.
Decision Support Before Implementation
The cheapest hour in any project is the one spent before it starts. We check the assumptions, compare the offers on equal terms and cut the scope down to what actually has to exist first.
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%.
A technical question and no one impartial to ask?
Message usDescribe the decision in front of you, a vendor quote, a schema change, a hire, and we will tell you how we would approach it and whether ongoing advisory makes sense for you.
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