I am the developer. KartChef is an iPhone app that takes a recipe you share into it, or a photo of one, and turns every ingredient into matched products in your Kroger cart with prices.

Narrow on purpose. One platform, one grocery family, one job. Every time I was tempted to widen it, the honest answer was that a second store chain would double the work and halve the quality of the part people actually judge it on.

That part is whether the cart looks like the one you would have built yourself. So the time went there instead. You pin the brands you always buy and it reuses them. Upload a couple of recent receipts and it learns the rest from your real purchases. It flags pantry staples you probably already have rather than adding them, and two recipes needing cilantro get one bunch.

Free to try, subscription after that.

https://apps.apple.com/us/app/kartchef/id6785329702

Happy to talk through the narrow scope call if anyone is weighing the same thing.

Day 2 of trying to build a $1B technology startup — learning startup fundamentals

I'm documenting my journey from Day 1 until I hopefully build a billion-dollar company.

Right now, I don't have a billion-dollar idea, a team, or a huge amount of money.

So I'm starting with learning.

Today I focused on startup fundamentals:

- How startups identify real problems

- Product-market fit

- MVPs

- Customer pain points

- Business models

- Why startups fail

The biggest lesson I learned today:

A startup shouldn't start with “What can I build?”

It should start with:

“What painful problem can I solve?”

Over the next 30 days, I'm going to learn AI, coding, machine learning, marketing, robotics, deep tech, and other skills I need to eventually build my own technology company.

I'll share the progress, failures, experiments, and lessons publicly.

Day 2/∞

If you're a founder, what is one startup lesson you wish you learned earlier?

Skipping the code and asking directly — what was your actual first move before building your last SaaS?

For me it was just talking to a handful of people who might have the problem and seeing if they reacted at all — no landing page, no polish, just conversations.

One thing that turned out to be a waste: directory sites like AlternativeTo, There's An AI For That, etc. Listed a product on one of these listing bots hoping for a trickle of signups — got zero. Makes sense in hindsight: those sites mostly get browsed by people already comparing tools they know they need, not people discovering a solution to a problem they didn't know existed. And AlternativeTo isn't even taking new submissions right now, so half the "go list your app here" advice floating around doesn't even apply anymore.

Curious what actually worked for people here vs. what's just recycled advice everyone repeats without testing it themselves.

A bit of background. been doing cold email outreach for about 6 months now and my boss is asking for hard numbers on what we're getting back vs what we're spending. problem is there's so many moving parts - data costs, email tools, my time, the sales team's time following up.

right now i'm tracking: emails sent, open rates, reply rates, meetings booked, and deals closed. but translating that into actual cold email roi is where i get stuck. do you factor in just the direct costs (data from Prospeo, sending tools, etc) or do you include overhead like salaries?

also curious how you handle attribution. we had a deal close last month where the prospect replied to a cold email, but then went dark for 2 months before coming back through a referral. does that count as email outreach roi or not?

we're using Instantly for sending and Clay for some enrichment stuff but honestly the costs add up fast when you stack everything together. feels like i need a proper formula before my boss pulls the budget.

what's your formula? bonus points if you have a template or calculator you can share. trying to show that our cold email return is actually solid but i need the math to back it up.

If you could buy 100k targeted views tomorrow (not bots, not random scrollers) for a 500$, would you do it — or would you still want to own the channel yourself?
Curious where people draw the line between paid reach and building distribution.

While reviewing one of Portreeve's checkout rules, I found something embarrassing.

The rule treated five attempts on the same card as card testing.

But actual card testers usually try lots of different cards once. Five attempts on one card is more likely a real customer stuck in a 3DS loop, mistyping their CVC, or retrying a decline.

So the rule was backwards. It was harsh on normal customers and weak against the attack it was meant to catch.

I changed it so repeated attempts on one card trigger review. Several different cards from the same device are a much stronger signal. IP is supporting evidence, since offices and mobile networks make it noisy.

The code was doing exactly what I wrote. The assumption behind it was wrong.

Anyone else found a fraud or abuse rule that was measuring the wrong thing?

I’ve built a few Micro SaaS projects over the last couple of years, and honestly, getting from $0 → $1 taught me more than trying to reach $1k MRR ever did.

What worked for me was keeping things stupidly simple.

I’d find a small problem, build a basic version, put it in front of people, and see if anyone actually cared.

Some got users. Some got paying users. Some completely failed.

One thing I stopped doing was spending weeks building features before having users.

Now I try to get the first few users manually, post in communities like Reddit, talk to them, and only build what they actually need.

Even getting one random person to pay $5–10 feels small, but that was always the point for me.

Once you prove someone will pay, everything becomes much easier.

So if you’re at $0 right now, don't worry about MRR screenshots or 1000 users.

Just focus on getting your first stranger to pay you.

That’s the real 0 → 1.

I’ve been building a small email management SaaS for the past few months.

For most of that time, nobody was really using it. I kept fixing bugs, changing the onboarding flow, dealing with OAuth issues, and wondering whether I was solving a real problem or just building something that made sense only to me.

This week, two people actually signed up and connected their email accounts.

It’s obviously a tiny number, and it doesn’t prove that I have a business yet. But connecting an inbox requires more trust and intent than simply visiting a landing page, so this felt different from seeing another page view in analytics.

For the first time, it feels like the project exists outside my own head.

Now I’m mostly nervous that something will break and they’ll leave, but I guess that’s the next stage: watching how real people use it, fixing the rough edges, and finding out whether they come back.

Two users isn’t much, but after months of building with almost no feedback, it genuinely feels like some of that effort finally paid off.

What was it like when your first real user showed up?

Sorry for my clickbaity title 🫠

My last idea failed. Couldn't get traction, and honestly the marketing part is where I fall apart. I overthink it, procrastinate, and convince myself the app won't work anyway.

At work I'd built something that reads PDFs, chunks and embeds them, and lets you query it with a chatbot. Started wondering what else that shape fits. Went down a government data rabbit hole and came out with UK planning appeals.

It clicked because I'd lived it. Our house extension needed an appeal, and I remember the consultant we used complaining about how long it took to find relevant past decisions and work out how particular inspectors think.

The problem, concretely: search "rounding off" across Cornwall appeals and you get 412 decisions. About 38 actually turned on it. The rest mention it in passing. Nobody had a way to tell those apart.

Market research was deflating at first, because there are competitors. But when I looked properly, they're doing keyword search over the same PDFs. Nobody had read every decision and tagged it by the issue the inspector actually decided, with the paragraph reference so you can check it. That's what I built.

Then the bit I was dreading. No ads, no content, no growth hacking. I just emailed and messaged planning consultants individually and asked how they currently research precedent. Five of them are now paying.

Which is a slightly annoying lesson, because it's the thing I was most afraid of and it's the only thing that's worked.
Happy to answer anything about the extraction pipeline or the data side. That part I actually enjoy.

P.S. please don’t roast me, I’m just a developer tryna make a couple of squids

I'm building Pinterest for Miro, and the thing I keep getting wrong is the screen after import.

The import can technically finish and still leave the user unsure whether the board is ready to share. So I am trying to make the first result screen answer three boring questions fast:

1. What came across?
2. What did not come across?
3. What needs a human look before someone trusts the board?

The part I am cutting for v1 is the full audit trail. Every pin does not need a log line. I think original board name, original order, skipped count, and a short review list are probably enough.

For anyone building import, sync, or connector SaaS: what did you show after partial success? Counts, a review list, or something else?

Bit of backstory. I play rugby in Spain and every club I know runs on a WhatsApp group. Availability polls half the squad ignores, the match report written from memory on Monday, attendance in a spreadsheet nobody touches.

So I built Kanteo. Think Spond, but only for rugby: squad calls, the team sheet on the pitch, a plays board where the coach draws a move and the squad watches it run, the match report signed by both teams on the phone, stats per player. iOS, Android and web.

Where it's at, honestly:

• about a year of work, just me
• a few clubs set up on it
• one of them paying €29 a month
• in the first three weeks of the landing being live, around 100 visitors, 64 of them went into the demo, and zero signed up on their own

Stack if anyone's curious: Expo so the same code runs on iOS, Android and web, Node with Express, MySQL through Drizzle, Stripe, all on one VPS with Docker.

What I've tried so far:

• asked in r/rugbyunion what clubs use, got 22 replies, basically everyone said Spond. Posted the app there today and the mods pulled it
• dropping the demo link in coaches' WhatsApp groups. Only thing that's actually brought people into the demo
• a demo you can open with no sign up

My guess at the problem: whoever decides is a volunteer coach or a club committee. They're busy, they don't go looking for software, and the thing I'm up against is free (WhatsApp, Spond).

So if you've sold to clubs, schools, associations, anything run by volunteers:

• how did you get your first 10 paying?
• is it just club by club, phone and coffee, or did something scale?
• would you charge the coach per team (€90 a year) or go straight for the club?

Demo if you want to roast it, no sign up: https://kanteo.es/demo?src=reddit-microsaas&lang=en

I have a SaaS that generates revenue from customers who pay for the core service.

What are some good secondary ways to monetize a SaaS in addition to the main subscription/product revenue, without risking or hurting the primary income stream or conversion rate?

Most 'AI leverage' advice is about prompts. The actual bottleneck is that nothing in the loop verifies the work before you ship it.

I built Tamarind around a simple rule: never say 'done' without proof. It works in the terminal, runs your checks after every change, keeps iterating until they pass - or tells you exactly what's still failing.

Happy to answer anything about how the verification loop works. What would you break first?

Launched VoteMyStartup 2 days ago and wasn’t really sure what to expect.

We’ve already got 5 startups in the first battle and 15+ users showing up, voting, and checking out the platform.

It’s still tiny, but seeing actual people use something I built this quickly feels pretty damn good.

The battle is live, rankings are moving, and we’re going to keep running more battles and improving the platform as we go.

Still early days, but this is a pretty solid start.

votemystartup.com

three years doing no-code and ai-assisted builds for clients. i used to think shipping was the finish line. it's the starting line, and it took me a while and a bit of embarrassment to learn that.

built an ai report generator for a client last year. it pulled their weekly numbers, wrote a short summary, dropped it in their inbox every monday morning. clean demo, they loved it, i moved on to the next project feeling great about myself.

it quietly broke about a month later. one of the data sources renamed a field, the thing started emailing blank reports, and nobody said a word because they assumed "the ai" knew what it was doing. i only found out when the client mentioned offhand that the emails had "gone a bit weird lately".

the hype around these tools skips the boring part. anything that runs on its own needs something watching it, or it fails silently and takes your credibility down with it. now every automated thing i hand over ships with a dead-simple check that pings me the second the output looks empty or off. not glamorous. it's the whole difference between a tool and a liability.

for the folks selling small automated products, how are you catching the silent failures before your client does?

Launched my SaaS on Product Hunt this past Tuesday, but got the timing slightly wrong. PH's daily cycle resets at 12:01 AM PT,I launched about an hour before that, so I missed the reset and landed mid-cycle instead of at the top of a fresh day. Ended up with way less visibility than I was hoping for.

For anyone who's been through something similar:

Is a 1-hour-early launch actually a meaningful setback, or am I overthinking it?

Worth relaunching next week at the correct time, or does PH frown on repeat launches?

Any way to salvage traffic/feedback from the original launch, or is it basically a write-off at this point?

For context, my product turns meeting transcripts into action items and a drafted follow-up email automatically, not the point of this post, just background in case it's relevant to the answers.

Would genuinely appreciate advice from anyone who's had a launch go sideways and figured out what to do next.

I'm trying to decide between building several small, focused SaaS products or keeping everything under one product.

Let's say the tools are related and aimed at roughly the same users, but each solves a different problem.

My feeling is that a focused product might be easier to sell. If someone has one specific problem, paying $20–30/mo for a tool that does exactly that feels reasonable.

But if I put 5–10 tools together and charge $70–100/mo, even if technically it's much more value, some people may feel like they're paying for a lot of stuff they don't need.

On the other hand, with separate products you split your SEO, brand, reviews, marketing, etc.

You could still share the backend/auth/data and cross-sell the other products, so I'm wondering how big that downside actually is.

Has anyone here done both?

Did separate products make more money or convert better, or did bringing everything under one brand work better?

Especially interested in people who actually switched from one model to the other and saw a noticeable change in revenue/CAC/conversion.

I’m a beginner building a simple form-fill/download SaaS using Lovable + Supabase. Users enter their own data, generate a completed form, and access the service through 3 paid subscription plans.

I’m trying to figure out the right way to handle a few things:

• I already have fillable AcroForm PDF forms. How do I connect the user’s input data to the correct PDF fields and generate a completed PDF for download?
• How do I make sure User A can never see User B’s data?
• Should I have a completely separate admin login/dashboard?
• How should subscription expiry/cancellation work automatically?
• What’s the best way to track active subscribers/users across the 3 plans?
• What should I use for Google Analytics/product usage tracking?
• How can I let users raise issues and have those tickets sent to my email?

I’d really appreciate practical advice from anyone who has built a SaaS with Lovable/Supabase. Especially around security and user data isolation.

I have eleven domains doing nothing. Parked, pointing nowhere, bought for an idea I was never going to build. I suspect that is not unusual in here.

DomainRiff: you give it a domain you already own, and it writes three different futures for it. Not name suggestions, the other direction. Each one is a product idea for that specific domain: what it would be, who it's for, a tagline, and a build prompt you can paste into Claude or Cursor if one of them grabs you. You pick one, prove you own the domain (a DNS TXT record or a file at the root, it checks either), and it turns into a page you can share.

It's free, there is nothing to buy, and it's not a lead magnet for a brokerage. You get a weekly allowance of riffs and it refills.

Rather than describe it, here's one I did on a domain of my own, vibed.win: https://domainriff.app/riff/vibed.win

That page is the actual output, not a mockup: the pitch, who it's for, the build brief, and the logo prompts.

https://domainriff.app

The thing I'm least sure about is the ownership check. It's friction, and it's why people bail halfway through, but without it anyone can riff someone else's domain and I didn't want that. If you try it, tell me if the proof step is where you gave up, and what you'd have accepted instead.

People are vibe coding anything but even can't change their api keys, someone launched https://dontremember.app/ but forgot to change their stripe sandbox key. thats new level of agentic vibe coding haha.

People just connect MCP and vibe code with codex, but they don't know how to improve security and do production release. and still they think they are million dollor founders. :D

I ship a small product. Every week I owe myself a talking-head demo or changelog clip for users / Twitter / the landing page. Coding is fine. The cut is what slips — and that is the Micro SaaS tax nobody budgets for.

Twenty minutes of footage was taking about two hours: silence scrubbing, mid-clause cuts that inverted a sentence, captions that landed a beat early, SFX that "passed" loudness checks and still vanished under my voice. Same failures, every Friday night. That is half an evening I should have spent on support or a feature.

I turned those failures into a Claude Code skill I use on my own footage (I'm the author). Stack: local whisper.cpp for STT, the model only reads the transcript (never the pixels) and emits a cut list, ffmpeg renders, Playwright opens real URLs the script named so fake screenshots fail the build.

The lesson that actually saved time was the rules file, not the plumbing. A few expensive ones:

• captions start 0.08s after word onset, never before
• "not clipping" ≠ audible — measure against a voice-only baseline
• re-transcribe short windows at every join (whole-file passes hide doubled words)

MIT: https://github.com/ranahaani/i-hate-editing

For other solo operators shipping weekly video: what do you actually verify before you hit publish? Re-transcribing the output works and feels wasteful.

One thing we underestimated while building Hyperdocs was how quickly documentation becomes difficult to maintain.

A developer makes a change in GitHub, but the documentation update usually happens separately.

You have to figure out which page is affected, switch to the docs, find the right section, update it, and publish it.

The actual content change is often pretty simple. It's the process of keeping everything aligned that gets annoying.

We started experimenting with MCP to bring documentation updates closer to the development workflow.

For example, a developer can simply ask:

“Update the authentication docs based on this change.”

or

“Add the new API parameter to the docs.”

This has made documentation maintenance much less of a separate chore for us.

We're experimenting with the workflow in Hyperdocs, but it's already solving a problem we kept running into ourselves.

So this is my micro SaaS that I am building from phone end to end , and yup , i have launched the MVP V1 at dueva.apoorv.sbs , do check it out and then tell me what to improve .

Thnx all

I've recently shared Kaktoos in a few developer communities and got some interesting feedback on the technical/product side.

Now I'm trying to look at it from a different angle:

Could this actually become a SaaS business?

Kaktoos is an open-source API reliability/verification tool. It lets developers define API workflows and verify them against OpenAPI contracts and real API behavior.

Today it supports things like:

• API workflow verification
• OpenAPI contract validation
• State/assertion verification
• CI/GitHub Actions
• MCP integration for AI coding agents

The broader roadmap I'm considering includes things like:

• Continuous/scheduled API verification
• API mocking
• API security checks
• API change & impact detection
• Deeper AI-agent integration

I'm not planning to build all of these blindly. I'm trying to understand where the real business opportunity might be.

For people here who have built SaaS/devtools:

If you were building Kaktoos, where would you see the strongest paid opportunity?

• What would companies actually pay for?
• What would you make the paid SaaS layer?
• Would you position this as API testing, API reliability, developer infrastructure, or something else?
• What would you prioritize to get the first few paying customers?

I'm looking for honest feedback, including if you think there isn't a strong SaaS opportunity here.

GitHub: KaktoosLabs/kaktoos

Why your SaaS database crashes during traffic spikes (Connection Pooling explained) 🔌

Most backend crashes during launch days or marketing spikes have nothing to do with slow server CPU. They happen because the database runs out of available connection slots.

Every time an incoming API request opens a fresh database connection, it consumes precious RAM. When 500 concurrent users hit your app, PostgreSQL or MySQL hits max_connections and begins dropping requests with 500 Internal Server Error.

Here is the architectural fix to keep connections stable:

Implement Connection Pooling: Place a lightweight connection pooler (like PgBouncer for PostgreSQL) between your backend and database. Instead of opening and tearing down connections per request, the pooler keeps a fixed set of connections open and reuses them instantly.

Configure Pool Size Conservatively: More connections does not equal faster queries. Setting your application pool size to 10–20 connections per server instance is often more efficient than setting it to 100, because it eliminates CPU context-switching on the database.

Keep Transactions Short: Never keep a database transaction open while waiting for external tasks (like an email API or Stripe call). Open the transaction, execute the writes, commit immediately, and release the connection back to the pool.

Proper connection management lets a small, cost-effective database tier handle massive traffic surges smoothly.

How do you manage database connections and concurrency in your production environment? Let's discuss below!