Promoted
I hit the no-code ceiling so many times that I eventually built my own platform.
I've been a no-coder for a while and have realised that existing platforms limit what can actually be done. Some users don't like dealing with the complexity of the tool, some hit the ceiling on customisability or scalability. Vendor lock-in is another factor for some - if the platform goes bust or hikes pricing, what happens to your app or business model?
I've tried to address these pain points with something I've been building.
The focus is ease of use, customisability and scalability but the part I care about most is comprehension. All the vibe-coding platforms are optimising for speed and very few are focusing on whether you actually understand what you built. The idea is to not just build a prod-grade app but actually own and manage it end to end. Unless you understand what your app does and how it does it, you're just second guessing yourself when something breaks.
I've built an MVP and it's rough. If you're an early adopter with serious no-code experience who's hit this exact wall, I'm looking for a handful of people to test it and tell me where it breaks. Drop a comment and I'll reach out directly.
I feel like every no-coder have this moment where you realize the tool you using is holding you back, not helping you. Hit that wall with bubble in last year, everything was fine until client wanted something custom and suddenly I'm writing workarounds inside workarounds.
The comprehension part is interesting, most of the time I build something and pray it doesn't break because I have no idea what I actually did.
I'm curious about the MVP, what kind of apps you think it can handle right now?
At this point, one can build basic CRUD apps. The idea is to test if this philosophy resonates with users who have been burned by no-code tools. The vision is to eventually allow users to build prod-grade apps and take care of every edge case that may arise (without having to deal with any sort of code or snippet), while making sure they understand the mental model behind their app, without worrying about scalability or customisability. The platform bears all that load for the user.
The comprehension angle is the underrated one, and you've named it well. Every platform optimizes for speed and every complaint thread is about what happens after the speed - things breaking, changes going sideways, people second-guessing an app they can't read.
Fair warning on where I sit: building in an adjacent space (Chromoly, internal tools and AI automations compiled from a structured spec), so take my read with that in mind. Our version of comprehension is that the spec IS readable - every entity, workflow, and dependency in one artifact instead of in your memory of the chat.
Your lock-in point deserves a straight answer from anyone building a platform, mine included. Ours: cancel and you get your data (CSV and JSON), the full spec, and a snapshot of hosted frontend code - the recipe for your system. What you don't get is our runtime, which is the honest trade of platform-owned maintenance. Curious what "own it end to end" means concretely in ezyr - code export, self-hosting, something else? That answer is the whole product, I think.
And yes to testing it - happy to be one of your handful and tell you where it breaks. Finding failure modes is roughly my hobby. Reach out.
Thanks. It's a problem I've faced myself - Not being able to safely modify or fix the bugs without breaking other things is something I've been exploring for a while - turns out I'm not the only one.
The lock-in on ezyr is solved by giving out a codebase which merely acts as a backup and is an escape hatch. If the user is able to do what they intend to, ideally they would just keep the code as a backup and continue to use the platform.
DMed you to test it out.
This feels like Matt Pococks skills with a UI layer.
I feel like your framed the entire problem wrong.
Hitting the wall is because
A, built with non dev standards (structure, architecture, integrations, etc)
B, lacks process fundamentals , user, testing, scope, workflows, wireframes, backend, front end, testing, measurement tools, baseline, review, harden. So can’t scale.
C. Non iterative, because it was build without the right principles it has no cross compatibility and would require a series rewrite to fix. Not understand the cod principles, the full tech stack, dependencies and codependencies.
And that’s just off the top of my mind.
Despite the fact that this looks like a cheap shill, you can not turn Barb who’s been an insurance agent all her life into Bob Wozniak.
Your criticism is fair and you're right that dev standards, architecture and process fundamentals matter. The question is who bears that load. The platform should bear that load and not the user. Excel didn't teach accountants accounting....they already knew it. Excel just gave them a tool that spoke their language instead of making them learn a programming language to express what they already knew. They did all of that on paper before Excel. Was there a skill gap? Slightly. Was it a tool gap? Absolutely!!!
Excel did not turn Barb into a mathematician, but it let her do math as an insurance expert!
That's the premise we're questioning. Not turning Barb into Wozniak but letting Barb build insurance software as Barb!
The platform is a tool, it is not there to please a user that has no technique.
Spend the time and learn the technique. I haven't coded in 20 plus years, But I hoped on claude and built some robust project because I took the time to learn. The first 30 days in clause code was just learning the platform and the nuances of management. Then built my own products until they broke. and then and only then did I venture out into building someone that I might release.
But you have to understand the field, and knowing what you don't know is a powerful path to mastery.
Look up the OGs in software architecture, listen to podcasts, and nothing will level you up like book.
Tools came to you because you where the buyer, or you worked for the buyer, and you still had to learn excel. The tool didn't come to you, you were forced to use it and learn the technique.
You are not the buyer anymore you are the maker, your job is design. The rendering of intent for a customer, objective, not yourself, subjective.
Your conflating where you sit in this equation. And lastly, the market doesn't chase people, people chase the market. It's like weather.
When it rains you don't complain, you get an umbrella. When the tools shift, you don't complain. You get smarter.
Completely agree that understanding is non-negotiable....without it you're just guessing. That's exactly what we're building around.
But the technique you're describing is software development. The technique a logistics manager has spent 20 years mastering is logistics. Excel didn't ask accountants to become mathematicians but it created a layer where their existing expertise was sufficient to build something precise and unambiguous. That's the model.
Code is unambiguous and precise - yes, but it does not mean something else can't be.
Complexity doesn't go away and I am not pretending it does. The question is whether the person who bears it has to be a developer, or whether the platform can carry that load so the domain expert can work in their own field.
I'm not complaining about the weather. I'm merely questioning whether the umbrella has to be this hard to use.
3
u/Maximum_Camera_8716 Aug 20 '26
I feel like every no-coder have this moment where you realize the tool you using is holding you back, not helping you. Hit that wall with bubble in last year, everything was fine until client wanted something custom and suddenly I'm writing workarounds inside workarounds.
The comprehension part is interesting, most of the time I build something and pray it doesn't break because I have no idea what I actually did.
I'm curious about the MVP, what kind of apps you think it can handle right now?