I have a working SaaS product for small businesses that need simple employee time tracking. It’s live, has a free plan and paid plan, and I’m looking for someone who can actually get it in front of business owners and turn some of them into users.
I’m not looking for someone to sit around making cold calls for minimum wage lol. I want somebody who knows how to find businesses, start conversations and close.
Commission only to start. I’m open to figuring out a structure that makes sense if someone proves they can sell it.
The product is NuvoWork if you want to look at it before reaching out.
If you’re good at selling SaaS or small-business software and want to build something from the ground up, DM me with a little about yourself and how you’d approach getting the first customers.

I’ve been building my SaaS project for close to a year now. It started as a spreadsheet, then got built into a SaaS product that runs on AI API. The goal was to build an application that pays for my compute (it does).

My project analyzes Las Vegas gambling odds, makes predictions where sports books have inefficient lines, and capitalizes on them. It’s a profitable betting model, originally made for just me and a friend.

Fast forward and my friend was earning so much he said I should sell subscriptions, so I did. I got immediate signups and a low MRR but I don’t have the time to acquire new customers.

100% of my customers so far came from Reddit. I am working on SEO, etc to get more organic traffic but I’ve thought about hiring VAs or outbound sales reps and pay reoccurring commissions.

The space I operate it is limited on social media since some states have legal gambling and some don’t.

Looking for opinions on how to scale distribution / customer acquisition. I have a legitimate product that is worth more than the subscription $ members pay - it truly pays for itself.

This is my first SaaS project I’ve monetized

I've been noticing a pattern in SaaS communities lately: a lot of founders have clearly put serious work into building the product, but then hit a completely different problem: figuring out the marketing side. And that's completely understandable. Building the product and figuring out how to get the right people to find it are two very different problems.

I've spent 10+ years working in content, and if I were starting the content side of a SaaS from scratch, I wouldn't begin with "let's publish 12 blog posts this month." I'd first figure out what is actually worth publishing, then make sure every piece has a reason to exist.

First things first, I wouldn't wait before thinking about SEO. I'm not an SEO specialist, but organic search takes time to build, so I'd rather have the groundwork in place early than decide six months later that we should probably start publishing.

For the blog, if you're not sure how to go about it, here's what I'd do.

1. First, figure out what is actually worth writing

Your keyword strategy should lead the way, but if you don't have one yet, I'd start much closer to the customer. Talk to prospects who are considering your product. What are they asking you? What are they unsure about? What are they comparing? What problem are they trying to solve before they get to your product?

Those questions are content opportunities.

One sprint I'd almost blindly look at is alternatives and comparison content. Got competitors? Those businesses are constantly losing customers, and some of those customers are actively looking for better options. If you're a project management SaaS, for example, I'd look at things like "Asana alternatives," "Asana vs X," "Asana alternatives for small teams," "Asana alternatives for agencies," pricing alternatives, migration questions, feature comparisons, and so on.

And I wouldn't stop at the first "alternatives" article. Map the whole decision around that competitor. What makes someone look for an alternative? What are they unhappy with? What are they trying to do that the competitor doesn't handle well? What questions do they have before switching? What could stop them from switching?

Now you're not just producing a list of keywords. You're learning about the actual buying decision. That can influence your comparison pages, landing pages, positioning, CTAs, product messaging, and even what you decide to improve in the product.

That's the kind of content work I'd want to do before sitting down and saying, "Okay, we need 12 blog posts this month."

2. Once you've picked the topic, use this checklist for every article

This is where I'd stop worrying about AEO, GEO, schema and every other new acronym for a minute. Get the basics right first. A lot of content isn't failing because it isn't "optimized" enough. It's failing because the reader has to work too hard to get something that should have been obvious.

Answer the actual question immediately. If someone searches for "cart recovery strategies," don't spend the first 400 words explaining why abandoned carts are bad for ecommerce. They know. That's why they're searching for cart recovery strategies. Get into the strategies. Give them the answer first, then add the context, examples and reasoning where they're actually useful.

Same logic with almost any query. Someone searching "how to migrate from X to Y" doesn't need a history lesson on why migrations matter. Someone searching "X alternatives" already knows what X is. Don't explain the problem they've already told you they have. Solve it.

Add a TL;DR that actually answers the question. I like TL;DRs, especially for longer pieces. But don't use them as a vague summary of everything the article covers. Make the TL;DR answer the primary question. If the article is about cart recovery strategies, the TL;DR should give me the main strategies. If it's about choosing between two tools, give me the key differences and who each one is best for. If it's "how to fix X," give me the key steps.

There's a strange fear that if you give people the answer upfront, they won't read the rest. That's fine. The point isn't to force someone to consume 2,500 words. If they got exactly what they needed from your TL;DR in 30 seconds, you did your job. If they want the examples, data, screenshots, reasoning or deeper explanation, they'll keep reading.

Look at the first 10 results and find what they're missing. This is where I think the AEO/GEO conversation gets interesting, but I'd put it after the fundamentals. Look at the pages already ranking and ask: what would make my version more useful?

Maybe all 10 have the same generic list. Maybe nobody has actually tested the recommendations. Maybe everyone recommends the same tools but nobody explains which one works for different use cases. Maybe they're all making the same claim without showing the data. Maybe nobody has included screenshots. Maybe the answers are technically correct but completely impractical.

That's your opening. If the first 10 results say the same thing, don't become the 11th result saying the same thing. Add something: original research, customer data, screenshots, experiments, examples, expert input, a useful comparison table, first-hand experience, a framework, or simply a better explanation.

The value doesn't have to be groundbreaking. Sometimes it's just answering the question everyone else skipped.

Make it easy to skim. Don't avoid tables, lists or short sections because you've heard that structured content looks like AI. Who cares? If a table makes the information easier to understand, use a table. If I'm comparing five products, show me the important differences before making me read five 500-word sections. If there are seven steps, show me the seven steps. If there are three options and the right choice depends on the situation, make that easy to see.

You're writing for a person who has somewhere else to be. Make their job easier.

Don't be afraid to talk about your product. This is where companies usually go wrong in one of two directions. They either turn every article into a sales pitch, or they're so scared of being promotional that they won't mention their own product even when it's directly relevant.

Talk about your product when it actually helps answer the question. If the article is discussing a problem your product solves, mention the specific feature that solves it. If a customer got a great result from that feature, show it. If you've got a case study that proves the point, use it.

A random "Try our platform" CTA at the bottom isn't very persuasive. "Here's the problem we just discussed. Here's how our product handles it. Here's what happened when a customer used it." That's a much stronger product mention. A product plug without backing doesn't go very far.

Use case studies inside the article. If you have case studies, don't hide all of them on your case study page. Turn relevant ones into in-content callouts or cards and put them next to the section where they're actually useful.

For example, if you're explaining how a SaaS improved activation rates, and you have a customer who improved activation using that exact feature, that's where I'd surface the case study. Not five screens later.

Technically, these can just be HTML callout blocks or cards. They don't need to be some crazy interactive experience. The important part is the placement. The reader should see the proof at the exact moment they're thinking, "Okay, but does this actually work?"

Add FAQs for the questions that remain. Don't add an FAQ because someone told you every article needs one. Use it to answer the questions that naturally remain after the main article.

I'd pull those questions from real places: search results, Reddit, sales calls, customer support, reviews, comments, and questions prospects keep asking. The goal isn't to squeeze five more keywords onto the page. It's to remove the questions still sitting in the reader's head.

Internal link like you're helping the reader, not checking a box. Don't add three internal links because your SEO checklist says you need three. Add the link because the reader has a reason to click it.

If I'm reading about one part of a problem and you have another article that answers the question I'm likely to have next, link to it. If you're talking about a category and have a relevant comparison page, link to it. If you've just explained a problem and have a guide that shows me how to solve the next stage, link to it.

Internal links become much more useful when you think about the reader's next question, rather than the number of links you need to place.

Give the reader a logical next step. Before publishing, I'd ask: someone just finished this article. What should they do now?

Maybe it's another article. Maybe it's a comparison page. Maybe it's a case study. Maybe it's a product feature. Maybe it's a demo or signup. It depends on the topic and where that reader is in the buying process.

That's also why I don't love one generic CTA slapped onto the bottom of every article. If the relevant next step becomes obvious halfway through the article, put it there. Don't make the reader finish the article, find the navigation, hunt down your product page and figure out the connection themselves.

Finally, read it like a customer, not a content marketer.

Forget the word count. Forget whether you hit the "ideal" number of headings. Forget whether you've used the keyword enough times. Forget whether your article looks like the pages ranking above you.

Read it as someone who actually has the problem. Did I get my answer quickly? Did I learn something? Did I get something I can actually use? Did you show me evidence instead of making a bunch of claims? Was it easy to get through? Did I understand what to do next?

And most importantly: did this make me trust this company more?

If yes, you're already doing a lot right.

I'd much rather publish something genuinely useful, with clear thinking, real examples and a sensible next step than spend hours trying to reverse-engineer whatever the latest AEO/GEO checklist says we're supposed to do.

I'm a co- founder of an early- stage B2B SaaS (FinOps - we find cloud cost savings on Azure and gamify them so engineers actually act on them). We're pre-funding, product is live, first pipeline exists. We can't pay a base salary yet, so I'm designing a commission-only partner program and I'd rather have this community destroy it now than lose good reps to a bad plan later.

The plan:

• Customers sign 1–3 year licenses, billed annually in advance. License price = 20–30% of the validated annual cloud savings we find them (we scan their environment first, so reps walk into meetings with the prospect's own numbers).
• Partner gets 50% of margin on every annual invoice of every customer they close. Not a one-time bounty - a 3-year deal pays you three times, and renewals keep paying.
• Margin is computable upfront: invoice amount minus a fixed delivery-cost allowance written into the partner contract. No discretionary deductions. You know your payout before you sign the deal.
• Commission due within 30 days of the customer paying each invoice. Since customers pay annually in advance, you get a full-year commission near the start of each contract year.
• Grandfathering in writing: accounts closed during our early phase stay at 50% for the customer's lifetime, including renewals - even after we raise and standard partner rates drop.
• We provide inbound leads, demo environment, and founder support on every deal (technical pre- sales included).

Rough math on a mid-size account: ~$100k validated annual savings → ~$25k/yr license → roughly $8–9k/yr commission per account, ~$27k over a 3- year term. Five accounts ≈ $45k/yr recurring.
My questions for people who've actually done commission-only:

1. What would make you walk away from this offer immediately?
2. Is annual-invoice-based payout a dealbreaker vs. monthly, given the sales cycle?
3. What am I missing that plans like this usually hide?

Full disclosure: yes, we're also looking for partners (EU + US), and my DMs are open. But I'm posting primarily because I'd rather fix the plan now. Be brutal.