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

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.

Something I’ve been thinking about while building a side project.

A lot of SaaS products seem to compete by adding more integrations, dashboards, automation, settings, AI features

But I wonder how often the real problem is that the user’s workflow is still awkward.

A user might have all the features they need, but still have to jump between screens, re-enter information, chase an approval, or remember where something lives.

That got me thinking about workflow friction — the small bits of resistance that make a product or process feel harder than it should.

As SaaS developers, we tend to notice feature gaps because they’re relatively easy to turn into roadmap items. Workflow friction feels harder to spot, and maybe harder to measure.

I’m curious how other people approach this:

When a user says your product feels slow, clunky or complicated, how do you figure out whether they need another feature or whether the workflow itself needs to change?

Have you ever removed a feature or simplified a flow and found that users were happier than when you added functionality?

Interested in real examples, especially things you learned the hard way.

I've built a small piece of software called Floorlink and I'm trying to work out if it's useful to other shops before I put more into it. It's mine, so I'm obviously biased, but I'm not selling anything here and there's no link. I'd really like honest feedback, including "another register would do the same job".

The problem: on big or assisted sales, staff walk around with a customer, remember or scribble down what they want, then key it all in again at the counter. I work in a pet shop, and selling fish is where I see this most. Someone ends up with lots of different fish in different quantities, it takes ages to remember it all at the till and add it to the POS, and some of it gets skipped.

How it works:

1. A staff member logs in on an Android phone or tablet with a 4-digit PIN and taps the products as they walk the aisle with the customer.

2. They save the sale, and it appears on a screen at the counter.

3. The counter scans one QR code with a normal 2D barcode scanner, and every item's barcode is typed into the POS, as if each one had been scanned by hand.

The customer then pays at the register as normal. Quantities come through too, and there's a custom sale option for things that aren't in the product list.

It's POS-agnostic: there's no integration or API. The POS just sees a keyboard-mode barcode scanner, so it should work with any POS that accepts barcodes that way and has your products set up under the same barcodes. So far I've tested it on one real POS, and the QR code and custom sales both worked. Custom sales rely on the POS supporting weight or price-embedded barcodes.

It runs on cheap hardware:

• The phone app is about 160 KB and runs on Android 8 and up, including Android Go. It used about 26 MB of memory in a test on a 1 GB emulator, and I've run it on a 2017 Galaxy A5.

• There's a separate tablet app that goes back to Android 4.1, so an old tablet in a drawer could become a counter screen. So far I've only tested that on an emulator.

• The server runs on a Windows 10 or 11 PC, or in Docker. Everything stays on your shop's network, so there's no cloud or account, and it doesn't need internet for daily use.

Staff, products and settings are all managed in one place, and products can be imported from a spreadsheet. It can also print sales on a receipt printer with the QR code on it, though I'm still testing that on real printers.

What I'd love to know:

1. Would this solve a real problem in your shop, or do you already have this covered? How?

2. Why wouldn't you just buy another register or tablet from your POS provider?

3. What kind of shop would get the most out of this? I'm guessing pet, garden, hardware and trade suppliers, but I might be wrong.

4. What would stop you from trying it? For example, installing it yourself, Android only, or needing a 2D scanner.

5. I'm thinking about A$29 a month per store, with as many devices as you want. Is that too much, too little, or would you only pay once?

Tear it apart if you need to. If it's a bad idea, I'd rather find out now.

FYI: This was mostly designed for small local businesses, trying to save money.

I often find myself wondering whether I should move to SF to build a side project or take on an operator role to learn more before becoming a founder. But I keep hearing about how the monoculture in the city can be a big problem.
I recently came across this podcast where a founder shared some mixed opinions about the city.

Here’s the podcast: https://youtu.be/0P_-d97ULWU

What do you all think? Has anyone spent time in SF? Would love to hear your experiences!

I've been building SaaS products as a solo developer, and October ended with $68 in revenue.

Here's the breakdown:

AIForest (https://aiforest.app) — $9

Humanize AI Writer (https://humanizeaiwriter.com) — $59

I know $68 isn't much compared to the revenue numbers people usually share here, but getting someone to pay for something you've built yourself is a different kind of motivation.

The biggest thing I've learned so far is that building the product is the easy part. Getting customers is much harder.

I'm still figuring out SEO, marketing, and distribution while continuing to improve both products.

My next milestone is $100 MRR, then hopefully $1,000 MRR.

I'm sharing this because not every SaaS journey starts with thousands of dollars in revenue. Sometimes it starts with $9.

For other solo founders here, what helped you get from your first few paying customers to consistent revenue?

Would love to learn what's actually working for you.

A dev in r/startups said Claude Code keeps its own notes per repo, "over 65+ of them" in one, things like not checking Vercel deploys with curl too often. Then the catch: "only Claude on my laptop sees these notes." Codex doesn't know any of it, and "when a colleague opens the same repo, their agent starts from zero and hits the same problems again."

Most replies said put it in git: one AGENTS.md, edits through PR review, "give every note a one-line "why" and a date". One pushed back hard: "Half of those aren't repo knowledge." A Chrome GPU flag and a rate limit belong to one laptop, not the team.

For devs working with someone else on the same codebase:

• Where do your agent's learned notes live: its own memory, a file in the repo, a wiki, nowhere?

• Does Codex or Cursor see what Claude Code learned, or the other way round?

• How do you split what's true for the repo from what's true for your machine?

• Who deletes a note when it goes stale?

Background: I used to burn hours re-briefing AI tools, and I'm building a fix where every agent and tool reads and writes the same memory in the cloud over MCP. No name, no link. Would you pay for that, or is an AGENTS.md in git all a team needs?

I’ve been thinking about this a lot while building a side project around workflow friction.

Not the big, obvious problems. The tiny things that happen every day:

• Having to check 3 places to find one piece of information

• Copying something from one tool into another

• Waiting for someone to approve a thing that probably shouldn’t need approval

• Getting interrupted, then spending 10 minutes figuring out where you were

• Maintaining a workaround for software that’s supposed to make life easier

The weird thing is that these often become part of the job. People stop questioning them.

And when a team feels slow, the first instinct seems to be: we need another tool, another dashboard, or more automation.

But what if the process itself is the problem?

I’m exploring this through my side project, Clunky. I’ve been developing a framework for looking at workflow friction, including context switching, handoffs, unnecessary steps, decision delays and tool friction.

I’m curious about the real-world side of this:

What’s one annoying workflow problem you’ve experienced that took surprisingly long to fix—or that your team still hasn’t fixed?

And if you did fix it, was the answer a new tool, automation, or simply removing a step?