Zero coding background. 6 products since March — all by talking to AI agents. #6 is on Product Hunt today.
I can't write code. No CS degree, no bootcamp. Stack is: describe what I want to coding agents in plain words, then review what comes back.
That's been enough for an e-commerce design tool (EC Designer), an AI video SaaS (ELEVA), a LINE-based ops tool for local businesses — and now #6, Kotoba Dojo. You see a target image, describe it, AI redraws it from your text only, you get scored on the gap. That's the same loop I use to ship.
What I keep running into as a no-code builder: the bottleneck is never syntax. It's whether the spec in your head is precise enough for an agent to act on.
For other no-code people shipping real SaaS: what's the first thing that broke when you added Stripe / auth / a second language? That's the part I want to compare notes on.
It's impressive to see how much you've accomplished without a coding background. Venturing into multiple products, especially in e-commerce and AI, shows real entrepreneurial spirit.
From my own experience building products, I found that leveraging no-code and low-code platforms can significantly speed up the development process, especially for someone without a technical background. For instance, when I was working on my own project, I focused on automating content creation, which has been both a time-saver and a way to consistently ensure quality.
For your AI video SaaS, think about how you can integrate options for users to customize the output. This adds a personal touch that many small businesses appreciate. Also, using AI for video editing can streamline workflows — and if you can benchmark video performance against industry standards, you’ll provide valuable insights for your users.
The key across your products can be consistency in branding and user experience. As a founder, I've realized that a unified approach helps in cross-promoting your products effectively. If your design tool, ELEVA, and anything else you create can interconnect or at least share user data (with consent, of course), it could increase the stickiness factor of your ecosystem.
Keep iterating based on user feedback — it’s easy to get caught up in building more features. Sometimes, focusing on enhancing what you have can lead to better user retention and satisfaction.
Six products built through agents makes me curious about what happens after the spec is clear but the product is actually live.
When you're reviewing what the agents build, are you still mainly validating the code/product manually — or have you started keeping evidence of whether the resulting system actually behaves against the original spec once real users are interacting with it?
That's the gap I'm working on with OpsWatch: independently sampling real production evidence and checking whether an AI-built or AI-operated system behaved against the expectations that were agreed upfront.
With six products now, have you reached the point where manually establishing that trust is becoming a bottleneck?
Honest answer: manual verification is still my main tool, and yes, it's starting to become the bottleneck.
My current process is end-to-end testing in production — literally today I shipped acquisition tracking, then opened an incognito window, visited with a test parameter, created a real account, and checked the actual database row myself. The agent also injects deliberate bugs into its own code to prove the test suite catches failures (mutation testing), which covers the "does the code do what the spec says" layer.
But what you're describing — continuously checking whether the live system behaves against the original spec once real users hit it — I don't have that. My monitoring is basically GA4 plus reading error logs when something feels off. At 6 products and growing, that won't scale.
I can't read code, so for me "trust" can only ever come from observable behavior, not review. Which probably makes founders like me your exact target user. I'll take a look at OpsWatch.
That’s almost exactly the problem I’m trying to solve.
Your acquisition-tracking example is a good illustration. Instead of you manually opening incognito, creating an account and checking the database row yourself, OpsWatch would start from the agreed expected behaviour and independently verify whether the resulting production evidence shows that behaviour actually occurred.
The important part for me is that this sits above the code layer.
Mutation testing can tell you whether the test suite detects deliberately introduced faults. OpsWatch is asking a different question: once the system is live, did the actual user journey behave as intended, including the outcomes and edge cases that matter?
For someone running six products, I’d probably start very narrowly — one important production flow, a small set of agreed expectations, and a defined evidence sample — rather than trying to monitor everything.
If that works, the same assurance model can then be reused across the other products without you manually proving each behaviour yourself.
Given what you described, I think one of your existing production flows would make a genuinely useful OpsWatch pilot.
"The bottleneck is never syntax, it is whether the spec in your head is precise enough" is the whole thing, and six products in you already know it.
One thing that helps when the spec lives only in chat: write the one-sentence core job of the product before the agent touches anything. Who is doing what, and what has to be true when they are finished. One sentence, kept in a file, not in the thread. Every later request gets checked against it, so a surprise rewrite has something to disagree with.
That is page one of what I run: https://durablefoundations.gumroad.com/l/pyramid-reality-check
For Kotoba Dojo, what is that sentence?
Kael Voss / DurableFoundations
Fair question — here it is, the sentence that's been in my spec file since day one:
"A player describes a target image in their own words; the AI must redraw it from that text alone; the score is the gap — and every feature must make that loop sharper, not busier."
That last clause has already killed two feature ideas (a hint marketplace, social feeds). If it doesn't sharpen the describe→draw→score loop, it doesn't ship.
And yes — I run the same discipline you describe, because when you can't code, the spec is the product. The agents only ever see what I can put into words.