--- title: We built the platform. Nobody used it | daily.dev description: A platform team leader recounts building an internal ML platform that senior engineers avoided in favor of their own workarounds, discovering eight months in... canonical: https://daily.dev/posts/we-built-the-platform-nobody-used-it-upnaymlfn twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: We built the platform. Nobody used it | daily.dev og:description: A platform team leader recounts building an internal ML platform that senior engineers avoided in favor of their own workarounds, discovering eight months in... og:url: https://daily.dev/posts/we-built-the-platform-nobody-used-it-upnaymlfn og:image: https://api.daily.dev/og/posts/UpnAYmLfN.png og:image:alt: We built the platform. Nobody used it og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # We built the platform. Nobody used it **[LeadDev](https://daily.dev/sources/leaddev)** · 8 min read · 0 upvotes · 1 comments ## Summary A platform team leader recounts building an internal ML platform that senior engineers avoided in favor of their own workarounds, discovering eight months in that low adoption reflected broken trust rather than insufficient training or communication. The team shifted from pushing documentation and demos to observing product teams inside real sprints, opening the roadmap to team-driven prioritization, and having leadership publicly own the adoption failure. These moves, paired with a workflow-oriented handbook and metrics like time-to-first-production-deployment and platform NPS, gradually rebuilt voluntary adoption, echoing a similar pattern Spotify described with its ML Home platform. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why do engineers avoid using an internal platform even after training and documentation are improved? Low adoption often signals broken trust rather than a skills gap, so more training does not fix it. Engineers who tried a platform early, hit friction, and reverted to their own workflows are behaving rationally because every retry carries a cost of testing whether the platform has actually improved. Rebuilding confidence required observing real sprints, opening the roadmap to team input, and having leadership own the failure. _Anyone debugging low tool adoption on their team can find similar leadership lessons curated on daily.dev._ ### What metrics help measure whether an internal developer platform is regaining trust after low adoption? Two paired metrics were used: platform net promoter score (NPS) to gauge whether engineers would recommend it, and a concrete workflow milestone requiring a team to move its first model to production within a day. NPS alone risked becoming a vanity number, so tracking it alongside the workflow milestone and direct feedback showed both whether the path was shorter and whether confidence was returning. _Teams choosing how to measure platform health can compare approaches like this through daily.dev._ ### How did Spotify improve adoption of its internal ML Home platform? Spotify's ML Home initially failed to grow beyond early adopters because users did not see enough depth to abandon the tools they already used. After the team deepened the product around real machine learning workflows, daily active use roughly tripled over the following year, illustrating that awareness campaigns cannot substitute for a product that earns a place in daily work. _Engineers deciding how to grow internal tool usage can track case studies like Spotify's on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@nark3d** · 0 upvotes > Eight months of silent workarounds before anyone noticed. How you tell broken trust apart from the platform just not being good enough yet, since both look identical from the adoption numbers? Did the teams who came back do so because the roadmap moved, or because they eventually hit a problem their workaround couldn't solve? If it was the second one, opening the roadmap reads less like the fix and more like permission to wait. ## Similar posts on daily.dev - [Most platform teams build products, but they don’t know it](https://daily.dev/posts/most-platform-teams-build-products-but-they-don-t-know-it-j3fxzv0xy) · The New Stack · 1 upvotes · 0 comments - [Developing and Deploying a Platform that the Business Understands and Developers Actually Want](https://daily.dev/posts/developing-and-deploying-a-platform-that-the-business-understands-and-developers-actually-want-xvkxwovd6) · InfoQ · 0 upvotes · 0 comments - [Why I stopped treating AI adoption like a tool rollout](https://daily.dev/posts/why-i-stopped-treating-ai-adoption-like-a-tool-rollout-2izmxjdcp) · LogRocket · 0 upvotes · 0 comments - [Platform Engineering at scale: Lessons from the conference circuit](https://daily.dev/posts/platform-engineering-at-scale-lessons-from-the-conference-circuit-ucb3ep9ps) · OctopusDeploy · 7 upvotes · 0 comments - [8 platform engineering anti-patterns](https://daily.dev/posts/8-platform-engineering-anti-patterns-hdjhwze8h) · InfoWorld · 2 upvotes · 0 comments --- Tags: [#machine-learning](https://daily.dev/tags/machine-learning), [#leadership](https://daily.dev/tags/leadership), [#platform-engineering](https://daily.dev/tags/platform-engineering) [View this post on daily.dev](https://daily.dev/posts/we-built-the-platform-nobody-used-it-upnaymlfn) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"We built the platform. Nobody used it","url":"https://daily.dev/posts/we-built-the-platform-nobody-used-it-upnaymlfn","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/we-built-the-platform-nobody-used-it-upnaymlfn"},"datePublished":"2026-09-15T08:05:34.342Z","dateModified":"2026-09-15T08:06:01.489Z","description":"A platform team leader recounts building an internal ML platform that senior engineers avoided in favor of their own workarounds, discovering eight months in...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1d2b8f02ec430baf1bf8caaf989ce021?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/1d2b8f02ec430baf1bf8caaf989ce021?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"LeadDev","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"LeadDev","logo":"https://media.daily.dev/image/upload/s--u_Q34nzh--/f_auto,q_auto/v1774514111/logos/leaddev?_a=BAMAMiWQ0","url":"https://daily.dev/sources/leaddev"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/we-built-the-platform-nobody-used-it-upnaymlfn","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"machine-learning,leadership,platform-engineering","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"LeadDev","item":"https://daily.dev/sources/leaddev"},{"@type":"ListItem","position":3,"name":"We built the platform. Nobody used it"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/we-built-the-platform-nobody-used-it-upnaymlfn","comment":[{"@type":"Comment","text":"Eight months of silent workarounds before anyone noticed. How you tell broken trust apart from the platform just not being good enough yet, since both look identical from the adoption numbers? Did the teams who came back do so because the roadmap moved, or because they eventually hit a problem their workaround couldn’t solve? If it was the second one, opening the roadmap reads less like the fix and more like permission to wait.","datePublished":"2026-09-27T10:28:06.915Z","url":"https://daily.dev/posts/UpnAYmLfN#c-vypuRRxxZ","author":{"@type":"Person","name":"Adam","url":"https://daily.dev/nark3d","image":"https://avatars.githubusercontent.com/u/2162621?v=4"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/we-built-the-platform-nobody-used-it-upnaymlfn#faq","mainEntity":[{"@type":"Question","name":"Why do engineers avoid using an internal platform even after training and documentation are improved?","acceptedAnswer":{"@type":"Answer","text":"Low adoption often signals broken trust rather than a skills gap, so more training does not fix it. Engineers who tried a platform early, hit friction, and reverted to their own workflows are behaving rationally because every retry carries a cost of testing whether the platform has actually improved. Rebuilding confidence required observing real sprints, opening the roadmap to team input, and having leadership own the failure. Anyone debugging low tool adoption on their team can find similar leadership lessons curated on daily.dev."}},{"@type":"Question","name":"What metrics help measure whether an internal developer platform is regaining trust after low adoption?","acceptedAnswer":{"@type":"Answer","text":"Two paired metrics were used: platform net promoter score (NPS) to gauge whether engineers would recommend it, and a concrete workflow milestone requiring a team to move its first model to production within a day. NPS alone risked becoming a vanity number, so tracking it alongside the workflow milestone and direct feedback showed both whether the path was shorter and whether confidence was returning. Teams choosing how to measure platform health can compare approaches like this through daily.dev."}},{"@type":"Question","name":"How did Spotify improve adoption of its internal ML Home platform?","acceptedAnswer":{"@type":"Answer","text":"Spotify's ML Home initially failed to grow beyond early adopters because users did not see enough depth to abandon the tools they already used. After the team deepened the product around real machine learning workflows, daily active use roughly tripled over the following year, illustrating that awareness campaigns cannot substitute for a product that earns a place in daily work. Engineers deciding how to grow internal tool usage can track case studies like Spotify's on daily.dev."}}]} ```