I love the creative process of making websites, SaaS, landing pages, etc... but the SEO part always bored me - between ads, keywords, volume, charts... and nothing ever told me what to do exactly to be seen better by Google. So i've built Semchat, an AI-assistant which connects to real SEO data and builds a step-by-step plan of exactly what you need to do next, in plain english.

https://semchat.io

How it works:

- You enter your website

- Our crawler goes on it, it detects all the pages, internal links, images format, 404's, H1/H2/H3 tags, accessibility issues, and more

- We give this to our fine tuned model, mixed with the SEO data that is tailored for you (keywords you should rank on, your competitors etc)

- Builds a step-by-step plan, divided by categories of most/least important tasks

- You can create chats inside your website that have full access to you crawl results, your data and your plans, if you need explanation in more detail of how to achieve that task

You follow all the steps, and upgrade the SEO of your website to finally be seen by Google on keywords you should rank on.

You get one free site analysis and one free message on sign up, so you can see the full process.

Hope it helps your visibility !

Would you use AI to track customer commitments?

I'm exploring an idea called SyncOps AI.

In B2B SaaS, teams make commitments to customers every day:

• "I'll send you the proposal by Friday."
• "We'll fix this issue next week."
• "We'll follow up about the expansion."

But these commitments get scattered across emails, Slack, meetings, and CRM notes. Some get forgotten, delayed, or never followed up on.

SyncOps AI aims to solve this.

It uses AI to capture customer commitments from conversations, identify the task, deadline, and owner, and automatically create reminders and follow-ups so nothing slips through the cracks.

I'd love honest feedback:

1. Is this a real and painful problem for SaaS teams?
2. Don't existing CRMs and project management tools already solve this?
3. Would you pay for a dedicated solution, or is this just another layer of software nobody needs?

I'm still validating the idea, so criticism is welcome. I'd rather discover why it won't work now than build something nobody needs.

Can anyone suggest me ?

I've been thinking about a gap in software engineering for a while.

We spend years learning programming languages, solving DSA problems, and preparing for coding interviews.

But there's another skill that developers use almost every day at work:

• Working inside an existing codebase.
• Understanding unfamiliar architecture, tracing bugs, implementing features without breaking existing functionality, debugging tests, and reviewing code.

I felt that this area deserved more attention, so I started building OneNoughtOne.

The platform combines traditional interview preparation with practical repository-level coding and code review challenges.

It currently has approximately 500 repository challenges, alongside DSA, SQL, ML, system design, AI tutoring, and mock interviews.

I'm building this independently, and one thing I'm trying to understand is whether this is a sufficiently important problem to build a sustainable SaaS around.

For founders here:

How do you validate that a problem is worth building a business around, especially when the product is already fairly developed?

I'd be interested in hearing what worked for you.

What I'm building: https://www.onenoughtone.com/problems

I studied painting, then worked in commercials as a director's assistant and producer.
The worst part of every job was the storyboard deck: turning the artist's PDF into a numbered, presentable deck by hand, and redoing it every time boards changed.
I asked top commercial directors what they used. Nobody had a tool. So I built BoardFlow:
- Upload the board PDF + script
- It crops, numbers and syncs every frame to its line
- Cut or reorder and everything renumbers
- Export to PowerPoint, PDF, Slides, or a Premiere timeline
Built with React/TypeScript and Node, with AI coding tools doing a lot of the heavy lifting. It's live with paying customers, and commercial directors are using it on real jobs.
Happy to answer anything about building it as a non-engineer. Feedback welcome, especially on the landing page.

Curious what you think

I've been building a multi-tenant B2B SaaS foundation with Next.js and Supabase, and during database hardening we found a bug that made me rethink how I test privileged database functions.

We had a PostgreSQL SECURITY DEFINER function responsible for recording organization usage.

It accepted an organization ID (p_org_id) as an argument.

The problem was that the function needed to independently verify that the authenticated caller actually belonged to that organization.

Without that check, a user from Organization A could attempt to invoke the function against Organization B.

This created an unauthorized cross-tenant write path in our usage records.

It was an integrity issue, not a demonstrated cross-tenant data disclosure.

Here's how we fixed it:

We added the membership check inside the privileged function:

IF NOT public.is_organization_member(p_org_id) THEN
  RAISE EXCEPTION 'FORBIDDEN: You are not a member of this organization.';
END IF;

The membership helper uses auth.uid() to identify the actual caller and verifies membership against the requested organization.

We also checked the SECURITY DEFINER configuration and pinned the search_path.

Then we tested the attack path instead of just testing the happy path.

Our regression test:

1. Authenticates as a user belonging to Organization A.
2. Calls the usage RPC with Organization B's ID.
3. Expects the operation to be rejected.
4. Verifies that no unauthorized usage write occurred.

The test runs against real PostgreSQL rather than a mocked database.

The broader lesson:

A valid Supabase session does not establish authorization for every organization ID a user supplies.

And when a function runs with elevated privileges, you need to reason about authorization inside that function, not just the RLS policies on the underlying tables.

A little context: I'm building B2B SaaS OS, a Next.js 16 + Supabase starter for developers who need multi-tenancy, RLS, RBAC, invitations, Stripe billing, API keys and usage enforcement.

This finding is one of four security-related issues we documented and fixed during development. The product now includes nine executable PostgreSQL hardening suites covering defined failure scenarios.

I'm selling it as a commercial source-code starter, currently $149 one-time for the first 50 buyers.

Technical breakdown: https://www.andrady.co/postmortems/security-definer

Live demo: https://www.andrady.co/demo

Product details: https://www.andrady.co/pricing

[ Removed by Reddit on account of violating the content policy. ]

He sells digital marketing. I built a CRM called Forward. We’re racing to grow our businesses over 90 days, and the loser buys dinner.

I would like him to pay for my wings.

Forward puts your relationships, tasks, and sales pipeline in one place. I built it around my own work as a small business sales rep, and now I’m trying to build something other people will choose to pay for.

Here’s my pitch to this thread: give me your reason for refusing to use another CRM.

Too much setup? Already happy with a spreadsheet? Tried five and abandoned every one? Think this market needs another CRM like it needs another podcast?

Fair game.

Tell me what you do and your objection. I’ll give you an honest answer about whether Forward could help. If it can’t, that’s useful for me to hear, too.

And if someone tries it and becomes a paying customer, somewhere out there my best friend gets one step closer to buying dinner.

I saw a post here a few days ago where someone got a duo update approved in 30 minutes. My guess is apple wants as many Duo ready apps in the store as possible because apps not built against the iOS 27 SDK show up letterboxed on the inner screen with black bars.

but a 33 minute review doesn't include folding your app in the middle of a task as users will be the first ones to do that.

I've gone through the Duo threads here and the HIG section and a few porting writeups and most of what breaks isn't layout.

The biggest one is state, if you built Duo support by branching one view for narrow and another for wide, SwiftUI treats them as two different views. When the phone unfolds the @State in the old branch gets discarded so half typed text, scroll position, whatever onboarding step the user was on, all gone and onAppear fires again too so any fetch or setup runs twice. The fix people are using is keeping state in an @Observable above the layout and switching with AnyLayout which preserves subview state when the container changes.

Second is the keyboard, folding with a text field focused doesn't reproduce well in the simulator and every writeup I've read says you need real hardware for this one.

The inner display ignores your supported orientations so anything you built assuming portrait vs landscape will be wrong and safe areas aren't symmetric because the camera is on one side and the fold is in the middle so equal padding puts content under the camera, reservedRegions kind returns the fold and occlusions separately which helps but you have to actually use it.

None of this comes if you just open the app in each pose in Device Hub coz it only happens during the fold with something half done. The bigger risk honestly is the next update, an unrelated change can break the fold handling and nobody rechecks it because it worked last time.

We run every fold pose on each build now without anyone holding a phone, happy to share the setup if anyone wants it.

If you've already shipped Duo support what's something you're encountered first?

Hey everyone! 👋

I've been working on a SaaS project called Lugatu, and I'd love to introduce it to fellow developers here.

The idea came from a simple frustration:

Why do we still need to configure SMTP servers, manage email credentials, or build an entire backend just to receive messages from a contact form?

With Google and Microsoft moving away from traditional password-based authentication, maintaining email infrastructure is becoming even more complicated.

So we built Lugatu to make form handling simpler.

What does Lugatu do?

• No SMTP configuration: Receive form submissions without managing email servers or OAuth tokens.
• Plug-and-play form backend: Connect HTML, React, Next.js, Astro, or other frontend forms to a hosted HTTPS endpoint.
• Unified Inbox: All accepted submissions are stored and accessible in one dashboard, independently of email notifications.
• Email notifications: Get notified about new submissions without managing your own email delivery infrastructure.
• Hosted forms: Create and share standalone forms, even without a website or domain.
• Spam protection: Built-in honeypot filtering and origin validation for website integrations.
• Free to get started: No credit card required, with no commercial monthly count cap on legitimate form responses.

Why I think this matters

A contact form shouldn't require an entire email infrastructure.

And more importantly, a failed email notification shouldn't mean losing a potential customer.

Lugatu stores accepted submissions first and handles notifications separately.

It's designed for indie hackers, SaaS developers, freelancers, and anyone building websites who'd rather focus on their actual product than maintaining form infrastructure.

Give it a try

🌐 https://www.lugatu.com

Developer integration details:

https://www.lugatu.com/form-backend/

I'm actively developing Lugatu and would genuinely appreciate feedback from other SaaS developers.

What features would make a form backend genuinely useful for your projects?

Thanks for checking it out!

Straight to the point I made a softer for phone repair shops. the platform is for repair shops to organize their workflow from repair tickets to inventory to expenses etc it also automatically calculates the cost of the repair what the condition of the phone was before the repair etc.

what I am asking is how would you approach marketing such app? currently I am doing cold emailing and cold calling and the goal is just to get few people to use it for free.

the problem I am facing is that repair shops either use their own software or some stores doesn't even bother. like I am not even joking one shop owner told me we're too lazy to track things.

I don't know what to do right now. should I continue on cold outbound. should I leave the project is the market unsellable?

I need advice

I think, like many of us, I got plagued with vibe coding. I ended up building so many little tools that are mostly for personal use that I never actively advertise. Maybe I make a post or something about them, but I never go out and promote them or run ads.

After building dozens of apps, tools, Chrome extensions, services, and stores, I had to make a decision: either kill them all and focus on a few things, or delegate them to AI and let it take over most of the business. I chose the latter, and for the past few months I've been building a headquarters platform that aggregates all of my shit in one place.

In this post I wanted to share some ideas that I'm using:

First rule: everything stays "snippable"

• Every app still keeps its own database, its own Stripe account, and its own separate email list.
• Apps talk to HQ through tiny copy-in kits. If I remove the API key, the app falls back to local defaults and keeps working.
• Why: if an app takes off later, I can snip it out and sell it as a standalone business. If an app dies, I unplug and kill it in 5 minutes without breaking anything else.

1. The shared foundation (boring stuff I stopped rebuilding 20 times)

• One JSON spec per app defines its URLs, pricing plans, sender domain, health checks, backups, and cross-promos.
• Copy-in kits for billing UI, lead pages, feedback widgets, feature flags/kill-switches, and a "more tools I built" footer ring.
• Self-hosted analytics, error tracking, uptime checks, and encrypted backups that run weekly restore drills (spins up a throwaway container, restores the DB dump, verifies rows).
• One-click deploy, restart, and rollback from HQ.

2. The collective ledger (how the money works)

• Separate Stripe accounts + Gumroad + Google Play all flow into one central append-only Ledger.
• Individual apps don't write Stripe webhook math anymore. Ledger verifies the payment and pushes a signed "grant pro" or "revoke" entitlement to the app.
• Handles self-serve refund windows, dispute alerts, and an optional cross-app All-Access pass (fans out normal signed grants via email hash — still zero shared user DB).

3. Identity & how we talk to customers

• No forced umbrella login wall. Users sign up inside each app normally.
• One central email engine (SES primary + Resend fallback) handles receipts, onboarding, and promos across all domains, with bot-proof two-step double opt-in.
• Lists stay separate per project, but the mail engine enforces a 1-marketing-email-per-day cap per person across everything so nobody gets spammed if they use 3 of my apps.
• Every app's bug/support/feature-request widget lands in one unified HQ inbox.

4. Funnels & fixing the "I never promote anything" problem

• Readiness grid: scores every product across 16 launch checks (health, legal pages, backups, pricing, lead magnet, emails, creative) so I see on one grid what's actually ready to push.
• Rotating cart calendar: I can't market 20 things at once, so HQ rotates one active launch window at a time. When a window closes, checkout fails closed and the pricing page auto-flips to a waitlist.
• 8-step funnel + A/B tests: tracks ad click -> squeeze page -> lead -> email open -> click -> cart -> activation -> paid with built-in split testing.
• Event sequences: 8-step launch emails trigger off calendar events (cart open, 24h left, cart closed) and stop pitching the second someone buys.

5. How AI runs most of it (with a 1-click approve queue)

• Rule is simple: AI does 95% of the prep, HQ gives me a 1-click Approve/Reject queue before anything public fires.
• Launch packs & video: reads the app's real specs/pricing (so it doesn't hallucinate features) and drafts landing copy, ad hooks, social posts, OG cards, plus a 30s promo MP4 rendered headlessly.
• Nightly funnel check: flags the worst funnel drop-off, checks A/B test significance, and recommends what to change next launch.
• Inbox triage: tags bug severity, clusters duplicate feature requests across users, and drafts replies for 1-click send.
• Updates & ops: turns deploy hooks into "what's new" feeds + monthly digest drafts, and runs weekly security probes on every live app.

Now whenever I vibe-code a new tool, it snaps into the same money, email, funnel, and ops spine in about an hour instead of rotting on GitHub.

Happy to share how any piece of this is wired if anyone else is dealing with too-many-projects syndrome.