Your advocacy team can either build things - an SDK, sample apps, better reference docs - or publish things: posts, talks, videos. Both compete with the product roadmap for the same engineering time. How do you decide the split?

Short answer

Decide by where developers are dropping out. Build when the blocker is inside the integration and repeats for every developer; publish when the blocker is awareness or a mental model.

Developer relations matters here because the deciding what to build versus what answer has to show the boundary, not just the happy path.

The decision is a diagnosis, not a preference

Build-versus-publish sounds like a taste question and is not. It resolves as soon as you say where developers are dropping out, because the two categories of work fix different drop-offs and are close to useless against each other's.

Publishing fixes awareness and mental-model problems. A developer who does not know your API can do a thing, or who holds a wrong model of how your webhooks retry, is fixed by words: a post, a talk, a diagram, a clearer page in the reference. Building fixes friction inside the integration itself. A developer who understands exactly what to do and still spends a day on request signing, or who cannot get from a blank editor to a first successful call without writing plumbing every other developer also writes, is not fixed by an article explaining the plumbing. They are fixed by not having to write it.

So the first question is not "should we build an SDK" but "at which step are we losing people, and is the cause not knowing or not being able". The instrumented version of that is the drop-off between account creation and first successful call, and between first call and the second week of calls. If people never arrive, publish. If they arrive and stall inside the integration, build. If they integrate quickly and vanish after a fortnight, neither answer applies and the problem is the product's value or its pricing, which is worth saying out loud in an interview because it is the case candidates almost never volunteer.

Observed signal	Likely blocker	The work that fixes it
Few developers ever create a key	Nobody knows the API exists or what it is for	Publish: talks, posts, launch material
Keys created, first call rarely reached	Friction in setup, auth or the first request	Build: quickstart, SDK, working sample
First call reached, then wrong usage	Mental model is wrong	Publish: conceptual docs, a diagram, a worked example
Integration works, usage stops after weeks	Product value or price, not developer experience	Neither; escalate as product feedback
Same question in support every week	A gap that repeats per developer	Build if it is code, publish if it is understanding

Price the build option at its true cost

The reason this question is hard, and the reason it belongs to senior candidates, is that the two options have completely different cost shapes and are usually compared as if they did not. A post is written, published, and either ages out or gets a revision. An SDK is a permanent commitment: it has to track every API change, keep up with its language ecosystem's own churn, respond to security advisories in its dependencies, and answer issues from people who now depend on it. Shipping one is opening a support surface that does not close.

The honest way to present this to a product owner is as an ongoing allocation rather than a project cost, derived visibly from your own assumptions rather than asserted.

Proposal: one official SDK, one language

Build:      6 engineer-weeks   (client, auth, retries, tests, docs, examples)
Ongoing:    ~0.2 engineer      (release cadence, dependency and security
            per year            updates, issue triage, tracking API changes)

Read that second line as: this SDK consumes roughly a day a week of
someone's time, permanently, from the same pool the roadmap draws on.
Three SDKs is most of an engineer, forever, before any new feature.

Those figures are illustrative — the point of writing them down is the shape, not the arithmetic. What the shape tells you is that the number of things you build is bounded by the ongoing capacity you can defend indefinitely, not by the sprint capacity you can borrow once. A team that ships four SDKs in a good year and then loses a headcount has four abandoned SDKs, and an abandoned official SDK is actively worse than never having shipped one: developers found it, trusted the badge, and are now on a client that silently lags the API.

Publishing has the inverse profile. Cheap to produce, and the decay is quiet rather than loud — an out-of-date post does not break anyone's build, it just teaches them something wrong. That asymmetry is a genuine argument for biasing towards publishing at the margin, and it is also why a stale tutorial ranking above your own reference docs is a real and common failure worth having an answer for.

Negotiating against the roadmap rather than around it

Since the engineering time is the same pool, the conversation is with a product owner who has their own commitments, and the framing that works is not "advocacy needs capacity". It is to bring the drop-off number and show that the fix sits inside the integration. A product owner is generally willing to fund removing a friction point that is provably costing them activated developers, because that is their metric too. They are much less willing to fund a sample app because the advocacy team would like to have one.

The corollary is that you must be willing to name what you are stopping. If the answer to every prioritisation question is that both matter, you have not made a decision and the interviewer will read it as exactly that. Concretely: pausing a video series to get a quickstart shipped is a decision; adding the quickstart to a list is not.

The specific error: building because building is legible

The trap in this question is that build work feels more substantial to the person doing it and to their manager. An SDK is a repository with commits and stars; a post is a thing that scrolls past. Advocacy teams therefore drift towards building, accumulate maintenance debt they never priced, and end up with a portfolio of half-current artefacts and no capacity to publish. The reverse failure exists and is rarer: teams that publish relentlessly about an integration path that still takes two days, where every reader hits the same wall the content politely walks around.

The tell for a strong answer is whether you check the same signal in both directions. The question "are we publishing our way around a problem we should be fixing" and the question "are we building things nobody knows exist" are the same instrument read from two ends, and a candidate who only ever asks one of them has half the discipline.

Build only what you can commit to maintaining for as long as the API lives, and publish everything else — an abandoned official SDK does more damage than the article you did not write.

---

© 2026 Preptima. Originally published at preptima.com.