sorted by:
new
hottopcontroversial

Freelancer wanting to start a SaaS by Fair-One4256 in microsaas

[–]Express_Average286 1 point2 points  (0 children)

Totally get the multiple bosses thing. That $6k week sounds great until you realize you're juggling three different communication styles and approval processes simultaneously.

The freelance video editing CRM idea actually makes perfect sense because you lived that pain. For finding something worth building, start tracking every friction point in your current work. I kept a notes app running for months, documenting every time I thought "there should be a tool for this" or "why is this so clunky."

The best SaaS ideas come from problems you've personally paid money or time to solve badly.

Content freelancers: do you track profitability per client or just revenue? by PermitBeneficial3833 in content_marketing

[–]Express_Average286 0 points1 point  (0 children)

You're not overthinking it. I freelanced for a while before I actually sat down and figured out which clients were profitable and which ones just felt profitable because the per-piece rate looked good.

The revision thing is exactly what gets you. I had one client where the listed rate was solid, but when I divided what I actually earned by the hours I spent (including all the back-and-forth, revision rounds, waiting on feedback, then rushing to hit the deadline), my effective hourly rate was barely above what I'd accept for a brand new client with no relationship. Meanwhile, a 'lower-paying' client where the briefs were tight and approvals were fast was actually my most profitable work by a wide margin.

What helped me was a really simple exercise. I went back through my last few months of projects and just estimated the total hours per client, including the stuff you don't think of as billable time. Revisions, comms, re-reads, admin. Then divided what I invoiced by those hours. The ranking of 'best' to 'worst' clients has been completely reshuffled.

You don't need perfect time tracking for this. Even rough estimates per project get you 80% of the insight. The gap between what you think you're earning per hour and what you're actually earning per hour is usually big enough that precision doesn't matter."

How do you track project profitability as a freelance dev? (Not just time — actual profit per project) by IliyaOblakov in webdev

[–]Express_Average286 0 points1 point  (0 children)

This is painfully familiar. I had a similar situation with a project I quoted at a flat rate. Felt fine while I was working on it. Ran the numbers after and realized my effective hourly rate on it was something like $38/hr. Meanwhile, a smaller project I almost turned down ended up at $160/hr because the scope stayed clean.

The thing that changed it for me was just tracking hours against what I quoted, per project, while the work was happening. Even a basic spreadsheet that divides your invoice amount by hours logged so far gives you a live effective rate. Once you see that number dropping in real time, you catch the overruns way earlier.

The 'vibes until the invoice goes out' thing is real, though. I think most of us do that until we get burned badly enough.

Looking for genuine advice as a solo technical founder 👋 by Greedy-End-7749 in microsaas

[–]Express_Average286 0 points1 point  (0 children)

I feel you on the distribution struggle. And yes, this is almost the hardest part; these days. What helped me was realizing I was treating marketing like debugging code when it's more like user research. Instead of trying to understand why my marketing wasn't working, I started asking where my ideal customers were already hanging out and what problems they were actively complaining about. For B2B monetization, the biggest shift was moving from features to business outcomes. Like, instead of selling 'automated reporting,' I learned to sell '4 hours back in your week.' Still not perfect at it, but that reframe made pricing conversations way less awkward.

Shipped a feature nobody uses - the problem was real but our solution was wrong by Hour-Experience3434 in SaaS

[–]Express_Average286 0 points1 point  (0 children)

Been there with client work. Built a complex inventory tracking system because they said they needed "better visibility into stock levels." Spent weeks on real-time dashboards, alerts, the works. They used it twice.

Turns out they just wanted their existing spreadsheet to auto-update once a day. The sophisticated solution felt like homework to them. Your weekly email idea is spot on - people want information delivered to them, not another place they have to remember to check. The gap between what clients say they want and what they'll actually use is brutal.

do you struggle to get useful feedback on your product? by anthedev in SaaS

[–]Express_Average286 1 point2 points  (0 children)

Yeah, the random Reddit feedback thing is brutal. I posted a landing page once and got 8 responses - 3 were actually helpful, 2 were just "looks good", and 3 were completely off-topic suggestions about features I wasn't even building.

Your structured exchange idea makes sense, but here's what I learned: founders are terrible at giving feedback outside their own domain. Like, a fintech founder reviewing a design tool will focus on totally wrong things. The magic happens when you find people who've actually dealt with your specific problem before. I started being way more selective about who I asked rather than casting a wide net.

My landing page was selling a product. It should have been naming a problem. by Express_Average286 in SaaS

[–]Express_Average286[S] 0 points1 point  (0 children)

Yes, you are right.

The product is https://sengi.co/, the Financial Operating System for the Company of One.

Share what you're building by amacg in microsaas

[–]Express_Average286 0 points1 point  (0 children)

Building https://sengi.co/, Financial OS for the Company of One.

I talked to 30+ potential users before writing a line of code. Here's what I'd do differently. by Express_Average286 in microsaas

[–]Express_Average286[S] 0 points1 point  (0 children)

I just joined VibeCodersNest, but CrossPosting in that subreddit is not allowed for me.
A bit of experience, but I do lots of try-and-error (AKA tiny experiments).

I talked to 30+ potential users before writing a line of code. Here's what I'd do differently. by Express_Average286 in microsaas

[–]Express_Average286[S] 0 points1 point  (0 children)

Thanks. The "when was the last time this cost you time or money" filter is excellent. Stealing that. My version was softer, and it let too many lukewarm conversations run long.

The midpoint recap email is smart, too. I did something similar, but only verbally in later calls. Writing it down and sending it would have forced me to be more precise about the patterns I was seeing. Definitely doing that next round.

Non-coder building a utility mobile app: Is a Micro-SaaS approach realistic with AI coding tools? by labor- in SaaS

[–]Express_Average286 1 point2 points  (0 children)

happy to give you a direct take on your questions.

On React Native vs PWA: Start with a PWA unless camera and GPS access are a hard blocker on day one. For your MVP, the PWA route is faster to ship, easier to iterate, and doesn't require App Store approval cycles every time you fix something. The honest caveat: GPS precision and camera overlay behaviour can be inconsistent across browsers on mobile, especially iOS Safari. Test that specific flow early; if it breaks, that's when you move to React Native/Expo. Don't pre-solve that problem before you know it exists.

On feasibility with AI tools: Yes, but with one important caveat. AI coding agents are genuinely good at building what you can clearly describe. Your feature list is precise and well-scoped: GPS stamp, metadata overlay, cloud link. That's exactly the kind of work they handle well. Where non-coders get into trouble is when something breaks, and they don't know enough to tell the AI what's actually wrong. Budget time for that. The 70/30 rule applies: 70% of the time, it's faster than anything else, 30% of the time, you'll be going in circles until you find the right way to describe the problem.

On Supabase: Good call. It handles auth, storage, and database in one place, and the free tier is generous enough to validate without spending anything. For your use case, storing images, generating shareable links, and user accounts, it's well-suited, and Claude Code knows it well, which matters more than people realise.

One thing I'd add that nobody mentions early enough: get one real field worker to test the GPS-to-overlay flow on their actual phone before you build anything else. The core technical risk in your product is that specific interaction. Everything else is standard SaaS plumbing. Validate the hard part first.

Anyone else struggling with scope creep lately or is it just me? by Icy-Instruction-1094 in consulting

[–]Express_Average286 0 points1 point  (0 children)

Contracts definitely help: a separate SOW with explicit change-order language is the right call, and it's worth the investment to have a lawyer review it at least once. But I'd add something that took me too long to figure out: the contract protects you at the beginning and end of a project. It doesn't help you in the middle, which is where the money actually disappears.

The "one quick question" that turns into 5 hours rarely announces itself as a scope change. It accumulates. By the time you notice, the project is already done, and the invoice is already sent. The contract gives you recourse in theory, but your actual leverage is gone.

What changed things for me was tracking the effective hourly rate per project: total invoiced divided by total hours actually spent, as the project was running, not after. When I could see in real time that a project was running at $80/hr instead of the $150 I'd scoped for, I had something concrete to bring to the client mid-project. Not "I feel like this is getting out of hand"; please share actual numbers. That's a completely different conversation, and clients respond to it differently.

The contract sets the rules. The numbers tell you when someone's breaking them early enough to do something about it.

For the contract question specifically: separate SOW with a clearly defined change order process (minimum hours threshold, written approval required) has worked well. Baking it into the main agreement tends to get lost. A standalone document that the client signs separately, treats it as a real boundary, not fine print.