InnerSource: Building a developer collaboration platform
A global professional services firm had a code duplication problem at scale. Teams across continents were solving the same challenges independently, with no way to find what anyone else had already built. I designed InnerSource to close the discovery gap — and the trust gap behind it.
The challenge
The firm's engineering teams were building the same code packages repeatedly across different geographies — without knowing what already existed. There was no central place to discover, evaluate, or reuse what colleagues had built.
Beyond discovery, the problem ran deeper: even when developers found an existing package, they had no way to know if it was compatible with the internal platform, who owned it, or whether it was still being maintained.
The goal of InnerSource was to give developers a single platform to find, understand, and reuse internal code packages — with enough context to trust what they were picking up.
Understanding how developers use packages
Before touching any interface, I needed to understand the real relationship between developers and code packages — from the inside.
I conducted interviews with developers across different teams to understand three things: how they actually used code packages day-to-day, what information they considered essential when evaluating a package, and which packages kept appearing across teams as repeated builds. We also mapped compatibility — which packages could realistically integrate with the internal platform and which couldn't.
- Usage patterns varied widelySome developers consumed packages passively; others modified and extended them. The platform needed to support both behaviors.
- Key information was always the sameAcross all interviews, developers consistently cared about the same things: what the package does, who owns it, whether it's maintained, and whether it works with their stack.
- Duplication was widespreadSeveral packages appeared across multiple teams with near-identical functionality — built independently because there was no way to find what already existed.
Moderated sessions with developers across different teams, seniority levels, and roles — consumers and package owners alike.
Research spanned geographies to ensure findings reflected how distributed teams actually work, not just one regional context.
Usage patterns, compatibility blockers, maintenance visibility, and what information developers actually need at the list level.
Benchmark: complex cards
Research made clear that each package carried a lot of information — more than a standard card could hold. Before designing, I needed to understand what patterns already existed for this level of complexity.
Could a card component realistically surface all the information developers needed — ownership, compatibility, maintenance status, usage — without becoming overwhelming? I analyzed platforms that handled similarly dense content to identify what patterns worked and under what conditions.
- Progressive disclosureThe most effective patterns showed essential info at the card level and reserved depth for the detail page — avoiding cognitive overload at the list stage.
- Scannable hierarchyCards that used clear typographic hierarchy and visual grouping allowed developers to evaluate relevance in seconds.
- Actionable metadataThe best references made status signals — compatibility, ownership, activity — immediately visible rather than buried inside detail views.
Design exploration & testing
With benchmark findings in hand, I moved into first explorations — putting designs in front of developers early to collect real feedback.
Feedback rounds focused on three areas: how developers navigated the platform, what information they needed visible on list-view cards, and whether the overall content felt relevant to their actual workflow. The goal was to validate direction before investing in high-fidelity work.
- Navigation: tabs didn't workDevelopers didn't identify with tab-based navigation. The mental model didn't match how they thought about exploring packages — tabs felt arbitrary and hard to scan.
- Decision: left-hand navigationMigrating to a left nav gave the interface more visual clarity and created room to scale as the platform grew. It also aligned better with how developers already navigate tools they use daily.
- Cards: less is moreDevelopers wanted to quickly assess relevance — name, type, compatibility status, and owner were enough at the list level. Everything else belonged on the detail page.
- Content relevance confirmedThe information we prioritized from research matched what developers looked for during testing. No major surprises — which validated the research findings.
Detail page & content definition
The most complex design challenge was the package detail page — each package had a different amount of documentation, and the layout had to work for all of them.
Content was variable by nature: some packages had extensive documentation, changelogs, and usage examples; others had almost nothing. We couldn't design for a fixed content model — the layout had to be flexible enough to handle every scenario without breaking.
- Right column: details and actions onlyTo bring consistency across all packages, the right side of the detail page was reserved exclusively for metadata and actions — owner, compatibility, version, links. This stayed constant regardless of how much or how little documentation a package had.
- Left column: flexible documentation areaThe main content area adapted to whatever the package provided — readme, examples, API reference, changelog — without requiring a fixed structure.
- Content dictated by the packagesRather than imposing a template, we let the actual packages define what content types mattered. The design had to be ready for all scenarios, from minimal to fully documented.
- Prepared for edge casesEmpty states, missing fields, and partial documentation were all considered — so no package would ever look broken, regardless of completeness.
The platform
The finished product — a single place for developers across the firm to find, evaluate, and reuse internal code packages across teams and geographies.
Outcomes
InnerSource's success was immediate and measurable.
Over 150 developers on the platform within six months — no mandate, no enforcement. It grew because it actually solved their problem.
Teams stopped rebuilding what already existed. Reusing proven packages cut development time by 2–3×.
Developers went from quietly solving problems alone to openly posting solutions. That shift didn't come from a policy — it came from making sharing easier than not sharing.