I Asked for Feedback, You Gave Me a Roadmap: SpeedPower. run V1 is Finally Here
A few weeks ago, I shared the beta of SpeedPower.run here on IndieHacker and Reddit. The goal was simple but ambitious: move past the "todo-list" benchmarks of the 2010s and measure how modern browsers handle Task Saturation - think 7+ concurrent AI workers, heavy JS, and the "Exchange Tax" that kills performance on high-end hardware.
We had a lot of feedback:
- You loved the concept of the "Parallel Paradox" (why your $1,500 flagship phone feels slow in the browser).
- You confirmed that the benchmarks we selected were representative of modern web app requirements.
- You pointed out some minor bugs either in the UI or when collecting data.
- Many of you asked us for a device classification and a weekly/monthly leaderboard.
Today, we are launching SpeedPower.run V1. Here is how we got there.
BUG FIXING & BENCHMARK SELECTION
First, we fixed the minor UI/running bugs. In parallel with getting your feedback, we looked deeply at the benchmark data and identified some benchmarks that were not adapted to current mobile devices due to memory requirements, in particular, the last two transformers.js models that were crashing on lots of devices, heavily impacting the global score. So, we made the decision to delete them for now (perhaps we could revive them in a V2) to ensure that every device/phone can run all benchmarks and be accurately compared. Now, for AI, we use the two AI TensorFlow.js benchmarks and the first Transformers.js benchmark.
By pruning the suite to the most rock-solid benchmarks (TFJS and Transformers.js), the entire run is now 2x faster and significantly more reliable. In the world of benchmarks, Reliability > Quantity. If a user doesn't trust the result, the numbers are useless.
NEW: DEVICE MODEL RESULTS
The biggest technical leap in V1 is our new Device Model Recognition Algorithm.
A score of "800" means nothing if you don't know the hardware. Our new engine identifies your specific device model—whether it's an iPhone 17 Pro Max, a Snapdragon 8 Elite Gen 5, or a Pixel 10 Pro. This allows us to compare scores between specific end-user device models, so we can finally answer: Is your iPhone 14/Chrome faster than your iPhone 14/Safari, or your iPhone 17/Chrome?
BUILDING THE "STATE OF BROWSERS 2026"
We aren't just building a tool; we’re building a dataset. We’ve added new infrastructure to agglomerate data for Community Results and Comparisons.
The goal? To release a definitive "State of Browsers & Devices 2026" report, add a weekly/monthly leaderboard page, and a device model comparison page. We want to show exactly where the bottlenecks live. Is Chrome still the king of WebGPU orchestration? Is Safari’s "Efficiency First" approach actually a performance ceiling for AI?
WE NEED YOUR DATA
We are looking for more data points to populate our "Top of the Month" leaderboards.
Give V1 a 30-second run: https://speedpower.run/?ref=indiehacker-2
I’d love your thoughts: As we prep our first big report, what hardware/browser showdown are you most curious about?
- iPhone 17 Pro Max vs. Galaxy S26 Ultra?
- iPhones on Safari vs. Chrome?
- Chrome vs. Brave vs. Arc Search?
- Flagship Pixels vs. Entry-level Androids?
Let’s expose the bottlenecks together. 🏎️💨
That’s a great turnaround.
I’ve literally just gone through something similar early feedback, was that my onboarding had too much friction so I added a demo mode to let people try it first.
Curious did your changes noticeably improve how people engaged or just reduce drop-off?
That’s interesting. I have just launched my product last week and I’m thinking a lot about how to handle early feedback.
Nice project 🙌
Quick question — did you ever need screenshots of websites for this?
I recently built something similar for that use case.
this is a really interesting direction, especially the “parallel paradox” angle — feels very relevant with how heavy web apps are getting
the device-level comparison + dataset approach could actually get a lot of attention if it scales
since you're already collecting data and building momentum, you could also try putting this into a competition
good way to get more visibility + validate interest at a larger level
also, prize pool just opened at $0, so your odds are the best right now
Cutting the unstable benchmarks was the right call. If the results aren’t reliable, the rest doesn’t matter. Faster runs help too since most people won’t wait around for something they don’t fully trust.
The bigger opportunity is the dataset. Once you have enough runs, the leaderboard and report become the real product, not just the test itself.
The more interesting comparison isn’t really brand vs brand. It’s the same device across different browsers under heavy load. Safari vs Chrome with multiple AI tasks running at once is where things usually break.
The community feedback → roadmap loop you ran here is exactly how good tools get built. You didn't just ask for opinions — you used the feedback to make product decisions (dropping the transformers.js models, adding device classification). That kind of responsiveness builds real advocates.
The "State of Browsers 2026" angle is smart positioning too. Data-driven reports are genuinely shareable content — developers, devrel teams, and browser vendors all have incentive to spread something that makes their stack look good (or calls out competitors). I'd double down on that narrative early.
For distribution: benchmarks and technical data like this travel really well on Twitter/X if you frame each finding as a surprising insight rather than a feature announcement. "iPhone 17 on Safari is X% slower than on Chrome for AI workloads" outperforms "We added device classification." If you're not already building a content queue around the data insights, it's worth systematizing — I use AlphaTweet (alphatweet.pro) to keep that kind of content flowing consistently without it becoming another thing to manage.
the Exchange Tax is an underrated framing - most benchmarks test peak throughput, not sustained concurrency cost. curious what the degradation curve looks like at 10+ workers.
Treating the feedback round as a roadmap rather than a todo list is the right instinct. Most people ask for feedback and then do a filtered subset of it. Sounds like you actually let it shape the scope.
The transformer.js crash issue is a real problem for modern browser benchmarks — mobile memory limits are still a nasty surprise even on high-end phones. Good call pulling those rather than leaving a broken score at the end.
What does the benchmark actually surface that existing tools like Speedometer or MotionMark don't? Curious what the use case is for someone running this today.
Thanks for the feedback! To answer your question: Existing tools are great, but they mostly measure responsiveness (Speedometer) or rendering (MotionMark). They’re optimized for the 2010s To-Do List era.
SpeedPower.run is about Task Saturation. We surface:
The use case? It's for the dev building the next heavy-duty WebApp/AI tool who wants to know: "At what point does the browser's orchestration actually break my user's experience?"
Love this approach. Letting users shape the roadmap builds loyalty fast. How did you collect the feedback?
Thanks for the shout-out. You're 100% right, the community has been the best co-pilot I could ask for.
The feedback came from two main places:
Active Listening: I hovered over the comment sections here and on Reddit, treating every bug report or feature request like a gold nugget.
Data Patterns: We watched the benchmark results closely. When we saw specific high-end phones struggling with certain AI tasks, it told us exactly what we needed to prune or polish for V1.
It wasn't always pretty, but it made the final product so much more reliable. Cheers for the support!
This comment was deleted 4 days ago.
This is a great example of building in public done right. You shared a beta, collected real feedback, made hard decisions (cutting those two transformer models), and shipped a better V1 because of it. That loop of share -> listen -> iterate is what separates products that improve from those that just add features.
Your point about reliability over quantity in benchmarks really resonates. I'm building a small indie app and went through a similar realization - I had too many features in the MVP trying to cover every use case, and cutting back to the core experience that actually worked well made everything better. Users trust a tool that does one thing reliably far more than one that does ten things inconsistently.
The device model recognition is a smart move too - context makes data meaningful. Curious about the community data angle: are you planning to let users compare their own device against the aggregate, or is the report more of a top-down editorial take?
Thanks for the kind words. It sounds like we’ve both learned that "less is more" the hard way! You’re spot on: reliability is the ultimate currency for an indie dev.
To answer your question: it's definitely about the community.
While we’ll release a "State of the Web" report with our own insights, the real magic will be the interactive comparison page. We want users to see exactly where they stand against the global average for their specific model. Data is only powerful when it’s personal!
Best of luck with your app, keep pruning until it shines!
This comment was deleted 4 days ago.
Why should a developer building a standard React app care about AI benchmarks?
Even standard apps use the same 'orchestration' logic for heavy tasks like data filtering, image processing, or complex animations. If the browser chokes on the AI workers used in the benchmark, it is likely to choke on the app's background tasks as well.
Interesting! What was the most unexpected result you've seen so far?
The biggest surprise was seeing that your browser choice can be just as powerful as a hardware upgrade! We found that switching apps could give an older phone a "second life," sometimes even outperforming brand-new models. It’s been so rewarding to show people they don’t always need the latest device to get a massive speed boost. Sometimes, the right software is all the magic you need.
What causes the difference in the Exchange score between browsers like Chrome and Safari?
The Exchange score is the 'tax' the browser charges to move data between web workers. The difference, known as the Parallel Paradox, occurs because some browsers, like Safari, are more conservative with threading to save battery, which results in a lower score even on high-end chips like the A19 Pro.