A few weeks back I was talking to a friend trying to compare competing MCP servers, and the whole thing took maybe four minutes. He opened both GitHub repos side by side, glanced at the README, checked the last commit date, scrolled the issues to see if anyone answered them, looked at whether there was an llms.txt, and picked one. No demo call. No sales deck. No trial. The repo was the pitch, and one of them lost before its maintainers ever knew they were in a race.
That four minutes is what I keep coming back to. It is also why I'm changing what Smoower measures.
I built the wrong frame first
When I started Smoower, I framed it as a DevRel index. Make the invisible work visible, give the discipline an S&P 500, help teams defend their budget. I still believe in that. But the framing was aimed at the wrong reader.
DevRel teams are not the only ones reading your public surface. The bigger audience, the one that grew fastest in the last year, is everyone who decides whether to build on you. Developers, sure. But also the AI assistants those developers point at your repo. When someone asks Claude or Copilot "should I use this SDK", the model goes and reads the same GitHub footprint my friend read, and forms the same kind of judgment, faster.
So a DevRel scorecard was too narrow. The thing being measured is not "how good is your developer relations team." It is "how strongly do you show up in the public places where builders and their AI assistants decide whether you're worth trying." I've started calling that builder mindshare, and I think it's the honest name for what the index was always circling.
(Yes, "mindshare" is a slightly marketing-flavored word and I sat on it for a while. I kept it because it's the one word that captures both the human attention and the machine attention at once.)
The two questions
Here is the part I'm actually excited about. When you strip away the dashboard and the sub-scores, every builder evaluating you is asking two questions, in this order.
Is this good enough to build on? That's everything you control. Your code, your docs, your samples, whether an AI can even parse your repo cleanly. You can fix all of it this week if you decide to. I'm calling this group Foundation.
Is the ecosystem paying attention? That's the response you don't control directly. Whether anyone's talking about you on HN or Reddit or YouTube, whether contributors show up, whether issues get answered fast. This is Traction.
Foundation is the thing you ship. Traction is what comes back.
That split is the whole point. A company can be strong on one and weak on the other, and the two failure modes look nothing alike. Great docs sitting on a dead community is a different problem from a buzzing community sitting on top of a stale, unreadable repo. The first means you built something good and nobody noticed. The second means people noticed and you're letting them down. Collapsing both into one number hid which one you actually have. Splitting them tells you where to spend your next month.
What each side is made of
Foundation comes down to your code and adoption, your education (the README, the docs, and how readable those docs are to an AI), your builder experience (samples, templates, the onboarding path), and your AI readiness (llms.txt, hosted MCP, whether assistants can discover and use you at all). That last one was a footnote a year ago. Now it's one of the first things that four-minute look checks, so it gets its own pillar.
Traction is your reach (HN, Reddit, Dev.to, YouTube, mentions, content written about you), your community (contributors, discussions, programmes, the people actually doing things with you), and your momentum (activity cadence, and how fast issues get a reply, which turns out to be one of the sharpest health signals there is).
Sentiment runs across all of it as a lens rather than a score of its own. I went back and forth on that. For a while I had it as its own pillar and it kept producing backwards results, ranking a warm low-volume project above a busy one with normal sentiment. So now it colors the reach and community signals instead of competing with your code for a slot.
What you actually get out of this
The reason to do any of this is that the number becomes something you can act on instead of just stare at.
If your Foundation is high and your Traction is low, the work isn't more docs. It's distribution. Go write the post, do the talk, answer the threads. If it's the other way around, stop chasing reach and fix the thing people keep bouncing off. One score never told you that. Two groups point at a specific next move instead of a vague "do better."
It also gives you a fair fight. You can line yourself up against the companies builders actually compare you to and see, pillar by pillar, where you're ahead and where you're quietly losing the four-minute test. Most teams have a gut feeling about this, and the gut feeling is usually wrong in at least one place.
Where the paid product comes in
Up to now Smoower has been free to browse, and the public index stays that way. But a score on its own is a diagnosis, not a treatment, and a lot of the people who found their page have written to ask the obvious next question. Okay, now what do I do about it.
So the next thing I'm building is a paid tier for companies that want help moving the number, not just reading it. The rough shape:
- Your pillars, broken down into the actual gaps. Not "AI readiness: 41". The specific missing
llms.txt, the docs pages an assistant can't parse, the onboarding step where forks stall. A work list, ranked by what moves the score most. - Competitor comparison that goes past the leaderboard. Side by side on every pillar against the companies you actually lose to, including which way the gap is trending, so you see someone catching up before they pass you.
- Tracking over time, with alerts. When a pillar slips or a competitor jumps, you hear about it instead of finding out next quarter.
- A Discord bot that makes Discord countable. So much real community lives in Discord and none of it shows up in a public crawl. The bot sits in your server and turns the parts you'd want measured anyway, response times, who's answering, which questions go cold, into Traction signals you can actually see.
- A hook into your own onboarding. Connect your signup or activation funnel and we line the public picture up against what's really happening in the product. Did that spike in reach turn into anyone trying the thing? Is your Foundation work showing up as fewer people bouncing in the first ten minutes? The point is to stop guessing whether the public signals connect to real usage and just check.
- The summary a board will read. The plain-English "here's what changed and why" write-up I wish I'd had in the budget meeting that started this whole project.
I'm being deliberately slow on pricing and packaging, because I don't want to ship another dashboard nobody trusts. If you run developer-facing growth somewhere and you'd genuinely pay for this, I want to talk while it's still soft enough to shape. That feedback is worth more to me right now than a launch date.
Honestly
Regrouping the pillars changes how the overall score rolls up, even where the raw measurements didn't move. I'd rather say that plainly than have your number shift one day with no explanation. The weighting across the new groups isn't locked yet, and I'll publish it when it is so anyone can check the math against their own page.
If you run a company that builds something developers or AI assistants pick up, go look at your page when this lands and tell me where the grouping feels off. The two questions I can defend. The weighting I can't yet, and that's the bit I want pushback on before it hardens.