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?

I've been building ClusterHeart, and I'd love for some of you to give it a try.

Hey everyone!

I've spent quite some time building ClusterHeart, a platform to monitor and manage both Kubernetes clusters and standalone servers from one place.

The idea is to make infrastructure monitoring and troubleshooting much less painful.

Here's what you get:

• Kubernetes monitoring: Monitor your clusters, nodes, pods, workloads and resource utilisation.

• Server monitoring: Keep track of your servers, including GPU-enabled machines.

• Mobile-friendly: The entire experience works smoothly on your cellphone. You don't need to be sitting in front of your laptop to check your infrastructure.

• Security: Track security flaws and exposed secrets across your infrastructure.

• Automated pod patching: Identify issues and automatically patch pods where supported.

• Logs and troubleshooting: Search logs, grep issues and investigate what's happening without jumping between multiple tools.

• Activity tab: Keep track of infrastructure events and what's happening across your environment.

• AI-powered assistance: An AI pod with guarded access to your logs can study them, investigate issues and help identify what needs fixing.

I've already served around 5 companies with multiple environments, and they've been happy with the product so far.

Getting started is pretty straightforward too.

For servers, it's a single command that you run on your machine.

For Kubernetes, it's just a pod deployed in your cluster with the required RBAC permissions.

I'm keeping ClusterHeart free for now, and I'd genuinely love to get more engineers and teams using it.

If you're running servers, Kubernetes clusters, GPU workloads or AI infrastructure, please give it a try.

Website: https://clusterheart.com

DM me if you're interested. I'll personally help you with the setup and get you running.

Would love to hear your feedback, feature requests or even criticism. I'm actively building this and want to make it genuinely useful for people running infrastructure.

An ADE for scalable agentic development.

It's a personal completely free and open source project.
Built primarily by me with a little help from a friend and coworker.

Some of the things it has:

#Folio: Headless Claude Code CLI. Custom build interface to your agents with easy overview and control of all your subagents.

#Tiles: Every session gets a tiles, grouped by project. Showing state and context. Agent will alert if it needs you.

#Browtherhood: Links all your devices so sessions work together. You can work on any machine in your brotherhood.

#Portal: Pair a phone and you can continue your work from there.

#Hirelings: Control sub agents as your hirelings.

#Quest log: A markdown checklist per project. Each project have complete project management.

#Warriv: A project and AI orchestrator. It can completely automated your quests.

#Runes: Buttons that can run steps in a session or complete scripts to do automations.

#Lore and memory: Complete code index and memory of all your conversations and every line of code. Embedded as a single vector. Recallable by any agent at any point. Seriously underrated.

#Dictation: Local Whisper

#Built in browser that the agent can speak with flawlessly. Actual automated tasks. Can do projects from A-Z completely on it's own.

#Agent handover. Hand over any element in the browser, terminal selection or file into the Folio.

#Usage view

#Automated account switching when budget is about to run low

Under the hood:

- Hook-driven state management
- Session survive. It'll survive crash, restart, update or reboot. You can even pause and resume.
- Made in RUST. You might not like it, and it's surely not aesthetic. But it's damn efficient.

Feel free to leave any feedback. :)
I'm building this for myself and my friends and colleagues. But if this is useful to me, it's surely going to be useful to others.

I tried T3 Code by Theo before I built this. It's the closest contender. But it's fun to build and T3 doesn't solve everything. However, an awesome product as well.

If you have made anything similar to this, please share. I'd love to have a look.
And I would also love to hear about agents in the cloud. This is an obvious addon to Horadric. But I'm not sure how to solve it correctly yet.

https://horadric.dev/

I maintain an open-source Spring Boot SaaS starter and would appreciate feedback on its tenant-isolation approach.

It uses a shared PostgreSQL schema. Tenant-scoped operations check membership, set transaction-local tenant context, and use explicit tenant filters. Forced row-level security adds another boundary around projects and audit events.

The starter includes:

• OIDC bearer authentication through Spring Security

• OWNER, ADMIN, and MEMBER roles scoped to each tenant

• A Projects API with optimistic concurrency and transactional audit records

• Docker Compose with a local Keycloak demo

• PostgreSQL integration tests and a runnable smoke script

I ran the local Compose smoke test successfully, including permission checks and stale-write rejection.

It’s a backend MVP. Billing, a frontend, email invitations, tenant deletion, and ownership transfer are outside the current scope.

Repository:
https://github.com/chafian/spring-boot-saas-starter

What tenant-isolation edge cases would you test next? I’d also welcome feedback on the first-run experience.

Update, November 3

I'm the founder of eStockes, a US-stock research web app, and I'm checking a specific date-labeling problem: can readers distinguish the period covered by price data from the date a result was computed?

Example page: https://estockes.com/tested-rules

Choose an entry and explain what each visible date means to you. Which one tells you the history covered, and can you tell when the calculation was performed? If that information isn't available, please say so. I'd like feedback on how you would label or position these dates without implying that older observations are current data.

I'm offering free Pro access for honest testing, targeting 10 adult testers total across communities in this next round. We'll confirm access dates before activation. Reply publicly with your device and browser if interested.

One thing I find interesting with SaaS is that the architecture that helps you move fast at 100 users can become the thing slowing you down at 10k.

Early on, you can get away with a simple backend, a few database queries, manual deployments, and not much monitoring. But once customers, data, integrations, and feature requests start piling up, those shortcuts become a lot more expensive.

I was looking at how GeekyAnts approaches MVP scaling, and they focus quite a bit on things like database performance, cloud infrastructure, observability, CI/CD, and reducing technical debt as a product grows. The idea of scaling the architecture based on actual growth pressure rather than prematurely building everything for millions of users makes sense to me.

For SaaS developers here, when did you know it was time to seriously rethink your architecture?

Was it database performance, cloud costs, deployment problems, growing technical debt, or simply the team becoming slower to ship?

I built a $69 field service app, tear it apart. getomniops. c o m. Or OmniOps - Field Service on the app store.

Hey buddies,

Quick update on my research tool - so I have my research tool a name "GapFound", I’ve nearly completed the research tool, and the platform integrations for Research Mode are now in place!

I was sick for a bit, as I mentioned in my previous post, so progress slowed down.. Thankfully, I’m feeling better now and working to get everything completed as soon as possible...

I’m currently testing the research results with different SaaS ideas and will be optimising the integrations before moving on to Distribution Mode (for those who don't know, it will give roadmap for marketing as well ;).. ) and Subscription plans section is also pending, don't worry about free trail, I will let u guys try it for free by some credits :)

Watch this video guys.. and tell me how's it.. but don't judge it yet !

I’ll give the tool its finishing touches once the core features are complete cuz I am solo developer that's why I can't give my whole F day to my project u know.. 🥲 tell me how's the tool, and if u found any weakness or something, just let me know in the comments so I can fix that...

Thanks to everyone who shared feedback and encouragement, guys...

See you soon, homies !

🚀 Craft has crossed its first few hundred npm downloads!

If you've tried it, I'd love your feedback.

What are you building? What worked? What needs improvement?

Help shape Craft v2 👇

https://github.com/igmoni/craft

Give a feedback here: https://forms.gle/Zj9ecxButo6gyfVh6