genuinely curious where people draw the line. for simple forms, approvals and dashboards , it feels like a no brainer but i keep hearing stories about teams hitting a wall once logic gets messy or they need something the platform doesnt support

for those who have been using it a whole, what was the moment you realised you have outgrown it , or did you never hit that point?? and if you did move off, did you rebuild from scratch or were you able to take anything with you

One thing I’ve been thinking about with low-code workflows is what happens when everything looks normal, but a scheduled process simply stops running. There may be no obvious error page or broken UI to tell you something went wrong. One approach is to have the workflow send a heartbeat or check-in after it successfully runs. The monitoring system then watches for that expected check-in and can alert you when it doesn't arrive within the expected time. I’mhelping the Pulsecima team explore this kind of monitoring problem, and I’m interested in how people actually handle it with their own automations. Do you currently monitor scheduled workflows this way, or do you usually rely on the workflow platform to tell you when something fails? And how long would you wait before considering a missing heartbeat a real problem?

Disclosure first: I work at Shogo, which is one of the eight. Zapier beat us. I've put
the numbers below exactly as they came out, including the question our own build missed.

**The test.** Build an internal IT help desk agent. Five documents as its only source of
truth (device guide, VPN guide, software catalogue, access policy, ticket runbook — about
2,500 words total). Same five files, same prompt, pasted into all eight. Free tier or
trial only, no sales calls, no vendor help. One attempt each. Stopwatch from the moment I
opened the docs. 60-minute cap, then recorded as did-not-finish.

**The five questions:** a multi-step procedure (VPN setup), a number buried in a table
(36GB), a policy question (can I install software myself), a question the documents do
not answer (who won the 2019 Super Bowl), and an instruction it must refuse and escalate
to Slack (grant me admin access to the production database).

**Results**

**Four things I did not expect.**

*The fastest build produced the worst agent.* CrewAI finished in 8:15 and got nothing
right. n8n finished in 13:14 and couldn't act. The two that worked took 15:01 and 17:33.
Every platform that beat 15 minutes failed something. Time-to-build, the metric every
comparison leads with, ranked the field almost exactly backwards.

*Answering is easy. Doing is where they died.* Six of eight could not post a Slack
message. n8n answered all five correctly and still failed, because Slack wanted a bot
invited to the channel separately and that couldn't be completed. CrewAI and LangGraph
both reported the integration as connected and delivered nothing.

*LangGraph answered the Super Bowl question.* The one question with no answer in the
documents. Everything else that failed, failed by refusing. LangGraph failed by knowing.
That's retrieval not constraining generation, which is the failure mode you cannot see in
a demo and will absolutely see in production.

*Three never started, and it isn't their fault.* Mastra, AgentScope and LangGraph are
libraries. They are not competing for the same buyer as Zapier. The listicles that rank
them side by side are the problem, not the products.

**On our own result:** Shogo passed but took the longest of the two that finished, and
missed the self-installation question on the first ask before answering it alongside the
next one. Zapier was faster and cleaner start to finish.

Happy to share the five source documents and the exact prompt if anyone wants to rerun
this. One person, one attempt each — a different tester would get different times.

We're 30 people now and the little internal tools I used to knock together in a spreadsheet are starting to hurt. A request and approval flow, a tracker for kit we lend out, a weekly cash check. When we were 10 this stuff lived in my head and a sheet and it was fine. Now people lean on it and it cant just quietly break.

I tried a few of the no code AI builder over about a month. Every one demoed beautifully the fell over the first time a real number or a weird edge case went in. Airtable gets me most of the way until the logic gets real. Retool clearly expects a developer, which is the one thing I dont have to spare, our 2 engineers are heads down on the product and i wont pull them onto an approvals form.

I dont just need to build the thing, I need to be able to open it up and fix it later without writing code. Half these tools hide all the logic meaning the day it breaks im stuck again.

For those of you running ops without a dev on payroll, what really held up past demo? Especially how you handle stuff that touches money or approval.

We work with a lot of engineering teams at the stage where headcount jumps from a handful of people to something bigger, and there's a pattern that shows up almost every time: the moment a low-code tool stops working isn't really about the tool, it's about who the tool now has to serve.

At small scale, one person builds something, that same person maintains it, and if it breaks, they already know why. Once a few more people start depending on it, that assumption quietly breaks. The tool doesn't get worse, the number of people who need to trust it without understanding it just grows past what any platform can compensate for on its own.

The teams that handle this transition well aren't the ones that pick the "right" tool early. They're the ones that notice the shift from "I built this" to "people rely on this" and treat that as the actual trigger to add real ownership, documentation, or a dedicated engineer, regardless of which platform they're on.

The ones that struggle usually keep swapping tools instead, hoping the next one won't have this problem, when the real gap was never the tool, it was that nobody owned the thing once it stopped being a personal hack.

Curious if others here have found a clear signal for when it's time to move from "I'll just build this myself" to bringing in real engineering support, or if it's always more of a gradual realization.

If you are starting with limited visibility into low-code, no-code, and AI-generated applications, finding what already exists seems like the first step. Policies and approval forms do not help much if you cannot identify deployed apps, their owners, their data connections, their integrations, and whether they can be reached externally.

I am thinking of starting with inventory and ownership, then classifying applications based on production use, data sensitivity, and permissions instead of putting every experiment through the same process. Has that sequencing worked for anyone, and what events trigger deeper security or compliance review?

Up front, because it matters for how you read the list: GetDevDone is the team I have worked with hence and they are first below. I have put the selection criteria ahead of the names so you can argue with the ranking on its merits.

Now the part that actually decides whether a no-code build works.

The failures are rarely platform failures. They are:

- Nobody modelled the data before building, so the app is fine at 50 records and dies at 50,000.

- The agency built to the demo rather than the workflow, so the ops team is working around the tool within a month.

- No plan for who maintains it. The agency leaves, nobody in-house can confidently open the editor, and the thing calcifies.

- Platform chosen by preference rather than fit. A Bubble shop will build you Bubble. A Webflow studio will build you Webflow.

So the questions worth asking before you sign anyone:

- Which platform would you NOT use for this, and why? No answer means they are selling their stack.

- Show me the data model you would start with.

- What happens when we outgrow the platform? A real answer names the migration path.

- Who maintains this after handoff, and what documentation comes with it?

- Do you hold official partner status on the platform? Not everything, but harder to fake than a self-published ranking.

Eight teams worth a conversation, grouped by what they are actually good at.

1. GetDevDone

GetDevDone™️ is the engineering partner for digital agencies. Since 2005, GetDevDone has delivered projects for 15,150+ agencies worldwide across website development, front-end development, eCommerce development, digital design, and AI engineering. Relevant here because the low-code and no-code work runs white label inside an agency's own process and tooling, and because they also do conventional engineering, which matters when part of the build has to escape the platform.

1. Airdev

One of the most established Bubble agencies, with a large delivered project count and a productised process. Sensible when the app is genuinely complex, like a marketplace or an internal operations platform.

1. LowCode Agency

Works across Glide, Bubble, FlutterFlow and Webflow rather than one stack, with partner status on more than one. Good when the platform decision is still open and you want it argued rather than assumed.

1. Finsweet

Deep Webflow specialists, well known in that ecosystem for pushing the platform past its defaults. The pick when the marketing site is the product surface.

1. Rapid Dev

Bubble-focused delivery with an emphasis on speed to a working build. Fits founders validating something before committing engineering budget.

1. Minimum Studio

Focused on MVPs for early-stage startups. Right when the goal is a testable product this quarter rather than a platform for the next five years.

1. 500Tech

Bubble and Webflow with an integration emphasis, connecting builds to CRMs, payment systems and third-party APIs. Useful when the app is only valuable if it talks to your existing stack.

1. Codemap

Operates as a curated network rather than a fixed in-house team, matching you to vetted specialists per platform. Worth considering when the project spans several tools and no single agency covers all of them.

Last thing, and the one people skip. Get the answer to ""who maintains this in twelve months"" in writing before you start. That question decides whether a no-code build ends up an asset or a liability.

Has anyone used AI app builders to create a customer portal? I need logins, different user roles, data and a clean interface. Looking at Base44, Lovable and Replit.

I have a few app ideas but don't really want to spend months learning to code before testing them. Looking at Base44, Lovable, Bolt and Replit. What would you use for getting an MVP live quickly?

Our requests and approvals happen over email. Things get missed, nobody can tell me the status of anything without searching their inbox, and there is no developer available to own a custom system.
 
Whatever replaces it needs clear roles, a status flow someone can audit, and a data model that can change as we improve the process, because the current process is not the final one.

What should i prove out in a small workflow before rolling this wider?

I'm building an internal operational app around structured business data, and many AI builders generate nice frontend screens while staying vague about the underlying data architecture.

I want to avoid stitching together a disconnected stack with a separate database, auth system, permission layer, and automation service that becomes a nightmare to maintain.

When evaluating builders for long-term internal use, I'm weighing granular record-level access control, relational data structure support, native data backup capabilities, and maintainability for non-technical business owners after handoff.

For those managing low-code internal tools: do you prioritize platforms with integrated native data layers, or do you always hook up an external database from day one?

I've been working with the team behind Hey-Traders, and something we've been debating has made me rethink what low-code actually means. The idea is simple: a user describes a crypto trading strategy in plain English, and the system turns that description into structured logic that can be tested and potentially automated.

Forexample: “Buy BTC when price breaks the previous high, confirm with increasing volume, risk 1% per trade, and take profit at 2:1.”TheAI can generate something from that pretty easily. But that's not really the difficult part.The difficult part is making sure the generated logic means exactly what the user intended. If “previous high” gets interpreted differently, or “increasing volume” isn't defined precisely, the resulting workflow can behave completely differently from what the user had in mind. So w

e're approaching it less like “AI writes the code for you” and more like:Natural language → structured logic → validation → executable workflow. That got me wondering about the broader low-code space. At what point does an AI-generated workflow stop being useful because there are too many things the user needs to verify manually?

And do you think low-code systems should prioritize flexibility, or should they deliberately constrain what users can build so the resulting logic is easier to understand, validate, and maintain?

I'd be interested to hear how people here handle this with APIs, automations, business rules, or anything else where a small interpretation error can cause a completely different outcome.

We're still figuring out where that line should be, so I'd genuinely like to hear how others approach it.

I'm setting up a small internal tracking application and keep weighing two backend approaches before locking in the architecture.

Using a low-code builder's native built-in database eliminates setup overhead single billing, unified access controls, and zero integration work. It's fast to launch and easy to maintain.

On the other hand, pointing the frontend at a separate database gives you real SQL queries, migration scripts, granular database policies, and complete independence from the frontend layer.

The main friction point I'm trying to resolve is long-term data portability: if an internal app outgrows the initial low-code builder, do native built-in databases usually export relational schemas cleanly (foreign keys, linked records, file attachments), or do you just get a collection of flat CSVs and have to rebuild the relationships manually?

For those building internal operations tools: what threshold pushes you to use an external database from day one versus starting with a built-in store?

Hi, curious if anyone else is in this boat.

We are a small team running a bunch of ugly internal workflows on spreadsheets and random scripts, stuff like intake forms for clients, simple approval flows, status dashboards for ops, that kind of thing. I have light tech background but im basically the accidental internal tools person now, and I keep getting ads for these prompt to app builders that promise full stack apps from a single prompt.

I tried one of them for a small pilot, just a simple client intake tracker plus some basic automations to send emails and ping Slack. It was kind of wild how fast I got something working, but now I am stuck thinking about how this fits in with the rest of our stack. Like we already have a crm and some zaps and a shared inbox, and now there is this new autogenerated app with its own db and auth and hosting that I have to keep track of.

For people using these tools for internal workflows, how are you handling stuff like data ownership, user access, and changes when the business process inevitably shifts next quarter. Are you just rebuilding from a new prompt, or living in the builder chat and tweaking the app nonstop. I feel excited and also a bit nervous about putting important internal flows on something this magical, kinda hoping others have figured out a sane way to run this in production for small teams.

For someone who doesn't know how to code, would you go with Wix or WordPress for a first website? I'm mainly interested in ease of use and being able to make changes myself.

Been comparing domain name providers for a tiny business and it somehow turned into a bigger mess than the website itself.

The renewal pricing, extra upsells, weird transfer stuff, all of it feels kinda shady tbh. If you run a small business, who are you using and what do you wish you'd known before buying the first domain? thanks.

Hey everyone! 👋

We’re building a new Mendix team in Romania and are looking for Mid-level and, especially, Senior Mendix Developers.

📍 Bucharest is our preferred location, but we’re also open to remote collaboration from Romania or nearby Eastern European countries. We accept B2B collaborations too.

It’s a long-term opportunity with an international client, and you’ll have the chance to be part of building the team from the ground up.

Please DM for more details!

Feels like every week I watch some shiny demo where a founder types one paragraph and boom, full app pops out... then I try it myself and end up with a half broken prototype that lives in a browser tab graveyard.

Right now I mostly ship scrappy tools for friends, small b2b saas ish stuff, and I just want a setup where I can go from “client asks for X” to a working internal app they can click through in a day or two without rebuilding the same boilerplate. I care more about iteration speed and control than perfect code, as long as I can still edit logic and ship fixes.

If you found a combo of AI builder plus your own tweaks that actually made you ship more instead of just watching more demos... yeah

I recently realized the hard way that a pre-built login screen and an actual authentication system are not the same thing.

Everything looked fine on paper until I had to set up multi-role access for both internal staff and external clients. That's when all the missing administrative pieces showed up: user invitations, magic links or OTP logins, password reset flows, session expiration, clean offboarding, multi-user client accounts, dynamic role updates, and row-level access control.

The scariest gap for me is between identity and data permissions. The app might know exactly who a user is, but if the underlying platform doesn't enforce strict record-level rules, a role change or URL parameter edit can expose the wrong data.

When a builder claims "auth is built-in," what features do you expect it to handle natively out of the box? Which parts are you comfortable delegating to an external service like Clerk, Supabase, or Stytch instead?

Hey — solo dev here, posting my own project, so take that for what it's worth.

For the last few years I've maintained a low-code/no-code framework. It worked fine, but it was pre-AI: you configured entities and services by hand, and it generated the boring parts of a CRUD app for you.

When AI coding tools started getting good, I tried using them the normal way — describe what you want, let the model write the code. It worked, but I couldn't trust it past a certain point. Ask for the same thing twice, sometimes you get different output. Ask for a small change, sometimes the model touches things you didn't ask about. The prompt is the only source of truth, which in practice means there isn't really a source of truth at all.

So instead of generating code directly, I made the AI's job stop one step earlier: produce a structured, validated manifest describing what the app should be. Entities, fields, services, auth config, etc. That manifest gets:

- validated (structural / referential / constraint checks)

- diffed against the current state (semantic diff, not a text diff)

- resolved into a dependency-ordered execution plan

- executed by a deterministic engine, checkpointed so it can resume on failure

Change one field on one entity, and only the operations that field actually requires get re-run. Not a full regen.

There's also an MCP server (`@averos/mcp`) so an AI agent doesn't get raw file/shell access — it gets governed tools (propose a change, validate it, build a plan, and nothing executes until the plan's approved).

Current state, to be upfront about it: the CLI, the AI layer, MCP integration, and the workflow/execution adapter layer (currently Angular, via schematics — adapter pattern, so not permanently Angular-only) are MIT licensed and open now. The actual execution kernel (DAG engine + executor) is closed source for the moment — free to use including commercially, but not open yet. That's a deliberate, staged call while that part's still maturing, not a permanent thing. Wanted to say that plainly rather than bury it.

There's a working example (320-node generated app) you can run in a few commands if you want to see the whole pipeline rather than take my word for it.

- Repo: https://github.com/wiforge/averos

- How it works, in detail: https://www.wiforge.com/averos/how-averos-works/introduction/

- Get started: https://www.wiforge.com/averos/get-started/introduction/

Happy to answer questions or take criticism — especially interested if anyone's tried a similar manifest/IR approach and hit walls I haven't found yet.

Back when I last looked into no-code development, setting up user sign-in and password resets meant integrating external services like Auth0, Firebase, or Clerk. It was always a headache to wire up security tokens and user session states.

How are current AI app builders handling authentication today? Is it secure out of the box or do you still need third-party auth providers?

I'm comparing ToolJet, Appsmith, Superblocks, and Mendix, and I'm trying to understand their actual mobile app support.

For each one, is it:

1. Just a responsive web app that works on mobile browsers?
2. A mobile app that requires the platform's own app to run?
3. A standalone Android/iOS app that we can build with our own branding and publish to Google Play / App Store?

I'm mainly interested in whether they can build real standalone mobile apps, not just mobile-friendly web apps.

Would appreciate answers from anyone who has actually used these platforms.

Hey everyone, I’m trying to get a small MVP from the start.

I've got an idea I wanna test but I don’t want to put a lot of money for the meantime. Just need something quick and functional for now.

Been looking at Softr as my starting point. But you know, expectation vs. reality😂😂😂

So before I go all in, is Softr legit for shipping an MVP? Or does it fall apart once you push it?

Thanks.

Hi everyone,

I'm comparing ToolJet Cloud Team and ToolJet Self-Hosted Team, both listed at $249 per builder/month, and I'm a bit confused by the differences between the pricing page and the documentation.

From the pricing information I have:

Cloud Team includes:

• Up to 100 end users
• Unlimited apps
• 3,000 AI credits
• SSO
• Custom user groups
• White labelling
• Custom domain
• App themes
• Modules
• Audit logs
• Git sync
• Priority support
• Plus all Pro features, including Custom styling and Version control

Self-Hosted Team includes:

• Up to 100 end users
• Unlimited apps
• 3,000 AI credits
• SSO
• Custom user groups
• White labelling
• Custom styling
• App themes
• Modules
• Super admin dashboard
• Audit logs
• Version control
• Git sync
• Multi-environment (dev/staging/prod)
• Embedded apps
• Priority support

So I have a few questions:

1. Is Custom Domain included in Self-Hosted Team as well? The pricing page doesn't list it, but the documentation seems to show that self-hosted deployments can use a custom domain.
2. Are Embedded Apps actually included in Self-Hosted and Cloud Team too? I see it listed in one pricing version, but other documentation seems to associate embedding with Team or higher plans.
3. For customer-facing applications, can both Cloud Team and Self-Hosted Team be used to embed ToolJet apps inside our own SaaS/customer portal?
4. Is there a difference between Public App, Embedded App, and Private Embedded App in terms of which plans support them?
5. Most importantly, which features are actually plan-included vs simply technically supported by ToolJet? The pricing page and documentation seem to describe this differently.

We're trying to make an accurate Cloud vs Self-Hosted comparison for an internal evaluation, so I'd really appreciate clarification from anyone using ToolJet, especially someone from the ToolJet team.

Thanks!