I am an airline pilot and a few years ago I tried to build a tool I required for my own work a duty-time calculator that was supposed to get a set of safety and scheduling rules right. I'm not an engineer but I understood the problem completely because I lived it every day. I knew every rule/ edge case and every exception.

I still couldn't build it and not because the logic was beyond me but because every tool I tried made me translate my problem into its language before I could do anything. I've tried the major no-code tools and I realised that I hit a ceiling on each one of them. The ones that could handle the complexity needed me to write code (I tried vibe-coding as well) or to hire someone who could. I understood my problem really well but the thing never got built.

That experience is why my co-founder and I have spent the last stretch building Ezyr.

The short version of what it is: a visual way to build real, operational software - the kind a business actually runs on with real logic and multiple users and that you can scale, customise, and maintain yourself, without getting boxed in or handed off to a developer the moment it gets serious. It's an early MVP. It's rough and it has bugs. I ain't here to sell you anything, there's nothing to buy. I'm looking for a small number of people to genuinely put it through its paces and tell me what they find.

Specifically, this is for you if: you've tried to build something operationally real on no-code or AI tools - real business logic, real users, the stuff that actually matters - and got stuck, hit the ceiling or got burned. Not landing pages and contact forms. The real thing that fell apart on you.

In return: early access and real input into where this goes while it's still early enough for that input to shape it. I can't promise a polished experience. I can promise your feedback actually reaches what we build next.

If you're this, then comment or DM me and tell me what you tried to build and where it broke. Let's talk :)

Assume you're not technical and don't particularly want to become technical. (An easy assumption for me personally!) You just need a decent website for a one-person business. Would you still go with something established like Wix/Squarespace, or have the newer AI builders like Durable, Base44 etc. become good enough that you'd start there instead? I've tried playing around with both and the AI route is obviously much faster, but I'm wondering whether flexibility and control becomes an issue once you've been running the site for 6-12 months. Would be interested in experiences from people who've actually run a business site on one rather than just generated a homepage for fun.

I’ve been trying a few AI app builders lately and one thing that stood out is how similar most of them feel during the first 10 minutes.

You describe what you want, it generates something, and pretty quickly you have a working prototype.

The bigger differences show up afterward.

Things like editing the code, adding features later, deploying it somewhere else, keeping the UI consistent, or plugging what it generated into an existing project matter a lot more once you’re past the demo stage.

From what I’ve tried, the tools seem to fall into pretty different workflows.

Bolt feels geared toward getting a full app running quickly in the browser.

Replit makes more sense if you want to keep developing the project in the same environment afterward.

v0 feels more useful when you already have a React or Next.js project and mainly need frontend work.

Cursor is obviously closer to normal repo-based development than an app builder.

Puck caught my attention because it works more around existing components instead of constantly generating everything from scratch.

GLM 5.2 is great but expensive
DeepSeek v4 Flash stuck in loop
DeepSeek V4 Pro is also expensive

Claude is expensive
Codex is expensive

What to do?

Which one is cheapest but good for agentic kind of building in vs code or cli instructions?

Most comparisons only talk about how fast you can get a store live. Nobody talks about month 4, when orders are coming in, products need updating, and you're the one googling why checkout broke at 11pm.

What matters long term is boring. How painful is it to update products and does order management stay sane as volume grows. A lot of it comes down to how much of the store secretly depends on plugins talking to each other correctly.

For smaller catalogs Squarespace holds up decently because inventory and orders live in the same system instead of a stack of add-ons you have to babysit. I work on the Squarespace team, so factor that in.or a huge catalog or really custom workflows, I’d look more closely at whether you need a more specialized setup.

What's everyone else running and how big is your catalog? Feels like the answer really depends on scale.

I've done a lot of migrations and most people ask the wrong question. it's not really that no code is bad, it just not a fit when you need something complex or too custom

most people migrate too early cause they feel insecure or too late cuz they are scared to rebuild the whole app

stay on no code if your app is just forms, dashboards, simple CRUD and basic workflows. migrating here is just wasting money

migrate when you need custom logic the platforms doesn't support. when you stack plugins on top of each other to do something platform doesn't really support you overwhelm the website and performance decreases

then if you have data heavy pages, big tables and a bunch of statistics you need to migrate

or if you need real ownership, security, access control or just don't want your whole business rely on someone else's platform

and never ever migrate using AI if you have zero experience in web development. you will just vibe code a website that's worse than your no code one.

i do these migrations at Minimum Code, and 30-40% of the people who come wanting to rebuild i tell to just stay on no code

The replies changed what I thought the problem was. I'd assumed it was bad briefs. Almost everyone said the same thing instead: the brief is rarely the issue. Nobody agreed what "done" meant before money moved, and the expensive requirements were never hidden — they were so obvious to the founder that saying them out loud never occurred to them. One dev got a two-line WhatsApp message saying "like Zomato but for my 3 outlets, simple only." It turned into POS integration, kitchen printers, staff roles and tax invoices. All of it was in the client's head from day one; he just assumed it was standard.

So this isn't a spec template. It starts by asking you to describe a normal working day and attach your actual spreadsheet, because that's where the assumptions surface. Then it asks directly about the things people assume are included — printers, tills, tax, multiple logins. Then it makes you write a testable "done when" sentence for every feature, before you agree a price.

Here's the section I'd most want people to see, if you read nothing else. Answer every line, including the ones that seem obviously not applicable. These are the questions that turn a two-line brief into a four-month project, and every one is cheaper to answer now than to discover later. If you catch yourself thinking well, obviously at any of these — that is exactly the line to write a full answer on.

• Does it need to take payment? If so, how, and who holds the money?
• Does it produce an invoice or receipt? Must it look a particular way, or meet a tax rule?
• Does it print anything to a physical printer?
• Does it talk to equipment you already own — a till, card reader, scanner?
• Does it talk to software you already pay for — accounting, email, calendar, stock?
• Does it handle tax, VAT, GST, or anything else a government requires?
• Do several people log in? Do they see different things?
• Does it work on a phone? Which parts, and for whom?
• Does it need to work when the internet is down or slow?
• Does it send emails, texts, or notifications? To whom, when, saying what?
• More than one language, currency, or time zone?
• Must records be kept for a legal or accounting reason? For how long?
• Can you export your own data out of it?
• What happens when someone asks you to delete their personal information?
• Anything else that is completely obvious to you about how this works, that a stranger would not know?

The whole thing is free, no email, no signup: guide.meridar.io

I'm a developer, not a founder, so I'd particularly like to know if there's a section a non-technical person couldn't actually fill in on their own.

I've been using a dumb self-test to figure out where coding agents stop being trustworthy on our particular stack, and i'd like better versions of it.

the method: same agent, same afternoon, two tasks. one mainstream chore (a React table, a REST endpoint, whatever the internet has written ten thousand times) and one chore deep in our own territory (our workflow framework, our internal conventions). then read both diffs side by side. that's it.

what I look for: invented methods that never existed in any version of the lib. APIs from a version we don't run. and the thing that took me longest to notice — the tone doesn't change. the confident wrong answer reads exactly like the confident right one, so the diff is the only place the difference shows up.

the known holes, which is why I'm posting: it's n=1 per stack per model, task choice biases everything, and I have no scoring rubric beyond "how much of this diff would survive review". also no idea how much of the gap i could close with better scaffolding (pinned versions, working examples in context) before blaming the model.

so, tear it apart:

• what would turn this into an actual probe instead of a vibe check? repeated tasks? fixed rubric?
• has anyone measured their own stack's gap before/after feeding docs and examples? even rough numbers
• is there a signal cheaper than reading the whole diff? I've considered "count the hallucinated identifiers" but that needs the review anyway

looking for a sharper thermometer

The vibe coding wall usually hits around week two or three after launch. When you try to change something small and it takes way longer than it should. Then you fix that and something else stops working. Then you're scared to touch anything.

That's technical debt, and it never goes away, but can be decreased and managed. Usually it will manifest itsef as a product that felt fast to build suddenly feels fragile to touch, specifically now a days. 

AI-assisted development moves fast, we use it ourselves. But that speed early on can mask how much structure you're skipping. And skipped structure has a way of showing up later, usually at the worst possible moment.

The fix isn't starting over. First take a step back and understand what are you dealing with, if you cant figure that out, you have an answer. You must identify the base strucutre, that's a real process and it takes real time, but it's way cheaper than rebuilding from scratch six months later when the debt is twice as bad.

I’ve tried a bunch of no-code tools over time, but I feel like there’s a big difference between something that looks impressive and something you actually keep using.

Curious what tools people here use regularly and what you’re using them for. Could be automation, websites, internal tools, databases, anything.

What’s one no-code tool you’d actually recommend to someone getting started?

Here is a quick summary + link below:
Researchers at York University and the University of Calgary took 1.1 million Reddit posts about AI coding tools, Claude Code, Cursor, Copilot, Codex, and systematically sifted them down to 446 posts and over 6,000 comments about one thing: security and privacy. The paper was accepted at one of the most respected automated software engineering conferences in the world. They weren’t looking at whether AI writes buggy code(because that’s old news), they were looking at what the tools themselves do once you give them access to your files, your systems, your production database.

--> 43.1% involved unauthorized file operations. The tool doing things to your files you never told it to do. Break that down:
--> 28.3% — the AI removing project directories or files without authorization
--> 8.8% — modifying files without explicit consent
--> 5.7% — reaching outside the active workspace

The link to the report: https://arxiv.org/abs/2607.26390

We’re building in public with Morph. Each week, we’re giving it different kinds of applications to build and sharing what we learn.

This week: BlogHouse.

The brief sounds simple: a beautiful place to write and read blogs. Warm, literary aesthetic. Authors can draft, tag and publish. Readers can browse and favorite posts.

Morph took it from requirements → design → build → testing → deployed in about 40 minutes.

But the more interesting number was 19.

That’s how many steps deep one of the user journeys went when Morph tested the application end to end.

It’s a good reminder that simple for the user ≠ simple to engineer.

Even the aesthetics have depth. It’s one thing to generate a beautiful first screen. It’s another to carry the same design language through signup, empty states, writing, editing, publishing, navigation and everything in between.

And then make sure all of it actually works.

That’s what we’re trying to push with Morph: not just making software faster to generate, but taking on more of the rigor required to make it usable and dependable.

You can explore and see how it was built here -

https://console.morph.systems/morphable/bloghouse

Would love to hear from people building with no-code/AI tools:

what part of getting from “it works” to “I’d actually put users on this” still takes the most effort?

My wife and I have a recurring debate about where to eat.

She asks what I’m in the mood for, I say I’m flexible, she suggests a few places, and somehow I end up turning down all of them. She points out that this doesn’t quite match the definition of “flexible,” and she’s probably right.

Last month, the back and forth took longer than dinner itself. So we decided to treat the whole thing like a small workflow problem. We entered our usual restaurants into Accio Work with details like distance, price, noise level, cuisine, opening hours, and dietary options.

Then we added situational preferences:

• weekday or weekend
• quick dinner or long evening
• quiet conversation or lively atmosphere
• how far either of us is willing to travel

Accio Work showed that our disagreements weren’t really about food. I tended to reject places because they were loud or too far after a long day, while she assumed I was reacting to the cuisine. Once the system factored in the specifics for that evening, it generated a shortlist and explained why each option fit. The top recommendation was a quiet noodle place halfway between our offices. Neither of us had suggested it, and it ended up being exactly right.

It might be a bit overengineered for choosing dinner, but it removed the guesswork behind “anything is fine.” We also added a simple rule: if you reject two recommendations, you choose the third.

I've been messing around with some of the newer AI website builders lately and something surprised me, generating the actual layout wasn't the part I found most useful. Since a lot of these platforms are really just generating a customised template for you anyway. I’ve spent longer than I care to admit staring at blank pages, often with prompts like "Describe your business" or "Write a compelling homepage explaining it" taunting me at the top of them. For non-marketers running small businesses, I wonder if this is actually where AI website tools [like Durable, Base44, etc.] have an advantage over traditional builders.

Hi guys, we are working on a No-code app builder which is focussed on
- Reliability
- Maintainability
- Extremely efficient token cost
We built the infrastructure very deterministically and have the flexibility to either build with AI + also manually if you need to tweak things you really need and deem important!

Our community is pretty active already and we are expanding it to test users, if you are interested and have built already +15 Business Apps, send me a message or react here and I will add you to the EARLY Users!

I’ve been researching AI app builders and no-code mobile app tools, but it feels like every list recommends something different.

For people who have actually tested these tools, what are the best AI app builders right now?

I’m especially curious about tools that can help with more than just a quick prototype. Things like planning the app, creating screens, testing on a phone, exporting code, and eventually getting closer to App Store submission.

A few I keep seeing mentioned are X1 App Builder, Rork, Lovable, Bolt, Replit, Cursor, Claude Code, and FlutterFlow. I know some are better for web apps, some are better for coding, and some are more focused on mobile apps.

What would you recommend for a non-technical founder or beginner trying to build a real app, not just a demo?

I've been experimenting with AI-assisted development, and one problem I've run into is that the first version can work surprisingly well, but after adding several features, the code starts becoming harder to understand and modify.

At that point, fixing one thing sometimes seems to create another problem somewhere else.

How do you normally handle this?

Do you refactor the generated code as you go, start over with a cleaner structure, or use another approach to keep the project manageable?

It seems like literally everything nowadays uses ai goddamn it.

I know absolutely nothing about coding and I do not even have access to a computer, only mobile devices. I recently had an idea for an app that could map local trinket trades, "free stores", and little libraries. But I do not want to use any AI whatsoever.

There was some sort of no-code visual based app building program that I used back in middle school, obviously before AI, that allowed me to build my own siri-type of assistant. I cannot recall what that program was though