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."...
For further actions, you may consider blocking this person and/or reporting abuse
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 actually opened the live project and took a look around because your post made me curious.
The product is much more complete than I expected from the article. It is always interesting to see the gap between building something, shipping it, and then facing the much harder question of getting people to actually use it.
I think that part of the story is what makes the post work so well. The technical work can be difficult, but the silence after launch can be even harder because there is no error message telling you what to fix next.
Congratulations on making it into the Hall of Fame, very well deserved. 🎉
If you ever feel like stopping by my corner of DEV, you're always welcome. I'm also open to collaborations, so feel free to reach out if something around my work ever feels relevant.
Thanks a lot, Marco! 🙌 Really appreciate you taking the time to check out the live project. You nailed it — building and shipping are only half the journey; getting people to actually use what you build is a whole different challenge. That silence after launch definitely teaches you things no error log ever will. 😅
Thanks for the Hall of Fame wishes! 🎉 I’ll definitely check out your work too. And I’m always open to meaningful collaborations — looking forward to seeing what we might build or learn from each other!
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.
😂 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.
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 ...
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.
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.
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!
"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!
😂 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!
"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
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. 🙌
Perhaps an https would help?
Thanks for the suggestion! 😊
The site is already served over HTTPS (
https://www.rizzzler.work.gd/). If you noticed any security warnings or something that made it seem otherwise, I'd really appreciate it if you could let me know so I can investigate.try to reach out to the particular audience you have built the product for, tech is one thing you also need finance and business if you want to enter real world market....
Absolutely, I agree. Tech is only one part of building a real-world product. I’m also focusing on understanding the specific audience I’m building for, validating their actual needs, and learning more about the business and financial side so the product can become commercially viable. Thanks for the perspective!
Try it and find out.
Keep it up, brother!
When visiting your website, I’d suggest considering integration with third‑party logins like Google or GitHub—pure email registration is still a bit of a hassle.
Thanks a lot! 🙌
That's a fair point. I wanted to keep the initial version simple, but I agree that Google/GitHub login would make onboarding much easier. I'll definitely look into implementing it.