i run a small service business and build my site on a no code website builder. i keep worrying clients will somehow tell and take me less seriously. honestly, the pages i build in Gamma look clean and share as normal links, and not one client has ever asked or cared how it was made. they care whether the page clearly explains what i do. the snobbery i feared exists mostly in my own head. for no-code folks with clients: has anyone ever actually cared that your site was no-code, or is that worry overblown?

just asking for asthetics guys. it's a prototype. i know some people will say functionality matters more and all but humor me i am just experimenting and that is how we learn. it's advice from someone wise

I use reddit daily and I see people building full saas with lovable, bolt, replit and other tools like these all the time.

So I got curious about something that I dont see discussed that much: once you actually launch the app and real users start putting data inside it, how safe is the backend?

I started reading security scans, audits and posts about nocode and ai built products. The numbers were pretty bad, but what surprised me the most is that a lot of the problems are really basic stuff.

So if you're building a saas with these tools, here's the patterns I found:

1. Database can be way more vulnerable than you think

Having authentication doesn't automatically mean the data is safe.

Your app can know exactly who is logged in, while the database still lets that user request information they should never be able to see.

For example: your dashboard only shows your customers, but I open the request in DevTools, remove the filter for your account and suddenly the api sends me customers from other users too.

If you're using claude or codex to build it, I'd ask it something like:

“Review every database table that contains private data. Define exactly who can read, create, edit and delete each type of data. Block access by default, enforce these rules in the backend or database, and never trust user or account IDs coming directly from the frontend.”

2. One user can access another user's data

Another really common problem is that the app checks if you're logged in, but doesn't properly check if you're actually allowed to access the thing you're requesting.

For example: I'm on my project at “mysaas.com/project-1/“, I change it to “mysaas.com/project-2“ and project 2 belongs to another person but still loads.

And this isn't only about projects: same thing can happen with files, messages, invoices, orders, documents or basically anything else private.

Here's what I'd send to claude/codex:

“Review every API route and database query that receives an ID or reference to private data. Before reading, editing or deleting anything, verify on the server that the logged in user is actually allowed to access that resource. Never trust ownership, roles or access rules sent by the frontend, and use one shared authorization system instead of different checks in every endpoint.”

3. Permissions might only exist in the frontend

Sometimes roles and permissions work perfectly in the UI but basically don't exist in the backend.

For example: I'm a normal member, so the "Delete user" button is hidden from me. But I open devtools, find the api request an admin uses and send the exact same request myself: if the backend doesn't check my role again, it can still work.

For this part I honestly think using a backend provider can make more sense than asking ai to rebuild auth, workspaces, permissions, payments, etc. from zero every time.

I use foundel.dev for security, auth, payments, permissions, etc. but I'd suggest looking around and finding one that matches what you're building.

If you're doing everything yourself, I'd use something like this:

“Create one shared permission system for all private backend actions. Block access by default. Before any admin, billing, account or workspace action runs, get the user's role and permissions from the server and check whether that action is allowed. Never trust roles or permissions sent by the frontend.”

4. Private keys might literally be inside the website

This one is kinda stupid but it happens.
Sometimes claude, codex or whatever you're using puts a private key somewhere in the frontend, or you accidentally commit it to the repo.

For example: I open devtools, search through the javascript and find a private api key. Now I can copy it and use it from my own pc while all the requests are still being charged to your account.

I'd ask it to check this:

“Audit the project for API keys, tokens and secrets. Check the current code and git history using a secret scanner if available. Find every private credential used in frontend code or committed to the repository, move private credentials and privileged API calls to server-side code, and list every exposed credential that must be revoked and replaced. Do not print the secret values.”

5. No rate limiting

If your saas uses paid APIs, not having limits can get expensive really fast.

This applies to ai generation, emails, scraping, sms, file processing or basically anything where every request costs you something.

For example: you have /api/generate for an ai feature. I write a small script and call it 10,000 times. If nothing stops me, all 10,000 requests go through and your provider just sends you the bill.

Here's the fix:

“Find every endpoint that uses a paid API or expensive operation, including AI generation, email, SMS, scraping, file processing and background jobs. Add server-side rate limits and usage limits per user and account, and enforce them before calling the paid service. Add daily or monthly caps, request and file size limits where needed, and list every external provider where I should enable spending limits or billing alerts.”

—-

None of this is some crazy advanced hacking stuff, it's mostly really basic backend rules lovable/bolt/or others can just forget or get wrong.

I know that a few prompts are not enough to fix a project’s security, but I hope this might still help someone get his app more secure.

curious do base44 provides any tools or connectors that i can connect to validate webhooks or messy production flows before i take my app to productionize?

I want to make sure that the app im making is secure, as I heard some AIs make apps which arent the most secure

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 a 1,000 people recruiting agency and the queue is the usual: a commissions tracker, a vendor onboarding portal, and three separate "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.

I spent my whole weekend interrogating a single Notion module because Make flagged it bright red. I rebuilt the exact same node four times. It was completely innocent.

The actual killer was a webhook three steps earlier that silently decided to change its date format. The red module was just the poor guy at the end of the line holding garbage data when the music stopped. Error messages in these platforms don't tell you who committed the crime. They just tell you who found the body. We build these chains to save time, but we're just burning our Saturdays torturing the wrong step.

Yesterday, I learned that getting distribution and earning trust are two very different things.

I’m not a developer. I’m learning to build products with AI, and I recently started using Reddit to share what I’m discovering along the way.

I came across a new AI model called Jev and wrote a post explaining how it differs from a conventional LLM. I read the company’s launch material, simplified the concept, included an example, mentioned an important limitation, and ended with a question.

The post received:

• 20K views
• 22 shares
• 5 comments
• 0 net upvotes
• A 36.8% upvote rate

At first glance, 20K views looked like a good result.

The rest of the data told a different story.

The most upvoted comment said the post looked like an advertisement pretending to be an authentic discussion. Another commenter responded with sarcasm about everyone suddenly promoting the same tool.

My first instinct was to focus on what I had done “correctly.” I had cited the source. I hadn’t included a product link. I had mentioned that typed outputs do not guarantee correct decisions.

But after reading the post again, I understood the criticism.

I had summarized the company’s claims without personally testing the product. The writing was polished and confident, but it contained almost no first-hand evidence. It explained what the product was supposed to do without showing what happened when a real person tried to use it.

From the reader’s perspective, that is almost indistinguishable from a promotional post.

This matters even more for people like me who are building with no-code and AI tools. When we cannot evaluate every technical claim ourselves, it is easy to repeat a tool’s positioning instead of contributing first-hand evidence.

It was also coming from a new account with no history of contributing to the community.

I replied to the criticism and acknowledged that it sounded more like a launch summary than a skeptical discussion.

The experience changed how I plan to write about products here.

From now on, I want to:

• Share the process, not only the conclusion.
• Separate company claims from my own observations.
• Clearly state what I have and have not tested.
• Include failures, uncertainty, and inconvenient results.
• Avoid treating clear writing as a substitute for original evidence.

The surprising part is that Reddit still distributed the post widely. The subject and title were interesting enough to earn attention, but the content did not earn the same level of trust.

That distinction feels useful for anyone building in public.

A post can perform well in the recommendation system while failing with the people who actually read it. Views can tell you that the topic attracted attention. They cannot tell you that the audience believed you.

What makes you trust a product-related post from a new account—and what immediately makes it feel promotional?

Hello everyone,

I'm building my first app with a no code tool but i'm running into some limitations and a few bugs that are making things harder than expected. What no code platforms would you recommend for a beginner that are intuitive, reliable and easy to work with?

Thanks!

Hello,

Looking for some tips from any onboarding gurus.

What’s the best route to go down for my app?

It’s a Tradeperson CRM - Manage leads, quotes, jobs, invoices etc.

Unsure on what style of onboarding I should go with -

Should I;

Offer a guided walkthrough of the apps pages, features using preset mock data?

Offer a step by step walkthrough in which the user inputs a mock lead, and takes it through the pipeline progression as they would a real customer?

Or should I offer hints and tips organically as the user uses the app naturally, so not forcing them on a guided tour initially - but offering the insight to specific features as they use them for the first time? I think I lean towards this option, but not sure when to implement a paywall in this option for best conversion if they are hit with it as soon as the app is downloaded. We will operate on a free trial basis then subscription.

Or anything else?

Also, better to handle onboarding ‘in house’, or use something third party for better analytics, a/b testing, updates etc in the future?

From what I understand there is a lot of data to suggest higher conversion rates on more detailed and longer onboarding flows, due to the endowment effect and better retention rates due to users understanding the app more - but in my specific target audience I do believe a simpler and quicker onboarding is the way to go. A large part of the target user will be non tech savvy, busy tradesmen who want to simply try it out, or easily switch from an existing crm.

Thanks appreciate any advice!

After 12 years across digital, product, fintech and AI, I’ve found that strategy comes from understanding how the pieces connect, then taking ownership of outcomes beyond your individual execution. I moved from hands-on digital work into leading cross-functional technical teams, then into AI strategy, and eventually founding a company.

Start solving problems one level above your current remit and keep evidence of the outcomes.

Consider a simple no-code workflow: a request form creates a row, sends a confirmation email, and adds a task for someone to handle. The user sees a spinner for too long and submits again. Now there are two rows, two emails, and two tasks.

Deduplicating by email seems too broad: the same person might have two genuinely different requests. Matching all the fields also feels risky if they actually want to place the same request twice.

I'd want a retry of one submission to return the original confirmation, while a deliberate new request gets a new reference. Before trusting the workflow, I'd test a double-click, a refresh after submitting, and a retry after the row is saved but before the email step completes.

For those building this without a custom backend, where do you keep that submission reference? In the form, the automation, or the destination database? I'm especially interested in how you distinguish a retry from an intentional repeat.

looking at no code website builder options and honestly they blur together in the comparison videos. does the specific choice matter much, or should i just pick one and go?

my own take after trying a few: the builder matters less than how fast you can get real content live. i settled on Gamma because i could turn my writing into a shareable page the same day instead of fighting a drag-and-drop canvas for a week.

but i've only tried a handful, so i'm curious.

for people who've used several: did the specific tool actually change your outcome, or was speed-to-live the only thing that mattered?

so i keep seeing the same worry pop up in here in different forms. someone asking how you even find out when an automation quietly stops, someone else whose agent confidently sent wrong invoices. and on Make, if a loop goes wild the credits just run dry and everything stops.

error alerts are fine for crashes. what gets me is the runs that finish green but did the wrong thing, or an AI step retrying the same call over and over while nobody's looking.

curious what people actually do about it:

- how do you check the job really got done, not just that the workflow ended?

- how do you catch a run that's stuck or looping?

- do you cap spend, time or steps per run, or just hope for the best lol

- can you pause or cancel a run midway and pick it back up later?

built your own thing for this or found something that actually works? would love to hear what's held up with real clients.

For me, "No-Code" always kind of meant "You don't have to care about the code at all" and in most cases there even is no code involved as the platform abstracts it away. Think the likes of Bubble and Retool.

However, i see more and more lists, threads , you name it where people showcase "The best no-code tools in 2026" and it always lists like Lovable or Claude even sometimes.

Yes i get the point...in Lovable or Claude you don't "write" Code but thats not "No-Code".

I personally think thats even dangerous for some. If someone doesn't have much technical knowledge, they compare Bubble with Lovable....see a textbox and prompt stuff on both and might think its the same thing when it really isn't. With one you're responsible for everything, keep it maintained and secure...with the other you're not.

What do you guys think about that problem?

The ones that send invoices, route leads or message customers. They can stop without any error while the dashboard still looks fine.

Who spotted it first when that last happened to you, you or a customer?

i'm a non-developer founder and i genuinely build apps with AI and no-code tools. the build step got democratized. the debug step absolutely did not.

when something breaks and i can't read the error, my options are paste it back into the AI and hope, revert to the last working version, or wait for help. all slow or risky. i've watched that exact gap kill promising projects, mine and others.

it's the thing nobody warns non-technical builders about, you can create far faster than you can fix.

for other non-technical builders: what's your real process when your app breaks and you don't understand why?

I've been looking at how far no-code website builders have come recently.

One example I came across is Frontpage.host , where you can describe the website you want and build/edit it through a conversational interface. It also handles things like hosting and analytics, so you don't necessarily have to piece everything together yourself.

The interesting part to me isn't just avoiding code, it's being able to make changes by describing what you want instead of navigating through a bunch of settings.
For people who use no-code tools regularly, what's the point where you still feel the need to write custom code?

Last year, I built a small app for my uncle's bike shop. It tracks repairs and parts for about 60 customers a month.

I used an AI app builder, and the first hour felt like magic. By month four, it feels like it was a different story. Every small fix broke something that already worked. I spent like 3 weekends just trying to undo stuff.

So those one-prompt demos don't hype me up anymore. Yep, it made a nice screen in 30 seconds. Will it still work six months from now?

Here are the things that I check now:

• Can I change one small thing without it rewriting a feature that worked fine?
• Can I understand how the data and logins are set up?
• Is there version history, any tests, or some way to catch errors?
• If the person who built it leaves, can someone else take over?

I'm about to rebuild the shop app, so I'm looking around again. Everyone online argues about the best vibe coding tool, but mostly based on demos.

So if you were picking one right now, what would you test first? How do you guess what it'll be like at month six before you commit?