// SDK Consulting · Est. MMXXVI
Engineering
counsel.
For product teams shipping SDKs, integrating third-party platforms, or running on someone else's infrastructure. We are the read-the-code, write-the-memo, attend-the-architecture-review kind of consultancy. No deck, no theatre, no off-shore back-room.
// engagement.brief.ts import { Brief, Memo } from '@sdk/practice'; export async function engage(brief: Brief) { const framing = await read(brief); const memo: Memo = { question: brief.actual, scope: 'narrow', deliverable: 'written', vendors: 'independent', }; return memo; } // → check inbox by next working day $ echo "ready"
// 01 / services
Five places we are useful.
We work in five fixed practice areas that sit at the boundary between product and platform. We are not a general engineering shop — we take on the kind of work where a written framing changes the outcome more than another pair of hands would.
Each entry below describes what the practice looks like in our hands.
- 01 / service
$ design --sdk --multi-platform
SDK integration architecture.
We help teams design SDKs that age well: multi-platform parity, versioning that does not betray its consumers on minor bumps, deprecation discipline, telemetry that respects the host app. The work usually starts with one or two integration-pain reports and ends with a written API contract the team will recognise three years from now.
- 02 / service
$ evaluate --vendor --redundant
Third-party API strategy.
Most product teams discover too late that one of their critical paths sits behind a vendor that has changed its terms. We help with vendor evaluation, redundancy patterns, contract review, and the migration plan you write before you need it. We do not get fees from any vendor we recommend.
- 03 / service
$ instrument --observability
Platform reliability.
Observability designs that do not drown the team. SLOs and error budgets at a level the team can actually defend. On-call rotations that humans can sustain. We look at the runbook, the alert noise ratio, and the post-mortem cadence — and we ship the small handful of changes that move it.
- 04 / service
$ bridge --mobile --backend
Mobile / backend bridge.
Auth handoff, sync, offline-first storage, conflict resolution, push-notification trust, and the small dozens of edge cases at the boundary between an app and the service it talks to. The work is mostly in the interfaces — defining them clearly and changing them rarely.
- 05 / service
$ audit --due-diligence
Technical due diligence.
For acquirers, partners, and lead investors. We read the codebase, talk to the team, and produce a written diligence report that answers the questions a deal actually needs answered: what is the maintenance load, what is the talent dependency, what changes if a key vendor disappears, what is the quiet technical debt that will surface in twelve months.
// 02 / stack
cat package.json
Where we have shipped real production traffic. We are loyal to a short list of tools — not because they are best at everything, but because we have shipped with them long enough to know how each fails under pressure.
// languages
// protocols
// observability
// infra
// 03 / how we work
Read. Frame. Ship.
Read.
Every engagement opens with a written brief from the team and a read of the relevant code, architecture documents, and incident history. We are trying to understand the actual question before we propose anything. The first session ends with a framing letter the next morning.
Frame.
We send a written framing of the matter — what we believe the question is, what we propose to do, and the work we are deliberately not taking on. The team revises it; we revise it; only then does an engagement formally begin.
Ship.
We pair with the team on the work that needs shipping, write the documents that need writing, and stay close until the engagement's end-date. We do not parachute in and out — every engagement ends with a written close-out the team can revisit a year later.
// 04 / working principles
Four lines we work by.
> We write code where it is useful, but we are not your engineering team.
We will pair on a tricky integration, sketch a reference implementation, or land a single PR that breaks a cycle. We will not become a billable headcount. The deliverable is usually a written framing plus the small handful of decisions the team needed permission to make.
> Independence is non-negotiable.
We do not accept fees from any vendor we recommend or any platform we evaluate. We disclose every other engagement that could matter, and we refuse the work where the disclosure would already be the answer.
> The brief outlives the engagement.
Every engagement produces a written brief. The brief is built so the next person — a future hire, a different consultant, the founder six months later — can read it cold and pick up the thread. We are replaceable on purpose, and that is a feature.
> We refuse fashionable nonsense.
Every quarter, the industry produces a fresh idea that promises to solve everything. Our job is to know the difference between a real shift and a marketing cycle. We are conservative on infrastructure and aggressive on developer experience, in roughly that order.
// 05 / contact
Email is the channel.
We watch the inbox during the working day and reply by the next one. If your project has a real deadline, name it in the subject line and we will prioritise honestly.
// a useful first email
- 01 What you are working on, in two sentences.
- 02 Which of the five services fit, roughly.
- 03 A link to relevant docs or a repo, if any.
- 04 When you would like to begin.