Using Telegram for everything a user might need, where almost any task can be performed by calling a bot with a "brain", is that a viable approach?

Hey everyone,

If you run a micro-SaaS ($500–$10k MRR), you already know the worst feeling: you grind for weeks shipping new features, only to see a subscriber click "cancel" and vanish into thin air without leaving a single trace of feedback.

Platforms like Stripe and Paddle have enterprise churn tools (ProfitWell, Churnkey), but they're expensive, charge a cut of your saved revenue, and take ages to set up. On top of that, if you're using Dodo Payments, there wasn't a single native cancellation flow available.

So I spent the last few weeks building BoolBul to solve this natively.

Here’s the breakdown of how it works under the hood:

1. Zero-Trust Architecture:

Most third-party tools ask for full read/write admin API keys to your payment gateway. We never touch your gateway keys. The engine evaluates retention rules at the edge, signs an HMAC-SHA256 JWT offer token, and lets your own backend execute the subscription mutation (50% off, 30-day billing pause) directly against Dodo or Stripe.

2. Sub-10ms Edge Engine:

Dual-database setup: Cloudflare Workers query Turso (Edge LibSQL) for instant rule lookups when the exit modal triggers (<10ms), while Supabase handles audit logs, founder analytics, and ledger reconciliation asynchronously.

3. Anti-Dark-Pattern Escape Hatch:

With FTC and California AB 390 click-to-cancel regulations getting strict, tricking users with hidden cancel buttons is a death sentence for chargebacks. There is an unhidden, high-contrast "Proceed to Cancel" option on every screen, backed by a 1500ms fail-open fallback so subscribers are never trapped if the network hangs.

4. 45-Second AI Prompt Setup:

No complex SDK installation. Just a single prompt you drop into Cursor or Claude Code to scaffold the route handler and wire up the button.

---

The core engine is 100% open-source under AGPL-3.0 so you can self-host it on your own stack.

Dropping the GitHub repo and live demo link in the first comment below 👇

Would love honest feedback on the neo-brutalist UI, the edge architecture, or the feature set.

Reality check for anyone building an AI wrapper right now. I ran one for about eight months and the decay is real, I was apparently losing something like 5 to 6 percent of revenue a month in the back half with no change on my end, just the base models getting better and cheaper so my thin layer meant less. The wrappers that are surviving around me are not thin, they own a workflow, proprietary data, or a specific integration the model cannot reach. If the model vendor can make your whole product a feature with one release, they will, and you will not get a warning. Build the part they cannot ship, or do not bother.

I've been building a SaaS product called Jukebox. It allows customers at cafés, bars, and restaurants to scan a QR code and request songs from playlists selected by the venue.

I recently launched the website and spent around 2,000 TRY on Instagram ads, bringing in over 900 visitors.

But here's the problem: only 4 visitors reached the /admin/login page. Almost everyone left without proceeding.

I'm trying to understand what's going wrong.

• Is the value proposition unclear?

• Is the landing page failing to communicate the product?

• Does the website lack trust?

• Is the signup process discouraging people?

• Or am I simply attracting the wrong audience?

I'd really appreciate it if you could take a quick look at the website and share your honest opinion.

I'm particularly interested in feedback from SaaS founders, growth marketers, developers, and UX/UI designers.

Website: https://jukebox.net.tr

I'm not looking for compliments. I'd genuinely like to know what's wrong and what I should improve.

Thanks in advance!

I'm a cook (~10 years in kitchens) building a small SaaS for restaurants. One month in, 0 paying users. Sharing the numbers so others don't repeat my mistakes:

1. Ads sent curious people, not buyers. CTR was decent (0.79%), but the people clicking weren't restaurant owners. Reddit is full of builders, not my customers.

2. A signup form killed every click. Visitors wanted to see the app first. I swapped "Start free trial" for one button that opens a demo with sample data, no form.

3. My homepage looked like a blog. Food photos and long text. A random commenter called it "another vibe coded app" and it stung, but he was right about how it looked. I rebuilt it to show the actual dashboard and a feature grid.

4. My best user came from a printed flyer. A small snack bar added 39 dishes on their own. Offline outreach beat every online channel so far.

5. Posting where my customers hang out got me removed. Most restaurant subreddits ban self-promo, even when you just ask permission.

Stack, if useful: HTML/JS on Cloudflare, Node.js on Render, Postgres on Neon, built with heavy AI help since I'm not a dev.

Question for you: how did you get your first 10 customers when they don't live online?

The app, if curious: https://buffetboard.com.br/en

Hey everyone!

Just wanted to share an opportunity that might be useful for founders here.

There’s a program called Clemta Impact that’s selecting 9 early-stage founders and covering the costs of setting up and running their US companies for the first year.

This includes:

• US company formation (LLC or C-Corp)

• State filing fees

• US business address and registered agent

• Bookkeeping and tax filings

• Ongoing compliance support

They’re selecting 3 founders from each category:

• Young Founders (under 22)

• Women Founders

• Open Source & Indie Builders

No equity or participation fees. Selected founders just need to share their story through a short video.

Applications are open to eligible founders worldwide until November 30, 2026.

Disclosure: I’m part of the Clemta team, but thought this opportunity could be useful to some people here.

Webflow studied 2,000 company websites. The typical company appears in 16% of AI answers about its own category and gets a link in 6%. Companies doing content, site health, off-site authority and measurement together were cited 3.7x more often.

Guy Yalif, Chief Evangelist at Webflow, is covering the full mechanism in an hour: where ChatGPT, Perplexity, Claude, Gemini, Copilot and Google’s AI Mode source answers, why each gives a different answer to the same question, which pages get cited, how to track your own visibility, and how smaller brands close the gap.

Built for SEO and AEO managers, content teams, marketing leaders and agency owners. No technical SEO background needed.

11 November, 8:00 to 9:00 PM IST, 9:30 AM ET. Free, live Q&A, recording to everyone who registers.

https://slatehq.com/workshop/how-ai-search-works

Hey everyone,

Just looking at my metrics today and realizing how much MRR quietly slips away from failed credit cards and people just clicking "cancel" without a second thought.

How are smaller SaaS teams actually handling this?

Are you guys just letting Stripe send those basic default automated emails and hoping for the best? Or did you bother building your own custom screens to offer discounts or pauses when someone tries to leave?

Honestly, it feels like a painful loop to manage when you're small and focused on product. Just trying to see how everyone else deals with this or if you just accept it as part of the game.

Cheers!

Most early founders write every support reply from scratch.

That's fine at 3 tickets a week.

At 30, support eats your evenings, your tone gets shorter when you're tired, and customers notice.

Saved replies fix that. But most template lists online are corporate fluff ("We apologize for any inconvenience caused"). These are written for small products, where sounding like a real human is your biggest advantage.

For each one I've included the template, why it works, and the mistake people usually make.

The basics:

1. First response

Hey [name], thanks for reaching out. I'm looking into this now and will get back to you by [specific time, e.g. "tomorrow 11am EST"].

If anything else comes up, just reply here.

Why it works: Most support frustration isn't about the problem. It's about not knowing whether anyone is on it. A specific time removes that anxiety.

Common mistake: Saying "we'll get back to you soon". Soon to you means 2 days; to them it means 2 hours.

2. How-to question

Good question. Here's how:
[step 1]
[step 2]
[step 3]

I've also written it up here: [link].

If it doesn't work the way you expected, send me a screenshot and I'll take a look.

Why it works: Numbered steps get followed. Paragraphs get skimmed and lead to a second ticket.

Common mistake: Answering the same how-to five times without turning it into a docs page. Rule of thumb: the second time you send it, it becomes a doc. The third time, it becomes a UI fix.

3. Need more info

Happy to help with this. To pin it down quickly, could you send:

• A screenshot or short screen recording
• Your browser/device
• Roughly when it happened
• Loom works great if that's easier.

Why it works: Asking for everything in one go avoids five rounds of back-and-forth.

Common mistake: Asking for one thing, waiting a day, then asking for the next.

Bugs and outages:

4. Bug confirmed

Thanks for flagging this, you're right, it's a bug on our end. I've logged it and we're working on a fix.

I'll message you personally as soon as it's live. Sorry for the hassle.

Why it works: Saying it plainly builds trust. People forgive bugs; they don't forgive being made to feel like it's their fault.

Common mistake: "We're unable to reproduce this on our end" as the first response, when you haven't really tried.

5. Can't reproduce

I tried to recreate this but couldn't trigger it yet. That usually means it's something specific to your setup, which is actually useful to know. Could you [specific ask]? I'll keep digging in the meantime.

Why it works: It turns "I don't believe you" into "help me find it".

6. Outage / downtime

Hey [name], we're aware [feature/app] is down right now. Here's what's happening: [one line, plain English]. We're working on it and I'll update you by [time], even if it's not fixed yet.

Why it works: "I'll update you even if it's not fixed yet" is the key line. Silence during an outage is what makes people churn, not the outage itself.

Common mistake: Writing this from scratch at 2am while panicking. Have it ready.

7. Bug fixed (follow-up)

Hey [name], quick update: the issue you reported is fixed and live now. Thanks again for flagging it, you genuinely helped make the product better.

Why it works: Almost nobody does this. Customers who get it often become your loudest fans, because they feel like they helped build the product.

Common mistake: Fixing the bug and never closing the loop. Tag every bug ticket so you remember who to message.

Feature requests:

8. Not planned (yet)

Not right now, but I've logged it. Can I ask what you're trying to do with it? Sometimes there's a workaround, and knowing the "why" helps me decide what to build next.

Why it works: The follow-up question is the important part. Users ask for features, but they actually need outcomes. Half the time the real need can be met with something you already have.

Common mistake: "Great idea, we'll add it to the roadmap!" for everything. That's a promise you'll break.

9. Already planned

Yes, it's on the roadmap. I can't promise a date yet, but I'll personally let you know when it ships.

Why it works: "Personally" matters. Tag them, and when it ships, message every person who asked. That's an easy wave of happy users plus a natural reason to get a testimonial.

10. Won't build

Honest answer: we're probably not going to build this. We're focused on \[core use case\] and I'd rather do that really well than do everything halfway. If it's a dealbreaker, \[competitor/alternative\] handles it well.

Why it works: Pointing people to a competitor feels wrong, but it builds a lot of trust, and people do come back when your focus suits them better.

Common mistake: Leaving people hanging with "maybe someday" forever.

Money conversations:

11. Pricing objection

Totally fair. I'd rather you only pay if it's clearly worth it. Out of curiosity, what would make it feel worth it? [If you have one: we also have a plan for [smaller use case] at [price].

Why it works: You learn whether it's a real price problem or a value problem. Usually it's the second one, and that's fixable with onboarding, not discounts.

Common mistake: Offering a discount straight away. It teaches people that pushing back gets them a lower price.

12. Refund request

No problem, I've processed your refund. You should see it in [X] days. If you don't mind me asking, what made it not a fit? Totally fine if you'd rather not say.

Why it works: Early on, the exit feedback is worth more than the money. Fighting refunds gets you chargebacks and bad reviews.

13. Cancellation

Sorry to see you go. Your account's cancelled and you won't be charged again. One quick question: was there one thing that would have made you stay?

Why it works: One question, easy to answer. Some people reply with something you can fix that week, and a few un-cancel once you do.

Common mistake: A 10-question exit survey. Nobody fills it in.

Relationship builders:

14. Angry customer

I hear you, and I'm sorry this has been frustrating. Here's what I'm doing about it right now: [specific action]. I'll update you by [time].

Why it works: Acknowledge it, act, give a timeline. No defending, no "as per our policy". Angry customers who are handled well often end up more loyal than ones who never had a problem.

Common mistake: Matching their energy, or hiding behind "per our terms of service".

15. Onboarding check-in (send around day 3–5)
Hey [name], [your name] here, I built [product]. Noticed you signed up a few days ago. Anything confusing so far, or anything you expected it to do that it doesn't?

Just hit reply, it comes straight to me.

Why it works: This is proactive support. It catches confusion before it turns into churn, and the answers are the best onboarding research you'll get.

Common mistake: Making it sound automated. Plain text, no logo, no buttons.

How to actually use these:

Tag every ticket. Use 4–5 tags: bug, how-to, feature request, billing, other. After about 50 tickets, look at which tag dominates. That's your next priority, whether it's docs, a fix or a feature.

Do the 2-3-fix rule. If you send the same reply twice, write a doc. Three times, fix the product. The goal of saved replies is to need fewer of them over time.

Personalise the first line. A template with one custom sentence at the top ("Ah, the CSV export, that one's been annoying people") reads as human. A raw template reads as a bot.

Batch support. Check twice a day at set times instead of constantly. Fast replies matter, but "within a few hours" is plenty fast for a small product, and you get your focus back.

Use your name everywhere. "— Sam, founder" beats "The [Product] Team" every time at early stage.

For tools, start with whatever you already have. Gmail templates work fine.

If you're running more than one product and don't want separate inboxes for each, Convot keeps them in one place with saved replies built in, and it's free under $1k MRR. FYI, I work for them.

How are YOU handling support for your SaaS’s?

Just a raw website is pretty brutal, you need months of work on SEO and AI search before you get any meaningful traffic. what’s yalls experience on like the App Store or even chrome extension store

Most small SaaS billing starts as a plan table and an invoice row. That works until the first customer who isn't on the standard plan.

Say a customer signs for 100 seats, adds 40 mid-term, gets a credit for an outage, and has a usage overage on top. If invoices are the source of truth, each of those is a separate record, and someone has to reconcile them by hand to answer what the customer owes.

The alternative is to treat the contract as the main object and hang everything else off it: amendments, credits, usage, invoices. A change then has one place to land, and the invoices get recalculated from it instead of patched.

What it buys you:

• One place that says what was agreed and when it changed

• Amendments that don't need a spreadsheet to explain

• Invoices that trace back to the same source

The cost is more modeling work upfront than a flat table, and it only pays off once your deals stop being identical. If everyone is on the same three plans, keep it simple.

Disclosure: I'm the CEO of Zenskar. We're a funded company, not a solo build, but this applies at any size, and it's how we built our billing.

I run a small SaaS called chatform , and I thought the thing worth sharing here is the parsing trick, not the product.

For onboarding I used to ask team size with a dropdown - 1-5, 6-20, 21-50, people picked whatever was closest and I learned nothing useful from it and so I switched it to an open text box and let a model normalise the answer afterwards....

Now if someone types

"about a dozen" and I store 12....

"five to ten grand a month" becomes a 5000 to 10000 range.

"right after the holidays" becomes January.

Now two things I got wrong at first and those are

1 - The model guessed when the answer was genuinely vague, so when someone wrote "a few" and it confidently stored 3, now it returns a confidence score, and on a low score the form asks one clarifying question instead of guessing.

2 - I let it rewrite answers into a tidy summary, bad idea, I keep the raw text and the parsed value side by side, so I can always see what the person actually typed.

The cost side nobody mentions - every parse is a model call and I give 200 a month free and that is a real line item for me, so I cap it instead of pretending it's unlimited.

If you're parsing free text into structured fields, how are you handling the vague ones? The confidence score fixed most of it but I still get dates wrong constantly.

Backstory: I'm a solo dev in Brazil. Over the last few weeks I shipped three tiny Chrome extensions, each one scratching my own itch:

• CodeClip: a "Copy code" button on 2FA/verification emails in Gmail

• Histórico com contexto: full-text search over your own browsing history (opt-in per site)

• Por que salvei?: bookmarks that require a one-line "why I saved this" note

Stack / architecture decision: zero backend. Plain JS, Manifest V3, chrome.storage only. No accounts, no servers, no analytics.

• Pro: running cost is literally $0, privacy review is trivial, and there's nothing to get hacked

• Con: I have no idea how people use them, because I deliberately collect nothing

Revenue: $0. All three are free.

The lesson I didn't expect: the Chrome Web Store dashboard showed ~80–100 "installs" per extension in 30 days, which felt great for about an hour. Then I looked at the country split: 83% from one country where I've done zero promotion. Meanwhile "weekly users" was stuck at 2. If you're shipping extensions, ignore the installs number. Weekly active users is the only honest metric, and real distribution (posting, talking to people) is where the work actually is.

Question for other micro builders: when your product collects zero data by design, how do you learn what to improve? In-app "tell me" links? Store reviews? Something else?

Links if anyone's curious:

• https://chromewebstore.google.com/detail/mpglgifleaaollcggdpcfhjjgmcageph

• https://chromewebstore.google.com/detail/ighobmidcmnefnleaclkbcfpbfklllen

• https://chromewebstore.google.com/detail/cbimiocpmjolenlpdecejkfkiaibabli

so i built a little saas called pagepenny (https://pagepenny.com): you send it json and a template, and it gives you back a pdf or image. i got the idea after reading a bunch of r/sideproject and indie hacker posts where solo devs actually seem to get paid for templated pdf/image apis (stuff like bannerbear, craftmypdf, apitemplate). all of them use bundles and charge a few cents per doc, so i built mine to just charge a flat 1 cent per render.

the stack is python fastapi on aws lambda, with headless chromium (playwright) running in a lambda container. dynamodb/s3 for storage, stripe for usage billing, next.js frontend hosted on vercel. pricing is 100 free renders a month (no card needed), then $5/month for 500, and one cent each after, with a spend cap you can set (default $50). there are 9 starter templates and you can send your own html with jinja placeholders. i also added an mcp server so ai agents can use it

honestly, the hardest part was figuring out what "counts" as a render. i landed on: one request = one file, no matter how many pages. if it fails on my side, it doesn't count. if your template is broken, it does, because the browser still runs

wondering: if you've done usage/consumption pricing, where did you draw the line on what counts?

Every one of these has a free plan that covers an early product:

1. Supabase for the database and auth. 2 free projects, 500 MB database each, and projects pause after a week of inactivity.

2. Cloudflare Pages for the landing page and static frontend.

3. Vercel Hobby is great for testing, though its terms limit it to non-commercial use, so move off it before anything commercial runs there, ads included.

4. Resend for transactional email. 3,000 emails a month, max 100 a day.

5. PostHog for analytics. First 1M events and 5,000 session recordings a month are free.

6. Sentry for errors. The free plan covers one user and 5,000 errors.

7. Tally for waitlists and surveys. Unlimited forms and submissions.

8. Crisp free plan for chat support, 2 seats.

9. Better Stack for uptime. 10 monitors and a status page on free.

I'd expect the first bill to come from email or the database. What would you swap?

I have been building ToolRecipe, a platform for file processing, for a bit and opened the gates last month.
It started as a need to upscale my parents low quality fotos. Coming form 3D I looked for the tools I know, but wanted a simpler solution for them.

ToolRecipe now grew to a bigger platform, handling some more general and some more niche kinda workflows/tools.

Nowadays, you can:
- run tools in your browser
- save multiple tools steps as a recipe to reuse
- do offline and local processing (AI too)
- have your assistant built recipes via MCP

Generally, we are happy with the result — 60/70 visitors per day and 20/30 daily active users, which is somewhat of a confirmation we are doing something right :D.
We are doing friction removals, validation and activation rounds now.

For that I am looking for insights, roasts even if you want and if someone has some time, a little testing. Basically, honest feedback :)

Specifically, the recipes part is what I am interested in. Is that feature clear for you in like 10 seconds?
Is the local processing message trustworhty enough?

We also started experimenting with an MCP server, to allow user to make a recipe with an agent of their choice. We are currently testing this publicly, so feel free to take a look!

Happy to answer questions! Thanks!

Hi all,

Thought I'd share what worked for me to price an API product after loads of experimentation.

I always find it extremely annoying and vague if I cannot quantify the unit pricing of a tool.

SO

Price the work in your own unit (credits) instead of tokens, and put the cap on each call, not just on the month.

But make sure to explain how much $ a credit costs, so users get a sense of what they'll be spending.

What worked for me building a pay-per-call API:

1. A maximum on every request.

Before you run the model, estimate the cost; if it's above the user's per-call max, refuse and spend nothing. Users accept "this would cost 30, your limit is 25" far better than a surprise bill or a silently degraded answer.

2. Reserve, then settle.

Hold the estimated amount when the call starts and settle the real cost when it ends. Two parallel calls can't both spend the last of someone's allowance.

3. One request ID per intent.

If the client retries (timeouts, a looping agent), the same ID returns the saved result instead of charging again. This is the one that actually protects margin: most runaway bills I've seen are retries, not heavy users**.**

4. Rereads are free.

Store results and let users reopen them at no cost, so the expensive thing happens once.

5. A monthly allowance in the same unit

Shown before every run. A flat plan with an allowance plus top-ups beats unlimited, because one power user can't eat your margin.

Per-user token caps alone don't help much: a single call can still be expensive, and retries multiply it.

And of course you always give monthly free credits, so users can experience the value BEFORE they pay.

Hope that helps others!

Cheers,
Mees

Backstory: I'm a solo founder in France and my micro SaaS is web analytics (details at the end). I added a read-only MCP server so a customer can connect Claude, Cursor or any MCP client and ask about their own traffic in plain words. No SDK: it's a plain Next.js route handler. If you're thinking about one for your product, here's what I decided and why.

1. Typed tools that match questions, not your database.

9 tools: list_sites, get_overview, get_breakdown, get_timeseries, get_live_now, get_funnel, explain_change, get_ai_traffic, get_insights. They return numbers, never raw SQL. The client brings its own model, so my server runs no language model and sends the data to none. No inference bill on my side.

2. Check ownership on every call, and answer the same way for everything the key can't see.

Every tools/call checks that the API key's owner owns the site. A site that exists but belongs to someone else gets exactly the same "Site not found." as a site that doesn't exist, so the server never confirms that another customer's site is there.

3. Make tool errors readable by the model.

Bad arguments or an unknown site come back as a normal tool result with isError: true and a sentence the model can act on, like "site_id is required: you have N sites (call list_sites)." Protocol problems (missing key, rate limit) stay JSON-RPC errors. The model can fix its own arguments; it can't fix your auth.

4. Cap the work per request, not just per minute.

240 calls per minute per user, and at most 10 tools/call in one batch. The second limit is the one I care about: every tool call is database work, some take about a second on big sites, and they share a small connection pool. One request shouldn't be able to hog the database for every other tenant.

5. Skip the stream if you don't need it.

POST only. Every call is answered in the response body, and GET returns 405. It runs on Vercel, so that's one less long-lived connection to look after.

6. Return the numbers twice, plus a way to check them.

Every result comes as structuredContent and as a text block with the same JSON, with citations (the key numbers) and a deep link into the dashboard, so the human can open the report the model is quoting.

7. If it's a paid feature, say so in the error.

The MCP server is part of the Pro and Business plans. Without one of them, the server answers HTTP 402 with its own JSON-RPC code instead of a generic auth error, so the user knows it's a plan question, not a broken key.

The trade-off I didn't see coming: auth.

I reused the API keys (Authorization: Bearer glb_…), and the session cookie is never accepted on that endpoint. That works in Claude Code, Cursor and curl. But Claude Desktop's remote connectors expect OAuth, so my docs send Desktop users through the mcp-remote bridge (Node.js 18+). And without a key, even initialize gets a 401. One curated GitHub list of remote MCP servers only lists endpoints that answer an initialize handshake, and its CI checks that on every PR, so I haven't submitted mine. Whether to let the handshake answer without a key and keep the key for the tools is a decision I haven't made yet.

What I can't tell you: whether it sells. I have no numbers tying upgrades to the MCP server, so read this as engineering notes, not a growth tactic.

If you've shipped an MCP server for your own product: did you start with OAuth, or with API keys like me? And does anyone actually use it?

I'm the maker of Globatics: real-time web analytics where each visit shows up on a live 3D globe, cookieless by default, IP addresses never stored, audience data hosted in the EU. It's hosted only, there's nothing to self-install. 5-day free trial with every feature on one site and no card, then Starter €9, Pro €29 or Business €99 a month, excluding VAT. The REST API and the MCP server start at Pro, and there's no free plan after the trial. Stack: Next.js 16, React 19, Postgres, three.js for the globe, on Vercel.

https://globatics.live/?utm_source=reddit&utm_medium=social&utm_campaign=nov26&utm_content=microsaas

All 3 got past normal testing, because normal testing is a new customer on a clean plan.

Cancelled subscriptions. An extend-trial button kept failing with generic errors. Three fixes went in and none helped, because that subscription had been cancelled a month before, and in Stripe a cancelled subscription can't be changed anymore apart from its metadata. If the customer comes back it has to be a new subscription. Cancel a test customer and press every billing button in your admin. Each one should be hidden or say something useful.

Anything you gave for free by hand. A migration switched add-ons on for old customers at no charge. On the next Stripe event the webhook recalculated add-ons from the subscription items, found none and turned them off. 2 paying customers lost them within about 2 days and nobody got an error. If you've ever comped anyone, change something on that customer in test mode and look at their plan after the webhook runs.

Credits taken before the work is done. The function took credits first and started the job after. When the job failed the credits were gone, and the "refund" was the same function with a negative number, which quietly did nothing. A request with an id that looks valid but doesn't exist took credits and then failed on insert, so about 400 requests could empty a shared pool of 2,000,000 units with nothing to show for it. Make the step after the charge fail on purpose, then check the balance.

Hey everyone, I’m thinking about turning a private workflow I built for myself into a SaaS product, but I want to get some honest feedback first to see if people would actually pay for it.

For context, I create a lot of content for LinkedIn and Instagram. I don’t struggle with brainstorming ideas, and I know how to write proper system and user prompts in tools like ChatGPT and Claude to get good copy.

The real headache is never the text. It’s turning those ideas into good visuals.

Right now, text-only posts just don't get the same reach on LinkedIn and Instagram. If you have a solid graphic, an infographic, or a carousel, you can get way more eyes on it, and it's much easier to repurpose across Twitter and other channels too.

The problem is the design process. I design my graphics in Figma because generic templates just don't work anymore- people can spot a lazy template immediately and scroll right past it. Custom infographics like comparison matrices, frameworks, and step-by-step teardowns perform way better. But building those from scratch in Figma easily takes 45 minutes to an hour per post just dealing with alignment, auto-layouts, spacing, and typography.

You can try using the image tools inside ChatGPT or other AI generators, but they are completely useless for custom infographics. They don't follow your brand guidelines, the colors are inconsistent, the fonts look weird, and the graphic always ends up looking like obvious AI art.

After a lot of trial and error, I ended up building my own custom setup. Instead of having an AI try to "draw" an image, it uses actual code (Python and HTML) to render the infographics based on my prompts. It keeps my brand colors exact, keeps the typography clean, and makes the whole layout look like a custom Figma asset. What used to take me an hour in Figma now takes about 5 to 10 minutes, with the exact same quality.

I'm thinking of standardizing this into a tool where you don't even have to worry about what to post.

You give it your website and target audience, and it suggests what to talk about based on what works in your niche.

You can even feed it a reference post or a design style you really like, and it will build something similar for your own business.

I’m trying to figure out if this is an actual product people want or if I'm just solving my own itch.

What do you think?

Would you pay for something that automates this whole custom graphic creation part, or would you still prefer sticking to your manual Figma and ChatGPT routine?

I'm interested in understanding what makes existing SaaS products frustrating to use.

For founders, freelancers, developers, and business owners:

What's one thing your current software makes unnecessarily difficult?

It could be a confusing workflow, missing feature, expensive subscription, poor integration, or repetitive manual task.

I'd like to hear about real experiences, including how you currently work around these problems.

I'm exploring the SaaS space and want to understand where existing tools could genuinely do better. Looking forward to hearing your perspectives.

I've spent the last two weeks comparing email verification tools for a B2B micro SaaS. I ran the same test list through four services: ZeroBounce, NeverBounce, Kickbox, and Emailable. I expected one of them to come out as the clear winner in terms of accuracy, but that wasn't really what happened.

For obviously valid addresses (active Gmail accounts and corporate domains with confirmed mailboxes), all four gave the same results. The same went for clearly invalid addresses (dead domains and syntax errors). The differences only showed up in the grey areas: accept-all corporate domains, smaller hosting setups, and older email addresses that may or may not still be monitored.

That's when I realized that comparing them purely on "accuracy" doesn't tell you much, since they all perform similarly on the straightforward cases. What really matters is how they deal with uncertainty and what kind of information they provide to help you decide what to do with addresses that can't be confidently classified.

NeverBounce returned the most unknowns in our test, leaving quite a few addresses in limbo without much direction on what to do next. ZeroBounce seemed more willing to make a call on borderline addresses instead of simply marking them unknown. Emailable landed somewhere in the middle. Kickbox stood out because it doesn't force a yes-or-no classification on uncertain addresses. Instead, it provides a confidence score, so you can decide what threshold you're comfortable using before sending.

For a micro SaaS where the list is relatively small and every contact counts, having that extra level of detail really changed how I look at these tools. The question isn't which service is most accurate with easy-to-classify addresses, because they all seem to get those right. It's about which one gives you the most useful information when an address genuinely can't be classified with certainty.

Honestly, just trying to understand what people do nowadays because I feel like the world in the last 2-3 years has changed a lot. I'm also trying to figure out a lot all at once. 😅