---
layout: service
section: Services
title: Reusability
summary: Measure how reusable your APIs actually are — score the estate, surface the duplication, and decide what to consolidate on.
nav: Services
sub: Governance
---

<div class="row gx-xl-9">
  <div class="col-12">
    <section>

      <!-- Breadcrumb -->
      <p class="small text-muted mb-2"><a href="/services/" class="text-decoration-none">&larr; All Services</a> &middot; <a href="/services/governance/" class="text-decoration-none">Governance</a></p>

      <!-- Header -->
      <div class="d-flex align-items-center mb-3">
        <img src="/images/services/reusability.png" alt="" width="64" height="64" class="me-3 flex-shrink-0">
        <h1 class="fs-3 mb-0">{{ page.title }}</h1>
      </div>
      <p class="lead text-muted mb-4">{{ page.summary }}</p>

      <!-- Story -->
      <div class="mb-2" style="max-width: 46rem;">
        <p class="mb-3">In almost every enterprise I walk into, the same capability has been built three, four, five times &mdash; by teams who were not being lazy, but who could not find, could not trust, or could not adopt what already existed. Reuse gets treated like a value statement, something you put on a slide and cannot inspect. It is neither. Whether an API <em>can</em> be reused comes down to concrete, checkable things, and whether it <em>is being</em> reused is sitting in your gateway logs right now.</p>
        <p class="mb-3">I assess your API estate against a written, weighted rubric across three axes &mdash; the design of the interface (can a stranger build against it), the operational anatomy (can they find it, get a key, and try it in a sandbox without a meeting), and its composability (can an agent reuse it as a capability). I run duplication detection across the whole portfolio, semantically, so the same capability hiding under different names surfaces. Then we name your capabilities, map the implementations to each one, and choose canonicals with adoption data in the room &mdash; turning &ldquo;we have sprawl&rdquo; into decisions your organization can actually make.</p>
        <p class="mb-3">The rubric is yours to keep and tune &mdash; a governance artifact your teams can score themselves against long after the engagement ends. The method is the same one behind my paper on the subject and the free assessment tool at <a href="https://reusability.apicommons.org">reusability.apicommons.org</a>, calibrated against hundreds of real public API programs.</p>

        <h2 class="fs-6 fw-semibold mt-4 mb-2">What you walk away with</h2>
        <ul class="text-muted">
          <li>A scored inventory of your APIs across design, operational, and composability axes</li>
          <li>A duplication map &mdash; the same capability under different names, made visible</li>
          <li>A capability map with canonicals chosen on adoption, and a consolidation roadmap</li>
          <li>Your reusability rubric &mdash; written, weighted, and published for your teams to run</li>
        </ul>
      </div>

      <!-- Related reading -->
      <div class="mb-4" style="max-width: 46rem;">
        <h2 class="fs-6 fw-semibold mb-2">Related reading</h2>
        <ul class="text-muted mb-0">
          <li><a href="https://papers.apievangelist.com/papers/fundamentals-of-api-reusability/">The Fundamentals of API Reusability</a> (paper)</li>
          <li><a href="https://reusability.apicommons.org">reusability.apicommons.org</a> &mdash; the free, browser-based assessment tool</li>
        </ul>
      </div>

      <!-- CTA -->
      <div class="card border-0 shadow-sm mt-4" style="max-width: 46rem;">
        <div class="card-body">
          <h2 class="fs-5 mb-2">Let's work together</h2>
          <p class="text-muted mb-3">If you cannot say how many times your organization has built the same API, let's find out together.</p>
          <p class="mb-0"><a href="mailto:info@apievangelist.com?subject=Reusability%20services" class="btn btn-outline-secondary btn-sm">Get in touch — info@apievangelist.com</a></p>
        </div>
      </div>

    </section>
  </div>
</div>