I’m building PickTests, one small browser test at a time
I recently launched PickTests, a collection of small browser-based tests for reaction time, focus, memory, speed, and coordination.
The idea started from a simple observation: many online benchmark websites are useful, but the experience often feels crowded, outdated, or inconsistent.
One test may look completely different from another. Results are sometimes difficult to understand, mobile support can be unreliable, and many pages contain more distractions than the test itself.
I wanted to build something simpler.
What I’m trying to make
PickTests is not meant to be a complicated assessment platform.
There are no accounts, downloads, or long setup steps. You choose a test, complete it, see your result, and try again whenever you like.
My goal is to make every test:
- quick to understand
- easy to start
- comfortable on desktop and mobile
- clear about the final result
- polished enough to repeat
I’m intentionally building the project one test at a time instead of adding a large number of unfinished tools.
Keeping the technology simple
PickTests is built with plain HTML, CSS, and JavaScript.
There is currently no framework, backend, database, or account system. The tests run directly in the browser.
This approach has made development easier to understand and has helped me focus on the actual interaction instead of building unnecessary infrastructure.
It also keeps the pages lightweight, which matters for a project where users should be able to open a test and start almost immediately.
## The difficult part is not building the first version
Making a basic reaction or memory test is not especially difficult.
The harder part is deciding how the test should feel.
Small details have a large effect:
- How long should each round last?
- When does a test become too easy or too frustrating?
- What information should appear in the result?
- Should the user immediately restart or review the previous score?
- How should the same interaction work on a phone?
I’ve spent more time adjusting timing, difficulty, spacing, feedback, and mobile behavior than building the initial test logic.
That process has made me realize that a small tool can still require a lot of product decisions.
What I’m working on now
The project is still early.
Right now, I’m improving the existing tests, adding clearer results, and making the experience more consistent across the website.
I’m also learning how to grow an English-language project through search traffic. This is my first serious attempt at taking a small tool website from zero traffic to something people can actually discover and use.
The next steps are to improve the current tests before expanding into more areas such as typing speed, attention, memory, and coordination.
I don’t want PickTests to become a large collection of nearly identical pages. I would rather have fewer tests that feel complete.
I’d appreciate any feedback, especially about the test experience, result pages, or anything that feels confusing on mobile.
Keeping the stack plain HTML, CSS, and JS is such a refreshingly smart choice for a micro-tool site like PickTests—the instant load times and zero-dependency footprint make for a great user experience. I tested a couple of the reaction and memory tests on mobile, and the clean design really shines without intrusive ads or bloated scripts. Congratulations on reaching $100/mo MRR already! For SEO growth, creating dedicated benchmark/percentile pages (e.g., 'Is a 200ms reaction time good?') could drive a lot of organic search traffic from people looking to interpret their scores.
I like that you're optimizing for simplicity instead of trying to launch 50 tests at once.
One thing that stood out to me is that the post clearly explains how PickTests works, but a first-time visitor is probably thinking something slightly different: "Why would I come back after taking one test?"
The product feels strongest when it's described as a place to measure and improve yourself over time, rather than just a collection of browser tests. That small shift gives people a reason to return instead of treating it as a one-time curiosity.
It's a subtle messaging difference, but I've found it often changes how people perceive a product before they've even clicked their first button.
Looking forward to seeing how it evolves.
This is a really useful distinction.
I’ve mostly been describing PickTests as a collection of browser tests, but that explains what it is, not why someone would return.
I’m starting to see personal bests, recent results, and clearer progress as part of the product rather than optional extras. The idea of measuring and improving over time gives those features a much clearer purpose.
I’ll keep this in mind as I refine the homepage and result screens. Thanks for pointing it out.
I'm glad it was helpful.
I actually spent a few more minutes looking through PickTests and noticed a few other messaging opportunities that could make the value proposition even clearer for first-time visitors.
Rather than filling your comment section with a wall of feedback, I can put together a concise homepage messaging audit with prioritized suggestions for $10. It's something I've been doing for early-stage SaaS founders who want actionable feedback without committing to a larger project.
Either way, I'm looking forward to seeing how PickTests evolves.
For timing-based tests, comparability will be harder than the UI. performance.now() helps, but display refresh rate, input device, mobile touch processing, background throttling, and the first cold interaction can shift results enough to look like user improvement. I would record device class and visibility state, add a warm-up round, report median plus spread, and explain that cross-device scores are not directly comparable. That makes the result trustworthy without adding accounts.
The one-test-at-a-time approach makes sense here. For this kind of product, I’d probably make the result screen do more of the retention work: show a personal best, a simple benchmark, and one clear reason to try again tomorrow.
That’s exactly the direction I’m moving in.
I’ve just added recent results, a personal best, and an average score to the reaction test using localStorage, so no account is needed.
I’m still figuring out the “reason to try again tomorrow” part without making the result screen feel too heavy. A simple benchmark could help, but I want to make sure the comparison is based on something trustworthy.
I like the constraint of one small browser test at a time. For early users, a tiny gallery of real flaky-test examples might make the value click faster than a broad feature list.
Thanks. I may be misunderstanding the “flaky-test examples” part.
Do you mean showing a few real test or result examples on the homepage, so first-time visitors can understand the experience before opening a test?
If so, I agree that this could communicate the value more clearly than a broad feature list.
Good luck
Thanks!
I like that you are improving one test at a time. I work in design, and I think that usually leads to a better product. One thing I would add is a simple comparison after each test. Show if the score is below average, average, or above average, and explain what it means in one sentence. Also save the last few results in the browser so people can see their progress without creating an account. That gives users a reason to come back.
Thanks, this is very close to what I’m working on now.
I’ve already added recent results, a personal best, and the user’s average score to the reaction test. Everything is stored locally in the browser, so no account is required.
The benchmark is the harder part. Reaction scores can vary depending on the device and input method, so I don’t want to show a made-up “average” just to make the result screen feel complete.
A short and honest explanation after each result sounds like a good next step.
Really great execution on this. Your point about the 'difficult part' being the feel of the test rather than the basic logic is spot on. A lot of similar web tools break entirely on mobile because of touch latency or keyboard layouts forcing the viewport to shif
Thanks, I appreciate that.
That’s exactly one of the things I’ve been noticing more as I build each test. A lot of the obvious issues only start showing up once I test the same interaction on mobile, especially around touch timing, screen space, and viewport shifts.
The logic can be simple, but the feel can break pretty quickly if those details aren’t handled well.
Love the "one test at a time" approach over shipping a bunch of half-finished tools. I made the same call building something in a similar spirit — no accounts, everything runs client-side (plain JS, no framework either). Feels slower at first, but I think it's the right tradeoff for something people just want to try and immediately understand. Are you planning to keep it framework-free even as the test count grows, or is that mostly a "for now" decision?
That’s a good question.
Right now, staying framework-free is still an intentional choice, not just a temporary shortcut. The tests are relatively small in scope, and plain HTML, CSS, and JavaScript make it easier for me to control the interaction directly and keep everything lightweight.
That said, I’m not treating it as a rule I have to defend forever. If the number of tests or shared systems grows to the point where plain JS starts slowing me down more than helping, I’d reconsider it.
For now, though, the bigger challenge still feels product-side rather than framework-side.
Great approach! Keeping it framework-free with vanilla JS is huge for an app where millisecond latency actually matters.
To boost retention without building an account system, you could save recent scores to localStorage so users can see their personal bests when they return. Also, adding a simple "Copy Result to Clipboard" text/emoji snippet would make it super easy for people to share their scores on Twitter or Discord and drive organic traffic.
Focus on quality over quantity is definitely the right call. Excited to see where you take this!
Thanks, these are both practical ideas.
Vanilla JavaScript has been enough so far, and I like having direct control over the timing and state of each test.
I’ve already been thinking about personal bests, and localStorage feels like the right fit because I want to avoid requiring accounts for now. A lightweight copy-result feature also makes sense, especially if it stays simple.
I’ve added both ideas to my list. Thanks for taking the time to share them.
The restraint around adding more tests is notable.
You’re already seeing that most of the work isn’t in making a test exist, but in understanding what makes someone want to use it again.
Exactly.
Getting the first version working is usually the quick part. The harder part is deciding whether the timing, difficulty, restart flow, and result are good enough to make another attempt feel worthwhile.
I’m learning that the return experience matters more than simply increasing the number of tests.
That makes sense. Have you started seeing any pattern from users who come back for another attempt, or is the return experience still something you're mainly figuring out?
I’m still mainly figuring it out.
PickTests is early, and the traffic is still too small for me to call anything a reliable pattern. I can compare engagement between tests, but I don’t yet have enough clean data to understand who returns later and why, especially without an account system.
My next step is probably to make the return loop more visible with recent scores and personal bests stored locally, then see whether that changes behavior. For now, I’m trying not to mistake a few repeat sessions for a real retention signal.
That’s helpful context. I appreciate you being candid about what you know versus what you’re still trying to understand.
I’d like to continue the conversation outside the thread. What’s the best email to reach you on?
Thanks, Aryan. You can reach me at [email protected].
Happy to hear what you have in mind.
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
I actually like the the
striking effect in the website is sick
Thanks! I’m glad the visual feel stood out.
I’m trying to keep the site simple without making the tests feel flat or lifeless.
I like that you resisted turning it into another giant benchmark site. Building one test at a time and obsessing over things like restart flow and timing feels like the right call for something people actually come back to.
Reading this I kept thinking it feels like the kind of project that could naturally be getting a lot more organic traffic than it probably is right now. At this stage that can change the pace of everything.
Out of curiosity what made you feel that was the hardest part so far?
That’s exactly the tension I’ve been feeling.
The basic logic behind most of the tests is usually not the hardest part. What takes much longer is deciding when a test actually feels finished.
For example, I’ve gone back and forth on whether an eight-round Reaction Time Test is enough to feel meaningful without becoming repetitive. The same questions keep appearing around difficulty, timing, mobile behavior, restart flow, and how much context to show in the result.
I also agree about organic traffic. PickTests is still very early, so I’m learning how to improve the product and make it discoverable at the same time.
I think you're on the right track. Looking at the project, I can already see a few opportunities that could help increase your organic traffic over time.
If you're interested, feel free to email me at [email protected]. I'd be happy to share a few ideas—no strings attached.
How do you currently handle your analytics and would you mind reading my indiehacker pots on how crawlers and bots are ruining analytics data?
https://www.indiehackers.com/post/i-just-discovered-my-analytics-numbers-are-mostly-fake-here-is-why-8197e3ff9d
I’m currently using GA4, Search Console, and Bing Webmaster Tools.
Traffic is still small, so I try not to read too much into the raw numbers. I mostly look at landing pages, traffic sources, and search queries to understand whether people are finding the right tests.
I haven’t done much bot filtering yet, so your post sounds relevant. I’ll give it a read.