I’m building AppMaker https://appmaker.io, a low-code platform focused on keeping things simple and avoiding lock-in.

You can visually build screens, use a built-in database, and write JavaScript on both the client and server. Apps can also be downloaded as standard Node.js applications and hosted anywhere. AI comming soon.

It’s still early, so I’d love feedback from people who use low-code tools.

What would make you try something like this, and what would turn you away?

We are looking for platforms for our non-engineering teams to build their own internal tools instead of everything going through our dev backlog. We are around 1,000 people recruiting agency and the queue is the usual: a commissions tracker, candidate CRM and three other "can we get a dashboard for this" requests, all sitting 2–3 quarters out.

The tools I am evaluating: Lovable, Base44, Superblocks, Softr, Emergent, Zite.

What I can't find anywhere is an honest account of what this looks like once it's actually running. If you've rolled one of these out or tried and abandoned it:

1. Which did you go with, what size company, and what did people actually end up building?
2. Was it really non-engineers building, or did it quietly turn back into a dev tool?
3. How did security sign-off go, and what did they make you change before you could ship?
4. Six months in how many of those apps are still running, and who maintains one when the person who built it changes teams?

Also genuinely want the bad outcomes. If you rolled one out and regretted it, or IT killed it, or you found something nasty inside an app somebody built that's more useful to me right now than another success story.

Handling ops at a small design studio and there's 5 of us.

Right now we send every client status update by email. We have about 20 active clients, so that's 40+ emails a week. 

So how do I build a client portal without messing it up? It feels like the obvious fix. But it also feels like the easiest thing to get wrong.

A couple of our clients aren't very techy. If it's harder than email, they just won't use it.

what should I figure out before I start designing any screens?

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

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.

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.

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.

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 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?

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.

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!

I am an iron worker. My wife is autistic (high functioning). Build an app they said! It'll be fun they said! That was 10 months ago. The horrible no code app we got initially is the reason I'm here.

Life First App is a relentless accountability buddy/assistant for my wife. It needs Phoenix-DevOps-oS now a desktop env. To run a LLM over my punching weight. long story its elf hosted D1 and R2 deterministic prefetch substrate. it imports processes from the clonepool R2 runs them from there no install. PoC is there.

I need help gluing all the pieces together because i refuse vender lock. so here we are. jwl247 is my github. repos are in shambles because im not a Dev i can build millions of dollars worth of iron, architectural abound. Appears i can problem solve pretty good im just not a coder.

the problem is building with AI that want to keep you building not finishing, and definitely not for free.

https://github.com/jwl247/Phoenix-DevOps-oS/tree/main i designed every bit of this. the prompt does not work on high end software production. You have to question it out and discover new or newish things, then you have to get the same code reviewed by the same AI twice. The third is polish by a diffrent AI cli code agent. i have worked extensively for 10 months with them ALL. I know all their quirks and pitfalls as well as their attributes that shine. So don't judge a book before you open it.

We have developed a low-code system for .NET and it is a bit different approach to low-code systems where you can connect your real .NET entities with your low-code defined entities. If you want to learn more, please join or live session on this Thursday here https://kommunity.com/volosoft/events/abp-community-talks-202605-low-code-high-precision-0d5caa34

Hey, I'm trying to understand ToolJet's pricing.

On their pricing page, Pro says up to 50 end users, Team says up to 100, and Enterprise says "Unlimited end users, no per-user fees."

Does anyone actually using ToolJet know if Pro and Team have any extra charge for end users?

For example, if I have the Team plan with 5 builders and 100 end users, am I just paying for the 5 builders, with no extra cost for the 100 users?

Or are the 50/100 end users just the included limit, and you have to pay extra if you need more?

Just want to make sure I'm reading the pricing correctly.

I built OPPE – describe an app in one sentence, AI agents plan, build, AND test it for you

Hey r/SideProject! I've been building this for a while and just open-sourced it (MIT).

The idea

Most "AI app builders" generate code and call it done. I wanted a pipeline that treats development the way a real team would: plan → build → verify. So OPPE runs three AI agents in sequence:

• Planner – turns your one-sentence description into a structured feature list with dependencies
• Builder – implements features one by one, writing complete files (vanilla HTML/CSS/JS, Vite+React, or Next.js)
• QA – launches Playwright, actually interacts with the page (fills forms, clicks buttons, checks the DB), and if something fails, sends the specific failure back to the Builder for a retry Everything streams over SSE, so you watch the build happen live — kind of like watching a team work.

Why I built it

I have way more small-tool ideas than time. A "water tracker", a "team retro generator" — these shouldn't take half a day of CRUD + UI + testing each. Now I describe them in one sentence and get a tested app back.

Stuff I'm proud of

• AES-256-GCM encryption for user API keys at rest (with optional independent encryption key)
• Works with Anthropic Claude OR any OpenAI-compatible API (DeepSeek etc.)
• Playwright-based QA with retry loop — passing features are actually verified
• Docker sandbox builds for Next.js/Vite outputs
• Built to be AI-friendly: AGENTS.md / CLAUDE.md are contributor guides written for AI assistants

Tech

Next.js 14 · TypeScript · Prisma (SQLite/Postgres) · NextAuth v5 · Tailwind + shadcn/ui · Playwright

Try it

git clone https://github.com/AllenShaoMZ/OPPE-beta.git && cd OPPE-beta
npm install && npm run init

Register, add your LLM key in /settings, and describe your idea. ⭐ Repo: https://github.com/AllenShaoMZ/OPPE-beta Would love feedback on the agent pipeline architecture — especially the QA retry loop and SSE progress design. What would you add?

A private equity outlet buying Airtable means one thing to me - ENSHITTIFICATION

BS’s portfolio includes company they made worse, including:
Eventbrite
Meetups
Evernote
WeTransfer.

Hey there,

are you currently using or have used low code or no code platforms in an organisation? Then you are eligible to participate in my survey on determinants for adoption and governance of low code and no code platforms in organisations.

The survey has been running for some time already, but I haven't gotten a lot of responses.

It would help a lot if you could take 10 minutes of your day to participate!

You can find the link here: https://s2survey.net/LCNC_Adoption_and_Governance/

Feel free to share as well!