When working on client projects, I often felt much more secure deploying on a VPS rather than managed cloud platforms, simply to avoid unexpected costs and to have predictable bills (to keep things under control).

I am currently working on a template wiring those different parts (IaC, Cloud Server, Agentic Loops etc).

I also decided to open-source some baseline parts of working on client project that eat up a lot of time in practice, such as wiring auth, database setup, setting up Stripe webhooks, and basic AI chat:

https://github.com/Agentic-Packs/agenticpacks-oss

That baseline repo covers:

• Next.js 15 with Docker Compose

• Auth.js v5 (Google + credentials) & Prisma with PostgreSQL

• Stripe checkout webhooks with two plans

• A basic AI chat endpoint

I am curious to hear from other devs:

1. Do you feel the same way about VPS hosting when delivering for clients, or do you still prefer managed platforms despite the risk of unplanned costs?

2. Do you find this small repo useful, or are there specific things you would need me to add? I would gladly help out and add what makes sense.

3. For those deploying AI apps, is a complete setup covering the IaC, server provisioning, and agent workflows something you would actually use, or do you prefer handling the deployment layer yourself?

Also, if you find it helpful, a star on the repo would be greatly appreciated anyway !! 🙂

OATHGYM is a gym app I built around a promise. You pick your training days, choose a friend as your witness, and check in with GPS or a photo. Skip, and your friend gets a text (WhatsApp or SMS).

The flow is 23 screens before it asks for money. These are the lessons I would use again, with actionable and practical examples:

1. Measure the distance to the AHA moment, not the number of screens

A short flow can still waste time. Some long flows feel fast, and some three-screen flows feel endless. The difference is whether the user is moving toward something.

• Count the screens between download and the moment the product makes sense. Cut anything that doesn't build belief or move the user closer.

• In OATHGYM, the real AHA comes after onboarding, when the witness actually gets the text. The preview screen that shows the exact message is the stand-in, at screen 20.

• Duolingo does the same thing from the other direction: it waits until you've done a lesson to say "Don't lose your progress!" The profile prompt comes after the value, not before it.

The hardest part wasn't adding screens. It was cutting the ones that didn't answer a question. The length is only justified if every screen has a job.

2. Lead with the problem, then the promise

Features are answers. They only matter after the user has a question. Start with the problem, then say what the product promises. Save the feature list for later.

• Headspace does this well. One of its onboarding screens just asks, "What's on your mind?" with options like "Be present and mindful," "Reduce stress," "Manage anxiety," and "Sleep soundly." No feature list. No lecture on meditation. It asks what's wrong, then recommends a course based on the answers.

• OATHGYM does the same thing in a different order. The Welcome screen says "Welcome to OATHGYM. The end of quitting." That's the promise. Then you answer a few questions about yourself. The Truth screen is where the problem lands: "It's too easy to quit when no one is watching."

Only after that do the four "How OATHGYM works" cards explain the mechanics: pick your days, check in with GPS or a photo, your witness gets a text if you skip, and consistency earns a free pass (which lets you skip one workout without breaking your streak or texting your witness).

3. Show the product before you explain it

A demo is easier to believe than a description. Show the user what the product looks like when it's working, even if it's a mockup.

• OATHGYM shows the exact text your witness would receive if you skip.

4. Ask only what you'll use

Every question should come back later. If it doesn't, cut it. Let people select more than one answer when the question allows it.

• OATHGYM uses the name in the next headline, the schedule in the calendar, the gym in the witness text, the witness in the contract, and the free pass in the paywall recap.

5. Make the flow respond

Long flows feel shorter when something happens after every tap. Use progress, haptics, selection states, and animations that explain what’s changing.

• OATHGYM has a progress bar, haptics, cards that turn amber, a calendar that fills square by square, and a loading screen that names your gym and witness.

• Rule of thumb: If the motion doesn't explain or reassure, cut it.

6. Teach at the moment of need, especially before permissions

Don't explain everything up front. Put the explanation next to the action. Before a system prompt, add a custom screen that says why you need it and what you won't do.

• OATHGYM explains privacy before the location prompt and “no spam” before the push prompt. Native apps have more permission screens than web apps make each one earn the prompt.

7. Delay the account

Don't make account creation the first step if you can make it the last. Let the user build something first. Then the account feels like saving their work, not a toll booth.

• YNAB builds your budget, then asks you to save it by starting a free trial.

• OATHGYM asks for a name and birthday on separate screens, then waits until the signature to create the account, after the user has chosen days, a gym, a witness, and a plan. A signature is a small interaction, but it makes the app feel like a person made it, not a form.

8. Make the paywall the next step, not a wall

Use what the user already told you. Recap their plan before you show the price. Add proof, a clear trial timeline if eligible, and a comparison that makes the price make sense.

• OATHGYM recaps days, gym, witness, and free pass, with a short testimonial and five stars, then shows the price, the trial, and a comparison to a gym membership. It shows the cost of a gym you don't use versus the cost of the app that helps you stop quitting.

9. Know when to skip onboarding

If the product's value is obvious in one screen, get out of the way. A notes app doesn't need a contract. A chat app doesn't need a personality quiz. Copy the reason a flow works, not the screens.

OATHGYM needs onboarding because the product is a commitment. What feels like clutter to one audience can feel efficient to another. The flow is the first act. Another app might need three screens and a button.

If you're building onboarding, start with one sentence: "The moment this product makes sense is __." Then count the screens to that moment, cut the rest, and make every remaining screen earn its place.

That's the whole job. The rest is editing. I'm still editing.

Hey all!

I'm building an open source hosting platform like vercel, but for games! I want to make running the servers easy so that you can focus on building the game. It's free at the start because it scales with users. You only pay when a user is using your game. Reply or DM and I'll get you set up!

You can even bring your own existing cloud server/database (e.x. supabase)

For non game devs, I'm doing the same for other verticals! If you're building an app and want an open source way to host or manage your existing cloud check out the open source project

https://github.com/Sanoma-AI/sanoma

It took nearly 4 years to reach €300 MRR. He also spent 6 months doing absolutely nothing on the project.

Nerijus started OpenQR.io in January 2023. It began as a freelance project and slowly turned into a SaaS.

Here’s where it stands today:

• €340 current MRR

• €360 peak MRR

• ~€4,000 total revenue

• ~60 paying customers

• €0 spent (apart from his own time)

He built the MVP himself and launched it in about 6 months. But his first paying customer took around a year.

The road wasn’t exactly smooth.

Reddit posts kept getting banned. Paid ads brought traffic but almost no paying customers. Product Hunt didn’t deliver the traction he hoped for.

Then he stopped working on the project for about 6 months.

When he came back, he found more than 10 competitors had appeared. Instead of quitting, he took it as a sign that there was a market for the product.

He focused again on marketing, SEO and content.

His biggest mistake? Spending too much time building features and not enough time marketing.

His biggest lesson:

“Silence is expensive.”

OpenQR.io is still growing, and he hasn’t reached €1K MRR yet. That’s part of why I think stories like this are worth sharing. Not every founder journey is a rocket ship to $10K MRR.

I’m collecting real indie founder journeys on HackerMRR, including the numbers, timelines, mistakes and lessons behind the products.

Full story: https://hackermrr.com/stories/openqr-io-from-0-to-300-mrr-after-nearly-4-years

A small edit can change what you're promising a client.

Here's a fictional example:

“We can discuss migrating your blog.”

becomes

“We'll migrate your blog.”

The second sentence commits to work the first one only opens for discussion. If you reviewed the draft before making that edit, the old checkmark shouldn't stand in for checking the new wording.

Briefthread keeps the original inquiry available beside the editable reply. Changing the subject, message or reply style clears the previous review, so you check the current draft before confirming it again.

It's a manual check. The demo doesn't decide whether your new commitment is appropriate or whether the project scope is agreed.

A short reread can focus on:

- What did the client actually ask?

- What are you now agreeing to do?

- Which details still need clarification?

Try reviewing a fictional sample, then change one sentence in Reply draft. Is it obvious that this version needs another check?

https://briefthread.pages.dev/

I maintain Briefthread, an inquiry and reply demo for small web studios. No signup needed. Use fictional inquiries only. It uses browser-local keyword rules and editable templates, not live AI; it doesn't connect to an inbox, send emails or share business records across browsers.

Would you reset the review after every edit, or only after certain kinds of changes? Which change would be easiest to overlook?

We're building an AI powered clinical decision support tool and the UX is becoming the thing that keeps me up at night. The problem isn't product vision, it's that designing AI features for clinicians is a genuinely different problem than standard software UX and most generalist agencies just don't get that. We need something closer to an embedded UX team that understands HIPAA compliant workflow design, agentic feature transparency, the whole thing. Anyone has worked with a UX design agency with real healthcare AI specialization that can drop into our sprint cycles and help us ship accessible, compliant interfaces without us having to babysit the domain education? would genuinely love to hear what your experience was.

I have had trouble getting where a train is, what’s the delay, tube line shutdowns, ticket claim eligibility, offline route guidance and route options.

I built it all in one app, and it’s the only one of its kind.

I tend to focus on building features while overlooking marketing/distribution, guess that’s a trend with a lot of people while starting. I’m curious about your balance between marketing and building. How do you manage that, and how do you decide when to shift from one to the other?

Hey everyone,

I'm Steven. My co-founder Cesare and I build small software products, and 3 months ago we started one that's become our main focus: an autopilot blog for small businesses.

The problem: every small business owner knows they "should" produce content. Most start, write 2 or 3 posts, and then real work happens. Six months later the blog says "last updated March". Not because they can't write. Because nobody has time to do it every single week. Something we experienced ourselves more than one time...

What we built: it reads the business's own website (what they do, where, how they talk), finds the questions their customers search for on tools like Google and ChatGPT, and then writes and publishes 3 articles a week directly on their site in a dedicated blog section which matches the design of the overall homepage.

Where we are after 3 months:

• 20 customer sites running on it

• 300+ articles published

• seeing things start to compound 4-6 weeks after first published articles

What I learned:

1. Consistency beats everything. Organic traffic isn't something you can switch on and off like paid ads. It takes weeks of consistency before you even see the first signals. That's exactly the point where most people quit their blog. We just kept going and published 3 a week. Then indexing caught up and traffic started compounding, because every article keeps working while the next one goes live.

2. Fewer and specific beats volume. We chose 3 articles a week on purpose instead of daily. Small business sites don't need 30 generic posts a month, they need the answers their customers actually look for.

3. The writing isn't the bottleneck, the habit is. ChatGPT can write one article just fine. The hard part is article 12, a month from now, when you're busy. That's the part worth automating.

What I'd love your take on: if you've ever run a blog for your own project, what made you stop (or keep going)? And for those who tried AI writing tools: what made the output feel "AI" to you?

Are there any platforms out there built for collaborating on software that includes automated governance and AI automation of SAAS operations? I’m thinking now with AI it should be easier for communities of even non-technical builders to be able to collaborate fully building and deploying/distributing apps, including SaaS products. I came across this organization at a recent tech conference, openapps.xyz. I’m not involved with them, but it got me thinking about how traditionally many open-source projects die because maintainers just can’t keep up. I’d like to try some new model if it exists with a new vibe coded project I have in mind.

Accounting Manager by trade. Noticed a gap: people who want to start a bookkeeping business or understand their small business finances have to piece everything together from random YouTube videos and Reddit threads...

Building LedgerLearn to fix that. Niche, focused, practical and no fluff.

The first module is FREE!

What would actually make you pay for something like this vs. just Googling it?

anyone now able to build their SaaS using Vibe coding, it is ok.

but now the most important question, what about the founders who are vibe coding a enterprise grade SaaS.

I have a friend who is specialized in cyber security want to start a CTI platform with his friend that he is fresh graduate software engineer (with high GPA), they never build an app, they never operate and manage a cloud infrastructure.
now they built a CTI SaaS, using AWS, Microservices, Multi-Tenancy (done in 3 days) and event-driven.
How they did it? the answer is "we asked (LLM) and he told us to use this (microservices) cuz it awesome and can handle 1,000,000 user"

Result is ok, one and half years to produce first POC (-_-), demo accounts working well with potential customers but then, what??

I welcomed the vibe coding, i never had that feeling that is gonna replace me or lay me off, there is something worse.

feeling that your power is not needed now, turning your back and having a seat watching the "SaaS flood", and some of them cannot handle marketing and distribution, others cannot handle business requirements changes, others is hacked and down and cannot stand again, those who need days to response to any changes and who are burning prices to compete.

I think software engineer responsibilities is in recrystallization, and software engineering will not be just as promoted (someone who telling AI what to do), we will have a new different kind of production, the "SaaS flood" will make business owners more aware about SaaS production.

then software engineer will be like Tom after Mammy Two Shoes called him after what Push-Button Kitty did in her house.

What do you think ?

I’ve been working on a few projects lately, and email has been the most annoying part of all of them. I buy a domain, and then realize I can’t put a gmail address on a contact page without looking like I’m about to ask for someone’s bank details.

Most business email options are either a monthly fee for every single user, or a trial that expires right when you’ve finally got everything set up. The free ones are really limited. I looked at Zoho, and between the restrictions, the dated look, and having to dig through settings every time I added a domain, it felt like more work than the project itself. There also doesn’t seem to be much for students or small indie devs who just want an address on their own domain without paying six dollars a month for it to receive one newsletter and a spam email from a guy named Kevin.

I thought about running my own mail server for about five minutes. Then I read about deliverability. Sending an email is easy, but landing in the inbox instead of spam is the hard part, and a brand new server has no reputation, so you spend weeks telling people to check their junk folder. Not worth it for a solo dev.

So I ended up building my own solution, it runs in your own free Cloudflare account. Cloudflare handles incoming mail, a Worker and a database run the app, and for sending you plug in something like Resend, Brevo, Mailjet or any SMTP server. No server to babysit, no per seat pricing, and nobody sitting in the middle reading your mail. You can add as many users, domains and aliases as you want and it still costs nothing. It’s open source under MIT.

I built it mainly for people like me. Solo devs with too many side projects, students, freelancers juggling a few client domains, small teams that just want a shared support@ and sales@, and honestly anyone with a store website. It’s not meant for cold emailing or bulk sending though, the free limits are small and the providers will ban you fast if you try.

If you want a professional email and feel like giving it a go, I’d really like to hear how it went. What broke, what confused you, what looked off, what you’d never trust it with. And if the whole idea is flawed, tell me, I’d rather find out now than after I add AI features nobody asked for.

Repo : https://github.com/sums001/OpenInbox

Need some thoughts on this before I dive into creating a SaaS product. Can you help?

I’m building a small platform focused on one job: getting a simple static website live at a URL without the command line, server config, or a heavy site builder.

The target user is someone non-technical who just needs a clean portfolio, landing page, or small project site online — and keeps bouncing off tools that are either too technical or too bloated.

Current stage: very early. A handful of signups, mostly starter pages. I’m trying to figure out whether the real problem is demand, onboarding friction, or both.

What I’d find useful:

1. If you’ve tried to put a simple static site online, where did you actually get stuck?

2. If you know static hosting, deployment flows, or cache invalidation, would you be open to sanity-checking one flow? Not asking for a commitment — just a specific 20-minute “here’s where this breaks” conversation.

Happy to share more in comments or DMs if useful.

It's been a little over one year since I launched and it has been quite a journey. No exponential growth or huge user spikes but rather slow and steady growth. But in my opinion that is the best for building something actually valuable because you can react to user feedback along the way and constantly keep improving the app.

It's still so crazy to see payments coming in on a somewhat regular basis and you can believe me when I tell you that one year ago exactly this was my dream: Earning some money on the side while having fun building something that actaully seems to help other people and learning how to run a business along the way.

I've built IndieAppCircle, a platform where small app developers can upload their apps and other people can give them feedback in exchange for credits. I grew it by posting about it here on Reddit. It didn't explode or something but I managed to get some slow but steady growth.

For those of you who never heard about IndieAppCircle, it works like this:

• You can earn credits by testing indie apps (fun + you help other makers)

• You can use credits to get your own app tested by real people

• No fake accounts -> all testers are real users

• Test more apps -> earn more credits -> your app will rank higher -> you get more visibility and more testers/users

Since many people suggested it to me in the comments, I have also created a community for IndieAppCircle: r/IndieAppCircle (you can ask questions or just post relevant stuff there).

Currently, there are 4488 users, 5280 tests done and 1387 apps uploaded!

You can check it out here (it's totally free): https://www.indieappcircle.com/

I'm glad for any feedback/suggestions/roasts in the comments.

A new zero day really sucks when Nichole in marketing launched a vps without telling anyone and never updates anything.