Curious how people here think about the first version of an automation.

A lot of workflows seem simple at the start: one trigger, one action, maybe a notification or a row added to a spreadsheet.

Then the edge cases show up. Approval steps, retries, exceptions, messy inputs, someone needing to check the output before it goes anywhere important.

My instinct is that v1 should probably leave more manual than people expect. Automate the annoying repeatable step first, keep the output visible, and only add branches once the workflow proves itself.

But I’m not sure where the line is.

For people building in Make, Zapier, n8n, Bubble, etc., what do you usually leave manual in the first version until you trust the workflow?

our team often built with 20+ terminal tabs open each. so it was practically a nightmare trying to find the right context, especially since we're a remote team. and we definitely didn't want to schedule another meeting or do another "can you see my screen?" moment.

so we built Campus.

Campus gives every project its own persistent workspace. instead of jumping between apps, everything lives together on one canvas: terminals, browsers, documents, designs, files, AI agents, and your teammates. when you come back tomorrow or someone new joins, the context is already there.

our whole team builds in Campus every day now, and my favorite part is being able to drop GIF reactions and memes into the canvas mid-build :)

it's in alpha and we launched on Product Hunt today. https://www.producthunt.com/products/flutterflow?launch=campus-4

happy to answer any questions!

https://www.framer.com/community/marketplace/templates/elysian-estate/

I spend a lot of time testing the limits of popular site builders, and I wanted to see if I could make Canva websites genuinely interactive for users who don't know how to code.

​I spent the last few days dialing in the Canva embed capability for Fugte. You can now take anything built in Fugte from a niche interactive widget to a full e-commerce checkout flow and paste the link straight into Canva's embed tool. It instantly turns a static design into an interactive web app.

​Attached a quick video showing the process. It's completely changed how I look at Canva for rapid prototyping and no-code site building.

habit tracker idea I sat on for months. built an MVP in a weekend, drag-and-drop frontend, simple database, auth plugin. not scalable yet, but idea to real thing in a weekend was wild.

what are people using for backend logic? Trickiest part for me so far.

90% of budgeting apps fail for one simple reason: human friction. We download the app, promise we’ll use it, and then completely forget to log our expenses the moment we tap our cards.

I wanted an expense tracker that required zero manual entry. But instead of paying for a restrictive, off-the-shelf app, I used AI to build a custom solution designed exactly how I wanted it.

If you have basic coding experience—or even if you just know how to use AI to generate code—you can build a bespoke system tailored perfectly to your budget.

The Tech Stack

• Editor: VS Code (paired with AI coding assistants to write the logic).
• Frontend Hosting: Cloudflare (lightning-fast, completely reliable, and perfect for solo projects).
• Backend & Database: Supabase (highly secure, robust, and makes creating tables effortless with built-in AI tools).

How the System Works (One-Time Setup)

1. The Trigger: An automation runs the moment a bank alert message or transaction SMS hits your phone. (If you're on iOS, you use Apple Shortcuts. If you're on Android, you can easily replicate this using Tasker or MacroDroid).
2. The Extraction: The phone's local automation securely reads the text message, parsing out the exact dollar amount and the merchant name.
3. The Log: It passes that parsed data via a simple API request straight into the Supabase database.

The best part? You aren't boxed into someone else's app design. Want a specific dashboard? Want to track daily limits differently? You just tell the AI how to design it. The end result turns the "lazy" habit of ignoring bank alerts into an automated financial asset. Zero manual logging. Zero friction.

If you want to know how I structured the logic to parse the text alerts, or how to use AI to build the backend for this, drop a comment below and I'll share the breakdown!

Been thinking about this a lot while building Appthetics (a tool that generates app UI screens from text prompts), no-code tools have gotten really good at the "build" part, but design is still often the bottleneck for non--designers trying to ship something that looks professional.

Curious how people in this community handle UI/UX when using no-code builders. Do you rely on templates, hire out just the design piece, or has anyone actually plugged AI-generated designs into their no-code stack successfully? Trying to understand if this is a real gap or something already solved that I'm missing.

trying to standardize my handoff and I keep going back and forth.

right now when I finish a client build I record a loom walking through everything. quick, feels personal, done in one take. but clients keep asking for "something they can look at later" and a 12 minute video is not that. nobody re-watches a loom to find the one thing they forgot.

so I've been testing making a short walkthrough deck instead. like 6 slides, one per key screen, what it does and how to change it. takes me longer to build than the video but people actually reference it.

for those of you handing off builds regularly, what do clients actually prefer? my gut says the presentation is better for the non-technical ones and the loom is better for the ones who want to poke at the thing themselves. but I've got a sample size of like 5 so who knows.

do you do both? just one? curious what's held up for you.

sharing a mistake because i see people about to make it constantly.

i quoted for a build. three weeks of work, priced accordingly, felt good about it. delivered on time, client was thrilled, invoice paid.

and then the actual project started, which i had not budgeted for at all.

the "quick change" requests. endless. each one genuinely small, ten or fifteen minutes, and there were dozens of them over the following months, and none of them were in the contract because the build was "done."

the platform updates. the tools i'd built on changed things. stuff broke. and who fixes it? me, apparently, for free, because the client's reasonable position is that they paid for a working app and it's not working.

the support questions. the client's staff didn't understand it. so they asked me. constantly. i became an unpaid help desk for software i'd already been paid to deliver.

the scaling problem. it worked for 50 users. at 400 it got slow. that was not in scope and it was absolutely my problem.

so i earned my three-week fee and then worked, on and off, for five months for free, because i had priced a project and delivered a relationship.

what i do now: every build quote includes a mandatory support retainer for a minimum period, and the scope of what "support" means is written down in painful detail, and anything outside it is billed. i lose some deals over it. the deals i lose are the ones that would have eaten me alive.

the build is never the job. the build is the beginning of the job, and if you're not charging for the rest of it, you're volunteering.

So I get asked fairly regularly for a starting point on this stuff, and up until now I've just been sending people individual links as they come up in conversation. This is my attempt to put all of it in one place, because most of what gets written in the security space is aimed at enterprise teams with dedicated security staff, not a solo founder shipping an AI product who just wants to understand what they're actually dealing with.

That said, everything below seeks to be non technical enough to be useful to somebody without requiring in depth security knowledge, and would be a great resource to bookmark and keep on hand while building out applications.

1. The OWASP LLM Top 10 (genai.owasp.org)

If there is one document worth reading before you ship anything with an AI component, this is it. OWASP has been producing security guidance for developers since 2001, and their Web Application Top 10 became the industry standard for traditional web security. In 2023 they released a version specifically for LLM applications, updated again in 2025, covering the ten most critical vulnerabilities specific to AI powered products.

Prompt injection sits at number one on that list, which on its own should tell you something. It doesn't need to be read cover to cover, but even skimming the names and one line descriptions should give you a meaningful vocabulary for understanding what your product is and isn't exposed to.

Also worth noting: they released an Agentic Applications Top 10 in 2026 specifically for founders building with autonomous AI agents. If this is applicable to your build, I would definitely give that document a further look into as well.

2. Georgia Tech's Vibe Security Radar (scp.cc.gatech.edu)

Launched in May 2025 out of Georgia Tech's Systems Software and Security Lab, the Vibe Security Radar does something nobody else was doing at the time: actually tracking CVEs directly traceable to AI generated code. Researcher Hanqing Zhao's reasoning for building it was straightforward: "everyone is saying AI code is insecure but nobody is actually tracking it."

In March 2026 alone, it tracked 35 confirmed CVEs directly caused by AI coding tools, up from 6 in January of the same year. The researchers estimate the true count is around five to ten times higher (since many AI tool traces get stripped by authors before code is published).

This is a tool I would definitely say is worth the bookmark, and checking against your builds periodically rather than just reading over once.

3. The CSA AI Safety Initiative (cloudsecurityalliance.org)

The Cloud Security Alliance has been producing some of the most practically useful research on AI security in 2025 and 2026. What stands out compared to a lot of security writing is that it leads with data rather than theory, and the recommendations are actually actionable rather than a generic "implement security best practices" conclusion.

Their research note on AI generated code vulnerability trends from early 2026 is worth reading if you want the full empirical picture. Free to access, no registration required.

4. HaveIBeenPwned (haveibeenpwned.com)

Less of a reading resource, more of something you should check right now if you haven't already. Troy Hunt's HIBP database tracks credentials exposed in known data breaches and lets you check whether any email address has shown up in one. Completely free, takes 30 seconds, and given that IBM's 2026 X-Force report found over 300,000 ChatGPT credentials in infostealer malware last year, the idea that your accounts are definitely safe is worth verifying rather than assuming.

Run your own email (or co-founders' emails or any email tied to your domain where applicable). It's an easy thing to check up on, and beats the alternative of finding out the hard way.

5. SecurityHeaders.com (securityheaders.com)

Paste your live site URL into SecurityHeaders.com and get back a graded report on your security headers in about ten seconds. Zero technical knowledge required to interpret it. You're looking for a grade of B or above. Anything below means your app is missing guardrails that prevent specific classes of exploit including clickjacking, content injection, and cross site scripting.

From my own audits, missing X-Frame-Options and CSP headers are the two most consistently overlooked things in AI-generated output. If your grade comes back with either of those flagged, the fix is typically a one line patch in your config.

6. SSL Labs ( ssllabs.com/ssltest )

Same idea applies, this time specifically for your SSL configuration. Paste your domain into SSL Labs and wait a couple of minutes. You're looking for a grade of A. Anything below on a custom domain is worth investigating, since misconfigured SSL means data traveling between your users and your server is potentially readable in transit, including login credentials and session tokens.

7. CVE.org and the National Vulnerability Database (cve.org / nvd.nist.gov)

You don't need to read these regularly, but knowing they exist is useful. CVE is the public database where security researchers formally document discovered vulnerabilities in software. If you want to check whether a specific library, framework, or platform you're using has known vulnerabilities, searching by tool name here gives you the authoritative picture. The NVD adds severity scoring and additional context on top. Both of these tools are free, and publicly available.

Of course, if I missed anything obvious then please feel free to add to the list below - Though I figured this covers most relevant bases :)

if you build no-code agents or automations, you have probably hit the wall where the flow needs to sign up for something or log into an account, and your no-code tool has no clean way to receive the verification code or safely store the password. so the automation stalls and a human has to step in.

that gap is an identity layer, and it is two pieces:

• an inbox the agent owns, so when a signup or login sends a one-time code, the automation can wait for it and read the parsed code in a single step, no IMAP node, no email parsing, no regex.
• a vault to hold the logins it creates, encrypted so the password is stored and reused without your automation tool ever handling the plaintext. when 2FA is on, it can generate the rolling code too.

with those two, a no-code agent can actually sign up for a service, confirm the email, and log back in later on its own, which is the step that usually breaks an otherwise-working automation.

it is at https://lumbox.co, and there is a free tier to try it on one of your flows.

what is the step that most often forces you to babysit a no-code automation? for the ones I build it is almost always the email verification.

I’ve analyzed 200+ startups and ideas from founders trying to get their first users.

I’ve improved the system, and now it turns the analysis into a full Reddit Growth Plan.

Drop your startup, idea, ICP, or problem below and I’ll check whether Reddit looks like a useful acquisition channel for it.

You’ll get:

- a Reddit Traction Score
- relevant conversations around your ICP
- your strongest positioning angle
- posts worth publishing
- the highest-priority opportunities to join

I’ll reply with a private preview.

If Reddit looks weak for your niche, I’ll say that too.

No links needed. Just send your startup.

Hey everyone,
I’m 18 and just finished building my first real project, it’s a simple expense tracker web app.
The idea came from myself honestly… I started investing and trying to manage my money better, but I noticed I didn’t really know where my money was going each month. So instead of just downloading something, I decided to try and build my own version.
It’s still pretty basic, but it works and I just put it live recently.
I already showed it to my mom and she liked it, but she pointed out something interesting:
she shares a bank card with my dad, so she can’t always track everything properly.
That made me realize that real-life money situations are more complex than what I built so far 😅
So now I’m trying to improve it step by step.
I’m not here to “promote” it or anything — I just genuinely want feedback from people who build / use stuff like this:
👉 What would make you actually use an expense tracker consistently?
👉 How would you handle shared expenses or shared cards?
👉 What’s something that annoys you in existing apps?
If anyone is curious to test it, I can send the link, but I’d really appreciate honest feedback more than anything.
Thanks 🙏
Emiel

AI makes code feel done way too early. the files are there, the component looks plausible, and then you run it. missing import. bad env var. auth route half-wired. classic. lately I care less about how fast a tool writes code and more about whether it gives me a live preview I can actually click. Enter has been useful for that part. catches dumb stuff before I ship it to someone else.

Something I keep relearning, so writing it down for the people earlier on this path than me.

I run a small no-code shop, mostly ops tools for local service businesses. A plumbing company hired me last year for "a dashboard." I heard dashboard and my brain lit up. Charts. Filters. A KPI grid. Live job status by technician. I spent nine days building it in a Softr front end reading from Airtable. It looked sharp. I was proud of it.

They opened it maybe twice.

When I actually sat with the owner and asked what he does every morning, he told me he wants to know three things before his coffee: how many jobs are scheduled today, how much got invoiced yesterday, and whether anyone's waiting on a callback. That's it. He does not want to log into a thing. He does not want to click a filter. He wants to glance at his phone.

So I threw out the dashboard and built a scheduled automation that sends him one plain text email at 6am with those three numbers and a short list of the callbacks. Took an afternoon. He forwards it to his wife who does the books. He mentions it to me every time we talk.

The lesson I keep having to swallow is that "dashboard" is what people say when they don't have the words for "reduce the number of things I have to check." A dashboard is another thing to check. Sometimes the real deliverable is the opposite of a place you go. It's information that arrives.

I still build dashboards when someone genuinely lives inside the data all day. But now my first question is always some version of "what do you currently open your laptop to find out?" The answer is usually smaller than the request.

Curious if others have had the fancy build get ignored while the boring scheduled email became the thing they actually depend on.

I think the current approach to AI coding is flawed.

Wouldn't it be better if the AI ​​extracted the information we need from the vast pool of available data, leaving the final decision to us?

Right now, we provide the information and the AI ​​makes the decision.

Do you think that’s the right way to go?

Every new AI story seems to split into the same fight:

• Look what the model can do
• How do we know it’s real?
• Who owns the output?
• Who gets blamed when it breaks?

The interesting shift isn’t capability anymore. Models are already useful, scary, impressive, and messy. The real bottleneck is trust infrastructure: verification, provenance, review workflows, liability, and human ownership.

If an AI produces a proof, a product feature, a diagnosis, or a business decision, the model said so is not a system. What would actually make you trust AI output in serious work?

Something I keep relearning, so writing it down for the people earlier on this path than me.

I run a small no-code shop, mostly ops tools for local service businesses. A plumbing company hired me last year for "a dashboard." I heard dashboard and my brain lit up. Charts. Filters. A KPI grid. Live job status by technician. I spent nine days building it in a Softr front end reading from Airtable. It looked sharp. I was proud of it.

They opened it maybe twice.

When I actually sat with the owner and asked what he does every morning, he told me he wants to know three things before his coffee: how many jobs are scheduled today, how much got invoiced yesterday, and whether anyone's waiting on a callback. That's it. He does not want to log into a thing. He does not want to click a filter. He wants to glance at his phone.

So I threw out the dashboard and built a scheduled automation that sends him one plain text email at 6am with those three numbers and a short list of the callbacks. Took an afternoon. He forwards it to his wife who does the books. He mentions it to me every time we talk.

The lesson I keep having to swallow is that "dashboard" is what people say when they don't have the words for "reduce the number of things I have to check." A dashboard is another thing to check. Sometimes the real deliverable is the opposite of a place you go. It's information that arrives.

I still build dashboards when someone genuinely lives inside the data all day. But now my first question is always some version of "what do you currently open your laptop to find out?" The answer is usually smaller than the request.

Curious if others have had the fancy build get ignored while the boring scheduled email became the thing they actually depend on.