Six months after launching an internal developer portal, weekly active usage has plateaued at around forty percent of engineering. How would you go about figuring out why, and what would you actually do about it?

Short answer

Stalled adoption is rarely a UI problem; segment usage by team and task rather than the aggregate number, then match the fix to whichever of three causes shows up - a missing daily task, a faster existing habit, or data nobody trusts.

Resist explaining the aggregate number

Forty percent weekly active usage is a single figure covering what is almost certainly a very uneven distribution, and treating it as one problem to solve is the first mistake. Before proposing anything, split it: by team, by tenure since the portal launched for that team, and by which feature was used. A platform serving on-call engineers a service catalog they check during every incident and serving product engineers a scaffolding tool they touch twice a year will show very different usage shapes even if both are working exactly as intended. A single aggregate number flattens "used constantly by the people who need it" and "opened once during onboarding and never again" into the same figure, and those have entirely different fixes.

The next split that matters is trajectory, not just current level. A team that never used the portal is a different problem from a team that used it heavily in month one and dropped to nothing by month four — the first is an awareness or relevance gap, the second is a trust or habit failure that happened after they gave it a real try. Pulling usage logs segmented this way, before forming any hypothesis, is the difference between diagnosis and guessing.

Team category               Pattern seen                     Likely cause
--------------------------  --------------------------------  ---------------------------
Adopted, still using        Steady weekly usage               Working as intended
Adopted, then dropped       High in month 1, near zero by 4   Data went stale, or a
                                                               faster alternative exists
Never adopted               Near zero from week one           Doesn't cover their task,
                                                               or they never heard of it

The three causes that actually produce this pattern

Once the split is done, the candidates worth investigating narrow to a small set, and each has a distinct signature.

The portal doesn't do anything a given team needs daily. A service catalog is compelling to whoever is on call and needs to find an owner at 2am; it's nearly irrelevant to a team that ships features and rarely touches another team's service. If the "never adopted" segment clusters around teams whose daily tasks the portal simply doesn't serve, the fix isn't marketing — it's building or surfacing a feature relevant to that segment, or accepting that this portal isn't for them.

The portal duplicates something people already do faster. If engineers can find who owns a service by asking in a Slack channel with a fast answer, a portal that requires navigating to a page and running a search is strictly slower for that specific task, and habit will always win against a marginally worse alternative unless the old path is actively removed or degraded. This shows up as a team that tried the portal, found the old way faster, and reverted — the "adopted, then dropped" pattern above, specifically for tasks with a fast informal alternative.

The portal's data is wrong often enough that people stopped trusting it. This is the most damaging cause because it is self-reinforcing: the first time someone pages a listed owner and gets nothing, they don't file a bug against the catalog entry, they just stop using the catalog and go back to asking around. A handful of stale entries can poison trust across an entire team well before the aggregate staleness rate looks alarming in a dashboard.

flowchart TD
    A[Weekly usage plateaued at 40%] --> B[Segment by team and task]
    B --> C{Never adopted vs<br/>adopted then dropped}
    C -- Never adopted --> D[Task not covered,<br/>or unaware it exists]
    C -- Dropped after trying --> E{Faster informal<br/>alternative exists}
    E -- Yes --> F[Habit beat the portal;<br/>remove or slow the old path]
    E -- No --> G[Data was wrong;<br/>trust collapsed]

Matching the fix to the cause, not to the symptom

The failure mode in how organisations respond to stalled adoption is applying a generic engagement fix — a leaderboard, a mandate to use the portal, a Slack campaign — to a problem that is actually one of the three specific causes above. A mandate forces usage of a tool people have already learned is unreliable or irrelevant to their work, which produces resentment and workarounds rather than genuine adoption, and it burns the platform team's credibility for the next thing they ship.

The correct response is scoped to whichever cause the segmentation surfaced. If the gap is coverage, the fix is shipping the specific feature the uncovered segment needs, validated with that segment before building it broadly.

If the gap is an informal alternative winning on speed, the fix is either making the portal path faster than the informal one for that specific task, or in some cases actively degrading the informal path — turning off the Slack bot that answered "who owns this" — which is uncomfortable to propose but is sometimes the only thing that actually shifts a habit.

If the gap is trust, no feature work matters until the underlying data quality is fixed and demonstrably fixed, because the trust deficit does not repair itself just because the data got better quietly.

Forty percent is not a problem to solve directly; it's an average masking several different, smaller, and much more tractable problems.

© 2026 Preptima. Originally published at preptima.com.