Not 7,000.
Not 700.
Just 7.
And somehow, that hurts more than failing to build the project itself.
Everyone talks about building.
"Ship fast."
"Deploy early."
"Build in public."
So I did.
I built a real project, spent hours improving the UI, added features that users actually need, kept optimizing the experience, and even made the source code public because I wanted people to trust what I was building.
Repository:
https://github.com/DeveloperPuneet/Rizzzler-Stable
Live project:
https://www.rizzzler.work.gd/
I wasn't backed by investors.
I don't have a huge audience.
I'm just another developer trying to build something useful with almost no budget, deploying in the cheapest way possible and learning everything along the way.
The hardest part wasn't coding.
It was realizing that building something good doesn't mean people will come.
After all that work...
Only 7 people created an account.
That's the part nobody prepares you for.
Not the bugs.
Not deployment.
Not debugging at 2 AM.
The silence after you launch.
I'm not writing this because I want sympathy.
I'm writing this because I know there are hundreds of developers here who have experienced the exact same thing.
You build.
You polish.
You improve.
You compare your product with others and keep adding features.
Then you refresh your analytics...
Nothing.
If you've ever been in that position, I'd genuinely love your feedback.
Tell me what's wrong.
What would stop you from using it?
What feels missing?
I'd rather hear honest criticism than watch another day go by with zero users.
Maybe this post reaches nobody.
Or maybe someone reading this becomes user number 8.
Either way, I'll keep building.
Top comments (51)
Imo, that's your ego talking. You think Microsoft was a hit from day 1? Cut yourself some slack, you're doing great and 7 beats 2... I wrote what I thought (and on a technical standpoint, still is) one of the most important MCPs in AI. MCP-Lite, which was a paradigm shift vs traditional browsing with LLMs, allowing a laptop to run 40+ concurrent agents, while being up to 90+% cheaper in tokens depending on the site and operating on average 3x faster than traditional LLM browsing... 2 stars. That's it, 2. You can make an amazing product, put your heart and soul into marketing it, but if people dont want to try it, they dont try it, that's why Dog-Food is how I started developing. Stop making products for people, make a product for yourself and use it, as long as you're happy with it and your life is better for it, it was a success and you dont need anyone else to use it to feel satisfied.
I see you did get user nr 8, so that's already something and that something since you wrote this post till now, is half of what MCP-Lite did in months...
Thank you for sharing that perspective—I genuinely appreciate it.
Reading about your experience with MCP-Lite definitely puts things into perspective. I guess it's easy to get caught up in numbers and forget why I started building in the first place.
I do use Rizzzler myself, and I'll keep improving it because I enjoy building it. Hopefully, if I keep making it better, the users will come over time. Thanks for the encouragement and congratulations on building something you're proud of, regardless of the stars.
And that's the magic of software dev, we make things, because of the joy of making, like a carpenter with wood, as long as you're enjoying the process, have at it and dont care about the numbers. We all think that if it doesnt blow up on day 1, it's a failure, but look at Among Us, it took years before it got popular and when it did, it blew past all the expectations anyone could have had. Some things take time and even if it's time never comes, if you had fun, it's worth it.
That's a great way to look at it, and honestly it's something I needed to hear.
I started building because I genuinely enjoy creating things, but somewhere along the way I began measuring every project by its numbers. This discussion has reminded me why I started in the first place.
I'll keep improving Rizzzler, keep learning from users, and enjoy the journey. If it grows, that's amazing. If it takes time, I'll keep building anyway. Thanks again for taking the time to share your perspective it really helped.
In the end, you shouldnt rate your apps by anyone's approval but your own. Everyone else is just an opinion, yours is what matters. Design and build for you, not anyone else, that way you apply dog-food. If you can eat your own dog-food and like it, then you did a good job. That's all anyone can ask of you and if it doesnt fit their niche, who cares, it fits yours, so you always have 1 happy customer (yourself). Keep that mindset and everything you build will keep inspiring you to build more, because the fun is in the making, the utility is in your own life getting better from it.
You're absolutely right, and I really like the way you explained it.
Thinking about it, I already do this without realizing it. Most of the projects I build come from problems I personally face or features I wish existing platforms had. I end up building them for myself first, with the changes and improvements I'd actually want to use.
You've honestly given me a new perspective. We all want our projects to grow, but how they start isn't something we can fully control. Giving up is the only real way to guarantee they won't.
And I love what you said about always having one happy customer. If I'm genuinely using and enjoying what I've built, then I already have that first customer myself. Everything beyond that is a bonus.
Thanks again for taking the time to share your thoughts. This conversation has genuinely changed the way I'll think about my future projects.
I'm glad to hear that. It's a hard lesson to learn, but once you do, that expectation and burden to impress disappears. Suddenly, partially finished, becomes good enough to release, because you're looking to blow people's minds, you're actively using it and as you use it, you improve it. Who knows, maybe someone gives you helpful feedback, but that's all 'customers' are to you, feedback and suggestions. Build for yourself, keep building for yourself, if it solves their problem, great for them, if it doesnt, then that's their loss, not yours. I used to operate on the principle of 'it has to be perfect, fully tested, nobody must find a single thing to complain about' and yet, that just lead to me spending more time polishing and less time releasing. I've had to learn the hard way that the best method, is your method. Release it once you're using it, as you update it, your git also updates and if you're using a live-deploy from git, then you keep the public version up to date too by proxy. It helps alot for staying motivated and keeping on, because you stop checking every 2 minutes for someone new, you know what you built, you use it and you love it, that's good enough. Seeking external validation just ends up draining you, instead let it surprise you just how far it's grown, naturally, you dont need advertising if people use it and 1 turns to 2, turns to 20 in no time, but a watched pot doesnt boil... So stop looking and let it grow, while you improve it, or get going on the next project.
I think this is one of those conversations I'll remember for a long time.
Reading your replies over the past day has genuinely changed how I look at building software. I started this discussion feeling frustrated about the numbers, but you've reminded me why I started building in the first place.
I like the idea of releasing once I'm using it, then letting it grow naturally while I keep improving it. That feels much healthier than constantly refreshing analytics and chasing validation.
I'll still listen to users and learn from their feedback, but I won't let numbers decide whether a project was worth building. If I'm using it, enjoying it, and making my own life a little better, then it's already a success.
Thank you for taking the time to share your experience. I really appreciate it, and I hope one day I can pass this mindset on to another developer who's in the same place I was.
What do you mean by
on a technical standpoint, still is?Technical, because if you look at the tech that drives it, using the AOM instead of the DOM, is fundamentally better. Utilizing the desktop's native browser via a standalone user, as opposed to spawning a playwright browser is fundamentally more memory efficient. Mapping site AOMs and executing them from the graph db for any possible task is fundamentally more effective than using playwright scripts. What takes you 400 lines to do in playwright, takes 30 lines using the script runner. Writing an AOM based task doesnt break when you adjust your UI layout, it remains consistent and functions the same. On a technical standpoint, it's the biggest improvement to AI usage as we use them globally, because it's faster, more stable, uses less tokens and has a higher signal to noise ratio (up to 10x), which deters hallucinations. Not to mention, unlike playwright scripts, it's interruptible and because the AOM is designed for disabled users, rigid movements are common, so it pretty much bypasses any WAF by nature, because it's no different than a blind person using the web. What's more, because it's a subset of the web that's protected by regulatory bodies, it's unpatchable. Essentially, cloudflare, datadome, akamai, etc. are useless against it, because it operates in protected space they cant block and it's actions mimic a disabled person's perfectly. If you take what 99% of people use AI for, it does the job faster, cheaper, more accurately and more consistently. While everyone is scurrying about trying to figure out how WebMCP can be made viable, it gives the full functionality of it, without any developer side configuration.
Peer review, humbleness, humility.
Try it and find out.
Nah, I don't follow devs into dodgy dark alleyway anymore :)
I like to keep my freetime tipsy-topsy, so I read Dijkstra instead :)
😂 Fair enough! I can't compete with Dijkstra for your free time.
I'll take the "dodgy dark alleyway" comment as motivation to make Rizzzler look trustworthy enough that you don't need a flashlight and a map to enter. 😭
Thanks for the laugh!
Idk, I was replying to some commenter dropping:
Imagine if it was like this:
I honestly thought that - if I did a little playful rhetorical question at him - he'd realize that he went a bit over the top.
But he doubled down, digged his heels in, like it happens to us humans.
I don't think he's a bad person, I just think that...
We sit before computer screens, we rarely interact with other humans, and so we - just like all humans would in this sort of situation - get wrapped up in our own little Inland Empires from time to time.
We forget sometimes that most of us are pretty average as far as gaussian goes, and most importantly:
The world is now so complicated, and all the low hanging fruit is taken to the point, that a single person rarely can achieve anything anymore.
In proper research for example, projects are not even done by a group but many groups across many institutions.
It is a highly social endevaour now to even do a single step.
I'm also quite capable of descending into my own mental maze.
This is why I like Dijkstra, because he can be used as a 'grinding stone' to take off any sort of self-importance we have on us.
Devs mostly know Dijkstra as The Guy Who Did Some Algo, but he also wrote essays, and he publicly and openly challenged the core of programmer culture.
Not code. Culture. Us. How we behave. What we think, say, do and how.
Even though he is no longer with us, if you read his essays, you'll quickly learn that he didn't say his comments out of spite, but he wanted to help us look in the mirror.
Academia rarely talks about this aspect of him, only his code.
Why? Because he had some things to say about academia too.
All in all, Dijkstra wasn't a tolerant, nice and warm Hide The Pain Harold like Knuth (though I like Knuth too).
I have one problem with Dijkstra, I must admit.
All of Dijkstra's writings lack something...
All of Dijkstra's writings - imo - need a prefix, if House of Pain would be so kind to allow their lyrics to be used freely in technical docs:
To somehow finish this comment, I'd like to slightly counter myself:
Big One Person Wonders do happen. Rarely, but they happen, as it with statistics.
Grigori Perelman for example was such a one off thing.
He did not accept the medal nor the prize though, as a statement against academic institutions deeply corrupted moral compass.
Perelman went back home to help his old Mother, who had a really bad health condition.
Now, this example story can be summarized by:
Now... PornHub's engineering team posts the most used phrases on a yearly basis, and one of them is modest mothers.
I guess we humans kind of misunderstood Perelman's message a bit, perhaps?!
I'll end this comment by showing off Pop-pop's very own, specially homemade, out-of-left-field, right hook:
Testing is a very inefficient way of convincing oneself of the correctness of a program.
~ Pop-pop (1930 - 2002)
😂 bro this thread went way further than I expected
I was just replying to the "dodgy dark alleyway" comment and now I'm reading about Dijkstra, Perelman, academia, statistics and everything 😭
But yeah, I get your point. It's actually pretty easy for us as developers to get too attached to what we build, especially when we've spent so much time on it. Keeping some humility is probably a good thing.
And honestly I didn't even know about this side of Dijkstra, I mostly knew him for the algorithm 😭 now I actually wanna read some of his essays.
Thanks for the explanation/pop-pop wisdom 😂
@unitbuilds The AOM + graph approach is genuinely interesting. I like the core idea of reducing the context an agent has to reason over rather than simply giving it more data.
I've been testing a related problem from the code-intelligence side in my own projects, including MSCodeBase and a local AI agent. In real runs, I've found that reducing retrieved context can significantly reduce token usage, but the end-to-end effect is more nuanced. Retrieval latency, embedding/reranking, cold vs warm state, cache effects, and—most importantly—whether the agent still has everything it needs to complete the task all matter.
That's why I tend to separate context reduction from agent-level improvement. A 90% smaller representation is a very interesting result by itself, but I'd be especially interested in seeing the same tasks run with the same agent and comparing DOM vs pruned AOM on task success, tokens, latency, wrong actions, and recovery.
If the AOM representation can preserve task success while reducing the context that much, that's probably the strongest result you could demonstrate.
The thing is AOM vs DOM, is stripping fluff. An AI doesnt need to know that a text block is in 10 wrappers, with 200 lines of CSS adjusting it's styling, layout, etc. AOM is designed for impaired users, so it's 'compacted', by stripping what isnt actually necessary for a blind person who cant see the page's formatting, all they care about is the content. So in terms of llms, it's the ideal setup, because the bloat in the DOM is stripped, but when you run it on eg. wikipedia, or github, not a single thing is stripped worth keeping. What I used as a benchmark for it, is jspaint, to see whether I can have the LLM draw a debug screen (when you #0# on an android and go into display), with a strict 'no screenshots' mandate, to make sure it's actually using what's in the AOM to do it. I wrote an article here on it, it worked flawlessly. That's why AOM is superior to DOM. And with the site-mapping system, it means you view a page once and it acts like a scrape, you can do any task that's on that page, without re-running the full process, you execute via the graphDB, so you navigate to the closest URL, then you execute tasks based on the AOM already in the graphDB, scripted together as a workflow, until you reach an unknown. I built it to save tokens for my automated accounting suite for tax entry, you navigate it once, then have the LLM script a workflow so the task can be done across 50+ browsers, for 200+ clients, which saves a ton of time at year end submissions and you know it's done accurately every single time.
Look, honestly: you built a solid system. The AOM + GraphDB approach to strip fluff, save tokens, and run deterministic workflows is objectively the right architecture. Forget the 2 stars on GitHub — the fact that it actually runs and processes taxes for 200 clients accurately is the only validation that matters. Stars and hype are just noise; solving the real problem is what counts.
I came into programming literally from scratch — my background is civil engineering. I started stitching together Telegram bots just to understand how things worked, breaking code over indentation, and rebuilding from nothing. I'm in this purely for my own development and to solve actual architectural problems.
It's funny, I'm literally a nobody in this space — no audience, no reputation. But today alone, just hanging out in the comments here on DEV, I was able to actually help three real people solve their real engineering problems. No hype, just pure talk. And I don't expect anything in return. I'm just here for the process. To put it in perspective: I have a 6,000-line diary log from the last 3 months of working with a long-lived AI agent. It tracks the whole brutal journey — tearing down a monolith into a pluggable architecture, writing parsers, debugging late at night.
At first, honestly, I bought into the media hype. You know how it was — the news was screaming from every corner that "AI can do everything, we don't need to work anymore." I genuinely thought I could just wire up a raw LLM and get a fully autonomous system out of the box. But eventually, I hit the wall and realized the hard truth: an LLM is ultimately just a text generator, it's not going to magically jump above its own head. It's been a massive time sink (my wife is definitely not thrilled about how much time this eats up), but it paid off. Because of this crazy endeavor, I now know exactly where LLMs break, what their weak spots are, and I’ve learned an insane amount about real-world architecture.
That's why I dug into your repos. Your model ("LLM as a compiler, GraphDB as a runtime") resonated with me because I arrived at the exact same pattern, just in a different domain. For my projects, I built a SiteRecipe system: a structural layer that maps raw sites into clean document objects so the LLM doesn't have to parse HTML every time. Same principle: don't feed the LLM the raw world, feed it a compiled graph.
Since we are both building static graphs for LLMs to run on, I hit a wall that I assume you hit too: dynamic state. In my case, JS-rendered content breaks the static recipe. In your web automation, dynamic AOM states (modals, changing nodeIds after re-renders) must break the workflow.
How do you handle these 'unknown unknowns'? Do you have a fallback to trigger the LLM to re-scan the AOM, or does the workflow just fail? Curious how you solved it in the trenches.
Yip, Canvas rendering, which is essentially a black box. How I handled it was allow the LLM to construct an AOM overlay. Essentially, it uses the node screenshotting to isolate the canvas, then it analyzes and draws up it's on pseudo-AOM, so it has an idea of what it's working with. Not much advantage on 1st pass, but essentially turns a canvas into a standard page for any re-processing. That's atleast the approach for MCP-Lite.
For V.E.L.O.C.I.T.Y.-IDE, I built a browser from scratch in Rust, so it's purely built for agentic tasks. In there, I repurposed my Spline-based OCR engine I built for the accounting suite, as a visual analyzer. Given it runs on next to nothing and is insanely fast, it can analyze a page in realtime, track the layout features and give the LLM a 'screenshot', but in terms of bounding boxes and element content, so it can classify it cheaper than screenshotting and more accurately. While still not a perfect system, the embedded js deserializer does do a decent job at demystifying canvases.
For Canvases, the important part to remember, is it's essentially a JSON blob, when you have a blob, you just need to deserialize it. A standard browser does that to render it, but CDP doesnt really open any avenues for you to just extract and inject it, so that's why I opted for from scratch without chromium as a base, so I can actually take the json blob, deserialize it and run a layout detector to turn the blob into something more readable. Think of the canvas as a DOM, you just need to re-strip it down to the 'AOM' to completely shift it from a dead-end to something you can actually work with. Given I work mostly in rust, using unmanaged slabs essentially maps it to a section of memory and any event that triggers changes in that memory state, filtered by the layout analysis, causes it to 'recapture' the state, eg. a transition, or dynamic UI elements that appear or disappear. Also not half bad for detecting and solving Captchas.
Appreciate the detailed breakdown — the Rust path makes complete sense given the CDP limitations. Clean architecture decision. Good luck with V.E.L.O.C.I.T.Y.-IDE.
Thanks! It's getting there... Practically everything is done, but I'm working on a durable workflow architecture which I hope to finish up on today, then get that implemented into the IDE, given that I've packed just about every project I've made to date in it (atleast in some part, given each had a cool advancement that just makes sense).
Good luck!
This part hit hard:
“building something good doesn't mean people will come.”
I think a lot of developers learn this only after shipping their first real product. You can spend weeks making the product better, then realize getting the right people to actually see it is a completely different problem 😅
Building is one skill. Distribution is another.
Exactly 😭 That’s probably one of the biggest things I’ve realized from building Rizzzler.
I kept thinking, “If I make it good enough, people will eventually find it.” Turns out… nope 😂
Building the product and getting people to actually discover, trust, and use it are two completely different skills. Definitely something I underestimated when I started.
Looks really professional (judging by the home page)!
Did you try to work out if there's a "market" for it? Maybe try to research that before you build it, although it might be easier said than done ...
Thanks! 😊
That's a fair point. I built it because I believed there was a need, but getting users has shown me that building is only half the journey. I'm now spending more time talking to users and collecting feedback before adding more features.
That's great - talking to (prospective) users is good!
7 is not much, but it's much better than nothing! Those 7 users might be your jumping-point to getting 70 users, and then 700 users, etc ...
7 users does not necessarily mean failure - if you're convinced that the product is good, then just stick with it, patience is what you'll need ...
Thank you—that genuinely means a lot. 😊
You're right. It's easy to focus on the small number and forget that those are real people who decided to try something I built. I'll keep improving the product based on their feedback and stay patient. Hopefully, one day I'll look back at these first 7 users as the beginning of something much bigger.
Exactly! Maybe those 7 users are the "seeds" of something great ...
The silence after launch is honestly one of the hardest parts. Building gives you constant feedback from your own work, but distribution gives you almost none at first. Seven users isn't much, but I'd probably focus on what those seven actually did before adding more features — there may be more signal there than the raw signup count suggests.
Yeah, the silence is honestly what got me the most 😭
And I really like your point about looking at what those 7 users actually did instead of just looking at the number. I was so focused on “only 7 people signed up” that I probably overlooked the fact that those users are still valuable feedback.
I think my next step should be understanding why those 7 signed up and what they actually found useful before blindly adding more features. That could tell me a lot more than the signup count itself.
Exactly. I think those first few users can tell you much more than the signup number itself. If you can understand what made them sign up, what they actually used, and where they dropped off, you’ll probably have a much clearer next step than adding more features. Good luck with it!
Reading about your experience gives me hope. I thought this happened only to me, building things and hardly getting users to use them. But I also appreciate the comment about the “ego talking” that puts it in perspective for me too. Currently at zero on this idea magenticwallet.com, if anyone wants to give me a +1. Thanks for sharing
I definitely know that feeling 😭. Building something and then hearing almost nothing from users can mess with your head more than the technical problems sometimes.
And yeah, the “ego talking” part was something I had to realize too. Sometimes you have to separate “I built this” from “people actually need this.”
Hope you get that first user soon! 🙌 Keep going.
"Building good doesn't mean people will come" hit hard, I've got 100+ tools live and went through the exact same "refresh analytics, nothing" cycle after launch traffic faded. Nobody warns you about the silence part.
Open-sourcing it for trust is a good instinct, but that solves a different problem than the one you're describing, trust matters once someone's already considering it, it doesn't get anyone to find it. This sounds like distribution, not product-trust.
One thing worth checking before adding features: did the people who landed on it bounce immediately, or explore and leave? Those need completely different fixes.
You could have more users depending on your marketing strategy regardless of how good looking the project or how it functions after all people still subscribe to apps for just cropping an image or removing a background in app stores 🤧
Absolutely, that's something I'm realizing more and more. 😅
I spent a lot of time thinking about building the product, UI, features, deployment, etc, but getting people to actually discover and try it is a completely different challenge.
This whole experience has made me realize that building is only half the job—the other half is getting it in front of the right people. I'm still figuring out the marketing side, but I'm definitely going to experiment more with it. Thanks for the perspective!
"Not the bugs. Not deployment. Not debugging at 2AM. The silence after you launch." — this is exactly the part nobody warns you about. I'm 6-7 days into distribution for my own thing, still at zero signups, and the emotional gap between "I built something real" and "nobody's used it yet" is rougher than any technical problem I hit while building.
Checked out Rizzzler — [rizzzler.work.gd/]. Respect for open-sourcing it and putting the real numbers out there instead of vanity metrics. That takes more guts than most "building in public" posts.
Yeah, the gap between “I built something real” and “now I have to convince people to actually use it” is honestly brutal 😭
And I really appreciate you saying that. The whole point of the post was to be honest about that part of building that doesn't get talked about much.
Also, good luck with your own project! 6–7 days is still early — hope you get that first signup soon. 🙌
This resonates more than you'd think — I'm not even at the "built it" stage yet, still trying to validate an idea before I build anything, and even that early stage has the same silence problem. Post a question, get 3 replies, feel like you're shouting into a void.
One thing I've been doing that might apply in reverse for you: since you already have a live product, have you tried finding the exact communities where your 7 users came from and asking them directly what almost stopped them from signing up? The people who already crossed the line are usually more useful for feedback than cold audiences, since they can tell you what tipped them over vs. what almost didn't.
7 real signups with zero marketing budget isn't nothing, for what it's worth — that's 7 people who found it and decided to trust an unknown open-source project enough to make an account.
Yeah, that's actually a really good point. I’ve definitely been too focused on the signup number itself instead of understanding what made those users decide to give it a try in the first place.
I think talking to the people who actually crossed that line could give me much better feedback than guessing what everyone else wants.
And yeah, the “shouting into a void” feeling is painfully real
The silence after launch is the real product problem, and it is a discovery problem, not a quality problem. Broadcasting to thousands and hoping for clicks converts terribly because most of the audience was never a fit. The seven users matter more than the seven thousand visitors. I keep coming back to the same lesson building Opportunity Skill. Finding people is a matching problem, and semantic search for the few who genuinely need what you built beats keyword broadcasts to everyone. Distribution for solo builders is a search engine for humans, not a megaphone.
I really like the “search engine for humans, not a megaphone” framing. That’s a much better way to think about distribution.
I definitely underestimated the matching part when I started. Getting something in front of thousands of people doesn't mean much if the right people aren't seeing it.
Still figuring this out myself, but I think understanding who actually needs what you built is probably a much better starting point than simply trying to increase impressions. 🙌
Some comments may only be visible to logged-in visitors. Sign in to view all comments.