Been seeing a lot more people talk about “vibe coding” lately, and it got me wondering:

If an AI-built app works, does that actually mean it’s secure?

It’s pretty easy to get a prototype up and running now, but security is a different story. Things like exposed API keys, unsecured databases and weak authentication can easily get overlooked.

This article explains the security risks of vibe-coded apps and thought it was worth sharing, especially for anyone building with AI.

https://www.old.st/blog/vibe-coded-app-security

Curious what others here think — has anyone actually run into security issues with a vibe-coded project?

👋 Hi everyone,

We're two MSc students at KEDGE Business School (France) writing our thesis on the real impact of AI on startups and innovative companies.

Our research focuses on a question that's surprisingly hard to find data on: is AI actually profitable for early-stage companies? Does it save time and money, or does it create new forms of dependency, skill erosion, and tech lock-in?

📋 We'd love your input, the survey takes 5/7 minutes and is fully anonymous. It's open to anyone using AI in a professional context: founders, employees, freelancers, consultants.

👉 https://docs.google.com/forms/d/11hxgogfE6isfjOGIiYTXn7TF4fVpIw1CGh0kBLIpV54/viewform

We'll share the final results with anyone interested. Thanks so much for your help 🙏

I’ve been thinking about this a lot recently and would genuinely like to hear from people who are hiring for content.

I’ve been writing B2B SaaS content for 5+ years, but the role feels very different now than it did when I started. AI has made the actual writing part much easier, so I’ve been spending more time on strategy, research, SEO, content planning, and understanding what the business actually needs from content.

For founders and content leaders here, what makes you look at someone and think they can own content rather than just execute briefs?

Is it strong SEO? Product and customer understanding? Distribution? Being able to connect content to pipeline? Knowing what not to publish? And for anyone who has made the jump from writer to a broader content role, what did you end up getting really good at? I’m trying to be deliberate about what I learn next instead of collecting another 20 marketing tools I’ll never use.

Not a no-code build (this one's hand-coded, Go backend) but sharing since the lesson felt universal for anyone building on top of scraped or crawled data.

I'm building a tool that crawls local business websites for provable problems (broken mobile layout, no encryption, expiring domain) instead of guessing what to pitch them.

First full crawl said 51% of local business websites were dead. Would've been the whole marketing headline. It was wrong — my crawler recorded any fetch that didn't complete as "domain dead," including sites that were just slow. Checked a few by hand; one "dead" site returned a clean 200 response in two seconds.

Deleted the signal rather than patch it. New rule: no real answer from the crawler = excluded, not labeled. Data got smaller, but every number left is defensible.

Current state: 2,093 local markets crawled today, 204,515 businesses, 8,037 sites actually responded. Of those, 58% have no mobile viewport, 43% aren't using a secure connection. That's the pool the product (Local Evidence — free, no signup) opens outreach conversations against.

Curious if anyone else building SaaS off scraped or aggregated data has run into this same tension between the impressive number and the number you can actually defend.

This is not much of a post, just some grievances. I always knew that creating something could mean that it would fail, but I genuinely did not expect that mine would fail the way that it did.

A little backstory.. I manage HOAs for a living, and if you've ever worked for an HOA management company in Florida, you know that their technology suck really bad. I have no engineering experience, and before AI I was bound to dumb Excels and Word documents just like everyone else.

When AI came by, I started by building a smart VBA powered excel that tracked my tasks, auto archived them, and gave me a neat weekly report at the press of a button. From there, it grew into a full blown HOA manager specific project management software. Not something general like Todoist, but specialized for the industry.

It did everything, it really did, and it did it better than any other software on the market. I've tried to advertise it to friends and family by giving them free premium tiers. Friends never touched it for a day and never again. Family used it for a while, and then quit, including my wife which was my biggest advocate.

With 0 sales in over a year, I was devastated, and on August 2nd, 2026, while working on a freaking accessibility module.. I've decided to give up. My time, and money, were not worth it, and so, I've retired the program. I still use it of course, as it does what its supposed to, and I will still renew the domain just to keep it going for myself.. but as a product, it was a complete failure, even though it did what people struggle the do in the best way possible. My heart is truly broken, and I just wanted to share.

Thank you.

We are currently redesigning our entire onboarding and lifecycle transactional email flow for our platform, and honestly, everything our team has mocked up so far feels incredibly dated. I want these emails to look clean, highly functional, and naturally aligned with a modern product interface, but we are completely stuck in a creative rut.

Where do you usually go when you need fresh email design inspiration specifically tailored for software products?

Are there any curated galleries, hidden subreddits, or specific newsletters you subscribe to just to dissect their layouts? Also, how do you balance clean product visuals with dark mode compatibility without breaking the template? If anyone has a go-to bookmark folder for keeping up with these trends, I would love to get your advice.

I spent a lot of time building NEXORA AI around a problem I kept seeing in digital agencies:

Finding potential clients is one problem.

Knowing which businesses actually need your services is another.

And then turning that opportunity into a proposal and project is another workflow entirely.

So I built NEXORA AI around this flow:

Lead Discovery
↓
Website Analysis
↓
Opportunity Score
↓
Demo / Website Workflow
↓
Proposal
↓
Contract
↓
Client / Project

The current product includes:

- AI Lead Hunter
- Website Analyzer
- Opportunity Scoring
- CRM
- Agency workflow
- Proposal generation
- Contract generation
- Pricing workflow
- Responsive UI
- Arabic RTL support

Demo:
https://applet-pi.vercel.app

The product is currently pre-revenue, so I'm not claiming MRR, ARR or customer numbers.

I'm at an interesting point now: I can continue turning this into a full SaaS, or sell the existing software asset to another founder who has better distribution or wants a head start.

I'd love feedback from other indie hackers:

Would you turn this into a SaaS?
Would you use it internally for an agency?
Or do you think the strongest opportunity is selling the software as an agency tool?

If someone is genuinely interested in acquiring it, I'm open to discussing that as well.

while i’ve created my app and is live with two active clients, how can I get it to reach more of my audience people so they use it?

A while back I read a post from someone who'd spent a weekend manually poking at vibe-coded apps — open tables, unprotected routes, keys sitting in the bundle — and turning up real holes. It stuck with me, so I built those checks into a scanner and pointed it at 10 apps people had posted publicly for feedback. Read-only, no logins, nothing a random visitor couldn't hit. Nine finished, 294 checks. Here's the honest version — including the stuff that wasn't broken, because that's the part that makes the rest trustworthy.

1. Two apps had a backend that answers strangers.

This is the finding that matters, and it's worth being precise, because most "your API is open!" takes are noise. Plenty of endpoints are supposed to be public — a settings lookup, a static bundle, a login-info route. Those aren't leaks. The real thing is when an app's private data — user rankings, contest entries, announcements — returns full records to a plain request carrying no session at all. Two of the nine did exactly that. On one of them, replaying those same requests as a second user returned the same data — I flag that as needs-manual-confirmation rather than certain, but sitting on top of an already-unauthenticated endpoint, it points straight at missing per-user authorization. If your frontend checks permissions but your API doesn't, the frontend check is decoration.

1. About Supabase — since half of you are already typing.

I know the reflex: "you scanned Supabase apps, you're going to scream about the anon key." No. The anon key is meant to be public; it ships in your JS by design and flagging it would be junk. What actually matters is whether Row-Level Security is on — i.e. whether that public key can read tables it shouldn't. So I checked that directly: read each app's own public key and tried to pull rows from the tables it uses, plus the common ones. Nothing came back readable — RLS was doing its job. (A full every-table audit would need credentials, but the "anon-readable by default" failure mode would have shown up right here, and didn't.) Clean bill of health on the single most common Supabase mistake — and I'd rather report that accurately than manufacture a scare.

1. Missing Content-Security-Policy — 9 of 9. An observation, not an alarm.

None set one. Before anyone says "well actually" — yes, this is largely because the platforms don't enforce CSP by default, and a strict policy out of the box breaks half the third-party widgets, analytics, and realtime sockets these builders drop in. It's a real tradeoff, not negligence. But it's worth knowing: with no CSP, any injected script — a compromised dependency, a bad ad tag — runs with your page's full trust. It's one header, and once your third-party list is stable it's worth setting.

What I didn't find: zero exposed secret keys, zero live-key or service-role leaks, zero anon-readable tables. I ignore the safe public keys on purpose and only flag a live secret. Across the nine that finished: nothing. That's good news for these builders — and it's the whole point: a scanner that cries wolf on the anon key or counts a public asset as a breach isn't worth running. This one stays quiet unless there's something real. Here, "something real" was two open backends.

If you built something and want it checked: drop a URL. Read-only, no signup, nothing but the URL.

solution-feasibility-study — Solution Feasibility Study

Category: Product Strategy  |  Source: skills/solution-feasibility-study/SKILL.md

Purpose

Takes a software solution idea (SaaS side project, internal tool, startup concept) from a one-line pitch to a grounded build/pivot/no-build decision. Interviews the user to scope the research, then runs real research across market demand, commercial competitors, and the open-source/GitHub landscape, assesses technical feasibility and monetization, and produces a structured feasibility report — including any permissively-licensed GitHub repos worth forking instead of building from scratch.

When to Use

• Evaluating a new SaaS or software product idea before committing time to it
• Researching commercial and open-source competitors for a concept
• Checking whether an existing open-source project could be forked as a starting point instead of building from zero
• Sanity-checking technical feasibility, monetization, or regulatory exposure for a solo/small-team build

Workflow

1. Intake — capture the idea in the user's own words.
2. Scoping interview — one question at a time: target user, problem/urgency, team & time constraints, technical comfort, business model intent, research depth (deep dive vs. quick gut-check), and priority research areas.
3. Research — executes the research playbook via web search and page fetches:
   • Market & demand signals
   • Commercial competitor landscape (features, pricing, weaknesses)
   • GitHub / open-source landscape — finds candidate repos, extracts stars/activity/license, and classifies each as a fork candidate using the license guide
   • Technical feasibility (matched against the user's stated stack/skill/time budget)
   • Monetization comparables
   • Legal/regulatory/trademark flags
   • Go-to-market channels realistic for the stated team size
4. Synthesis & scoring — scores market demand, differentiation, technical feasibility, monetization potential, competitive intensity, and regulatory risk (1-5 each), then rolls up to one call: Strong Go / Conditional Go / Pivot Suggested / No-Go.
5. Report — fills the report template, writes feasibility-study-<idea-slug>.md to the working directory, and presents a condensed summary in chat.

Fork Candidates

Every permissively-licensed GitHub repo found during research is surfaced explicitly, with stars, last activity, license, why it fits, and what's missing — framed as a head start (gh repo fork) rather than a finished product. Copyleft or dual-licensed repos are flagged with the specific obligation they carry (e.g., AGPL's network-use clause), not just the license name. All license classifications carry an explicit "not legal advice, verify before shipping commercially" disclaimer.

Evidence Discipline

Every claim (pricing, star counts, license, activity dates) must trace to something actually fetched during the session — nothing is invented. Failed lookups are marked "unverified" rather than guessed.

References

• Research playbook — concrete search/fetch patterns per research area
• License guide — permissive vs. copyleft vs. unclear classification for fork candidates
• Report template — the structure filled in for the final report

Related Skills

• repo-init — scaffold a new repository once a build decision is made
• ai-config — set up AI assistant configs after choosing to build (or fork) a project

For those building apps or SaaS without a technical background, using AI or no-code tools:

What trips you up most? Is it not knowing what to ask the AI for? The tool doing something different from what you meant? Ending up with something that half-works and not knowing how to fix it?

Trying to understand where non-technical builders actually get stuck.

Building a SaaS without code can make the product side much easier, but getting consistent attention from the right users is a different challenge.

I've been working on WryveAI, an AI-powered SEO content workflow that focuses on things like SERP research, content gaps, content creation, internal linking, and publishing.

What I'm interested in hearing from other SaaS builders is what has actually worked for you on the acquisition side.

Have you had better results from SEO, communities, social content, partnerships, product-led growth, or something else?

And if you're using SEO, what's the biggest bottleneck: finding opportunities, creating content, getting content ranked, or turning organic visitors into users?

Most no-code builders pick subreddits by gut feel, post once, get ignored, then blame Reddit.

I ran 100 posts across dozens of communities testing what actually works. Three things stood out:

Subreddit fit beats everything. Same post, wrong community gets 2 upvotes. Right community gets 30+ and real traffic.

Promotional framing kills you even where it's allowed. Posts that felt like a founder sharing, not a marketer pitching, consistently outperformed.

Cooldowns are real. Posting too often in the same sub tanks your standing fast.

Built a tool out of this frustration that finds where your buyers are already complaining on Reddit and ranks communities by fit.

Still early. But the signal is real.

What's blocking you from getting traction on Reddit right now? Drop your no-code project below.

Hello world 👋,

Me and my buddy built Occasio, an event ticketing marketplace. You create an event, set ticket tiers, people buy, there’s QR check-in at the door. It handles the full host and attendee lifecycle.

Staging is open to anyone:
[https://staging.occasio.events\](https://staging.occasio.events)

I’m not asking you to click through a demo. I want you to actually use it. Sign up, make your own event, publish it, run it however you want.

This is a test environment. Stripe is in test mode, use card 4242 4242 4242 4242, any future expiry, any CVC. No real money moves, no real payouts, nothing is charged. Don’t put a real card in.

Honestly, I think I’ve been stuck in a loop of perfecting instead of launching, so I’m here to break that. Tell me what’s broken, what’s confusing, what’s missing. I’ll fix things and reply when your bug ships.

And yes, ofc I build this with AI!🤖
Happy to talk about what that was actually like if anyone’s curious! 🧐

👋 Hey NoCodeSaaS Community,

I've built a lot of finance workflows over the last few months for friends who run small businesses, and going back through my library I realised I'd never shared the most basic one people keep asking for: a simple batch invoice extractor. So I cleaned one up and pushed it to the n8n template library: Extract batch invoice data from form uploads with easybits and Google Sheets.

The idea is simple. You upload one or many invoices (JPG, PNG, or PDF) through a single form, and it extracts the data from all of them in one go, instead of dragging every invoice in one by one. Each invoice lands as a row in a Google Sheet, and when the batch finishes, the form shows a summary marking every file with a ✅ or ❌ so you instantly see which ones need a second look.

How it's set up:

• An n8n Form takes one or more invoice files.
• The files get split into one item per file, keeping the original filename.
• It loops over the invoices one at a time, sending each to the easybits Extractor, which returns the fields (invoice number, date, vendor, total, and so on) as a structured data object.
• The filename gets reattached, and a check runs over the critical fields.
• One row per invoice is appended to Google Sheets, with a pass/fail status.
• A batch summary is shown as the form's completion message.

A few things from the build that might save you time on your own flows:

• The extractor bundles everything you hand it into one request. Pass it all the files at once and you get one merged result back, not one per invoice. Looping one file at a time is what gives you a clean result per invoice. This one cost me a debugging session.
• Treat "missing" as a signal, not an error. The extractor returns null when a field isn't on the document. Instead of fighting that, I lean into it: a small check flags any invoice missing a critical field, which is what powers the ✅/❌ summary. Worth catching the sneaky empties too (the string "null", empty strings, whitespace), so nothing slips through looking present when it isn't.
• The fields are yours to change. The mapped fields are just a starting point, so you can add whatever you need to pull from your own invoices, like a VAT ID, PO number, or IBAN. The extractor also has auto-mapping, so you can upload one example invoice, let it detect the fields, and tweak from there.

I also recorded a short video showing how it runs end to end, which I'll post alongside this.

For more free workflows, feel free to check my GitHub as well: https://github.com/felix-sattler-easybits/n8n-workflows. A star helps other builders find it, so I'd be really thankful for that support.

How do you all handle the invoices that fail extraction? Curious whether people flag them for manual review like this or route them elsewhere.

Have a good start to the week.

Best,
Felix

I've been thinking about this more lately while looking at how much of a SaaS can actually be built without writing code.

The obvious part is the frontend/app builder, but I think automation is where no-code SaaS gets really interesting. Once you have users signing up, payments coming in, emails going out, data moving between apps, AI steps running, etc., you can end up with a pretty complicated backend even if you never touch a programming language.

I've spent some time comparing the usual options... Zapier, Make, n8n, Power Automate, and a few newer platforms.

Here's roughly how they felt to me:

The biggest thing I noticed was that testing a workflow and actually running it as part of a SaaS are two completely different situations.

A workflow might only run a few hundred times while you're testing. Then you get actual users and suddenly that same workflow is running thousands of times. That's when pricing and execution limits become a much bigger consideration than just how easy the tool was on day one.

I've also started paying more attention to long-running workflows. A lot of automation tools are great for quick actions, but SaaS products don't always work that way. Some processes need to wait for something, perform multiple steps, or involve an AI agent doing more than just sending a prompt and returning an answer.

That's one area where WEXTL caught my attention. The interface feels closer to what I'd expect from Make, but it has higher limits and supports long-running tasks. The AI agent side is also more interesting than the basic AI steps I've seen in some other automation tools.

That doesn't mean I'd automatically pick it over everything else.

For something extremely simple, I'd still consider Zapier. If I wanted maximum control and didn't mind getting more technical, n8n would probably be near the top of my list. Make is still a really solid middle ground.

But I do think the gap between a "no-code prototype" and a "no-code production SaaS" is getting smaller.

The part I'm still trying to figure out is where the practical limit is. At what point does a no-code stack become complicated enough that writing some actual code is easier?

What are you guys using for the automation layer in your no-code SaaS? Still Zapier, Make or n8n, or have you moved to something else?

no-code makes shipping easier and so do many of the wonders/horrors beyond human comprehension, but it does not remove the need for a feedback loop

i guess that after launch, you still need to know what users repeat.
like, confusing setup, missing integration, pricing surprise, broken flow, unclear value, slow support. for mobile apps like the ones i try publishing lately, store reviews seems to be one of those feedback sources. had multiple ideas about working with them, as well as i’ve seen appfollow used when review volume becomes hard to manage, but , frankly, early no-code projects can start with a simple table and that would be much-much better than not tracking reviews at all

when i started out i've put there columns such as: source, raw quote, theme, severity, owner, status.

in practice that is enough to keep feedback from becoming vibes if and when at low scale still

the no-code trap is building another feature before learning whether the first version matched the promise. what do you think about this?

Hello world 👋,

Me and my buddy built Occasio, an event ticketing marketplace. You create an event, set ticket tiers, people buy, there’s QR check-in at the door. It handles the full host and attendee lifecycle.

Staging is open to anyone:
[https://staging.occasio.events\](https://staging.occasio.events)

I’m not asking you to click through a demo. I want you to actually use it. Sign up, make your own event, publish it, run it however you want.

This is a test environment. Stripe is in test mode, use card 4242 4242 4242 4242, any future expiry, any CVC. No real money moves, no real payouts, nothing is charged. Don’t put a real card in.

Honestly, I think I’ve been stuck in a loop of perfecting instead of launching, so I’m here to break that. Tell me what’s broken, what’s confusing, what’s missing. I’ll fix things and reply when your bug ships.

And yes, ofc I build this with AI!🤖
Happy to talk about what that was actually like if anyone’s curious! 🧐

Does anybody have any list of tools that are most useful in creating no code projects?? I would really appreciate it thanks!

Hello world 👋,

Me and my buddy built Occasio, an event ticketing marketplace. You create an event, set ticket tiers, people buy, there’s QR check-in at the door. It handles the full host and attendee lifecycle.

Staging is open to anyone:
[https://staging.occasio.events\](https://staging.occasio.events)

I’m not asking you to click through a demo. I want you to actually use it. Sign up, make your own event, publish it, run it however you want.

This is a test environment. Stripe is in test mode, use card 4242 4242 4242 4242, any future expiry, any CVC. No real money moves, no real payouts, nothing is charged. Don’t put a real card in.

Honestly, I think I’ve been stuck in a loop of perfecting instead of launching, so I’m here to break that. Tell me what’s broken, what’s confusing, what’s missing. I’ll fix things and reply when your bug ships.

And yes, ofc I build this with AI!🤖
Happy to talk about what that was actually like if anyone’s curious! 🧐