Ship the SDKs, APIs, and docs your roadmap keeps deferring
Willowark supplies senior contract engineering to developer tools and infrastructure companies. The work is usually the surface nobody owns: client libraries where only one language stays current, the versioning policy that has been a design doc for two quarters, the self-hosted build enterprise deals now require, the CLI that works but does not feel good.
We arrive productive and take a whole discipline rather than a slice of your core product. That means SDKs generated from a spec with a hand-written idiomatic layer on top, a compatibility suite running old clients against new servers on every merge, an air-gapped install path for the on-prem tier, or telemetry that produces real usage data without alarming privacy-sensitive customers. We work in your repos and your review process.
A first engagement is usually one bounded surface with a clear definition of done: bringing the lagging SDK to parity and putting release automation behind it, standing up the self-hosted build an enterprise prospect is waiting on, or getting the compatibility suite running in CI before the next breaking change ships. We scope it against your existing repos and review process, so the first pull request looks like one your team wrote. Once that workstream is stable we either hand it back or take the next one.
Reviewed
Sound familiar?
If you've said any of these, we should talk.
“Our SDKs drift. Only the language our founders write in stays current.”
We generate clients from one source of truth, then hand-write the thin layer that makes each feel native rather than transpiled. Release automation publishes every language on a single tag, and a conformance suite runs identical scenarios against each client, so drift fails a build.
“Every enterprise deal wants self-hosted, and we built a SaaS.”
We build the distribution path: a containerized release, a Helm chart with sane defaults, an air-gapped install that pulls nothing at runtime, and entitlement checks that work offline. Upgrades get tested against the previous two releases, and a support-bundle command collects logs and config from environments you cannot reach.
“We want to deprecate v1 but cannot tell who is still on it.”
First we make it observable, attributing usage by route, version, SDK, and account so the decision runs on data. Then the mechanics: deprecation and sunset headers, a compatibility shim that buys a release cycle, and migration tooling that rewrites the common call sites.
“The docs are the product and nobody has time to own them.”
We treat docs as code with testing behind them. Reference generates from the spec so it cannot fall out of sync, and every quickstart example compiles and runs against a live service, so a broken snippet fails a merge rather than a signup.
“Enterprise security review keeps asking for SSO, SCIM, and audit logs, and every deal stalls on it.”
We build the enterprise tier as one workstream: SAML and OIDC login, SCIM provisioning that handles deprovisioning correctly, audit events emitted from the same code path as the action, and exports the customer's security team can consume. The same features ship in the self-hosted build, so the on-prem tier is not a separate answer.
How this industry actually runs
The operation as we usually find it.
These companies carry an unusual ratio: a small team against a surface spanning an API, a CLI, client libraries in every language a customer might use, a dashboard, docs, and often both hosted and self-hosted builds of the same thing. Adoption starts bottom-up, then converts into enterprise deals arriving with security review, SSO and SCIM, audit logs, and an on-prem requirement. Backwards compatibility becomes a permanent tax, since every published endpoint is a promise and breaking one costs trust rather than a bug ticket. Meanwhile the Python SDK is three releases behind the Go one, and the self-hosted build gets tested when a customer reports it broken.
Product, integrations, and the AI feature behind them
Components:
- Your product (web, mobile, API)
- Backend services (queues, jobs, evals)
- AI feature (retrieval, review gates)
- Data & integrations (warehouse, third parties)
Connections:
- Your product to Backend services (API)
- Backend services to AI feature (structured calls)
- Backend services to Data & integrations
What we build
Starting projects that fit Developer Tools & Infrastructure.
- Client SDK generation across languages with a hand-written idiomatic layer on top
- API versioning: contracts, deprecation policy, and compatibility suites running in CI
- CLI ergonomics — command structure, config precedence, shell completion, machine-readable output
- Self-hosted and air-gapped distribution: containers, Helm charts, entitlement, upgrades, support bundles
- Product telemetry with privacy controls and per-version, per-route, per-account visibility
- Docs-as-product tooling with reference generated from spec and examples tested on every merge
- Enterprise readiness: SAML and OIDC single sign-on, SCIM provisioning, audit logging, and data export
- Rate limiting, quotas, and usage metering that hold up under abusive clients and feed billing accurately
Capabilities we bring
Working in Developer Tools & Infrastructure?
Tell us the line.
What runs by hand, what is not connected, what you are trying to build. An engineer replies within one business day with whether and how we would approach it.
Common questions
What Developer Tools & Infrastructure teams ask first.
We have strong engineers. What do you actually add?
Capacity and specific depth, not a replacement. Your senior people belong on the core product, which leaves SDK maintenance, on-prem packaging, telemetry, and docs infrastructure permanently a quarter away. We take one of those as an owned workstream and run it to done.
Have you worked at real distributed scale?
Yes. We worked with American Express on global loyalty and rewards, migrating legacy systems to event-driven microservices in Go across point tracking and the ledger, through to war-room production deployments. That rested on stable contracts between independently deployed services, the discipline that governs an API you cannot break.
What happens to the work when the engagement ends?
It stays with you and keeps running. The compatibility suite, release automation, and docs pipeline live in your CI. Architecture notes and runbooks are deliverables, and we walk the handoff through with whoever inherits the surface.
How do you avoid slowing down our own release cadence?
By working in your process rather than beside it. We open pull requests against your main branch in reviewable sizes, follow your CI and review rules, and keep the workstream we own behind flags or in separate packages where that makes sense. Typically the first week or two are slower while we learn the codebase and the conventions; after that we are usually another reviewer and contributor rather than a queue you wait on.
Which languages and runtimes can you cover for SDKs?
The common set — Go, Python, TypeScript and Node, Java and Kotlin, C#, Rust, Ruby — and we are candid when a language falls outside what we write well. Generation from a spec covers the mechanical part in any language; the idiomatic layer is where native fluency matters. For a language we do not write daily we say so up front, and usually recommend a generated client with a documented contribution path rather than a hand-tuned layer we could not maintain to the same standard.
Strategy. Software. Systems.
Engineering for Developer Tools & Infrastructure.
Describe the problem in your own words. An engineer reads it — not a sales script — and tells you plainly what it would take.