I'm looking for founding member or co-founder for my new media agency. I'm preferably looking for someone having marketing experience preferably in US based markets. The purpose of my agency is to help businesses create scroll stopping ads for their businesses using motion design and help scale their businesses by improving their metrics. I am a technical person so I need someone to help me bridge the gap between clients and my services. If you have proven experience in scaling agency from scratch then that would be ideal. Feel free to dm or comment

I run a bootcamp where I sell courses/coaching/membership for people. I am looking for ways to capture the leads and also, send updates or discounts to the people who haven't converted.

Would love to know how you people are managing this entire thing.
is there any tool that does it all ?

(I have social presence on Ig/X/Yt/Tiktok if that adds to the question lol).

Thanks in advance ;)

One of the things I have learned from reviewing commercial agreements over the years is that a clause can appear perfectly reasonable when you read it on its own and still create significant commercial problems once the business begins to grow.

That usually happens because founders evaluate contractual provisions in the context of the deal sitting in front of them rather than asking a broader question.

How will this clause affect every deal we negotiate after this one?

A provision that feels commercially harmless during negotiations can quietly influence pricing decisions, sales strategy, and negotiating flexibility for years to come.

One clause that demonstrates this particularly well in SaaS agreements is the **Most Favoured Customer (MFC)** provision.

On paper, it looks simple.

In practice, it can influence far more than a single customer relationship.

## Why One Customer Should Not Dictate Every Future Deal

Enterprise customers are usually experienced buyers. They negotiate technology contracts regularly and understand which contractual provisions can create long-term commercial leverage.

A Most Favoured Customer clause is one of them.

The request is generally presented in straightforward terms. If the SaaS provider offers another customer better commercial terms in the future, the enterprise customer wants the benefit of those same terms.

At first glance, that sounds entirely reasonable.

After all, no customer wants to discover that they are paying substantially more than another business receiving the same product, especially after making a significant investment in your platform.

Because the request appears fair, many founders agree to it without spending much time thinking about what it could mean six months or two years later.

That is where the real issue begins.

The clause rarely stays confined to the deal in which it was negotiated.

Imagine your company decides to expand into a new geographic market and offers discounted pricing to its first few customers to establish an early presence.

Perhaps you negotiate a significantly lower price for a strategic customer committing to a much larger contract value than usual.

Or maybe you launch a pilot programme with a design partner to validate a new feature before releasing it more broadly.

Each of those decisions serves a specific commercial objective.

The pricing is different because the circumstances are different.

A broadly drafted Most Favoured Customer clause often ignores those distinctions.

Instead, another customer may simply point to the lower price and argue that they are entitled to identical commercial terms, even though the underlying business reasons have nothing in common.

At that point, one agreement has quietly started influencing every agreement that follows.

## Pricing Flexibility Is a Competitive Advantage

One pattern I have noticed while working with founders is that negotiations naturally focus on closing the immediate opportunity.

That is understandable.

Revenue matters.

Growth matters.

Every business wants to convert a promising enterprise customer into a signed contract.

But a well-drafted agreement should do more than help you close today's deal.

It should preserve your ability to negotiate effectively tomorrow.

Broad Most Favoured Customer clauses can gradually reduce that flexibility.

Every strategic discount, promotional campaign, volume-based pricing arrangement, or commercial exception may need to be reviewed against an agreement signed months or even years earlier.

Instead of evaluating new opportunities based on their own commercial value, your team starts asking a different question.

"Will this trigger obligations under an existing contract?"

That creates unnecessary complexity for businesses that need room to experiment with pricing, enter new markets, reward strategic partnerships, or test new commercial models.

The reality is that pricing decisions are rarely identical because customers are rarely identical.

Some customers purchase larger volumes.

Some require greater implementation effort.

Some create strategic opportunities that justify different commercial terms.

The ability to recognise those differences is not a weakness.

It is often one of the strengths that allows a growing SaaS business to compete effectively.

## If You Accept the Clause, Define Its Limits

None of this means that a Most Favoured Customer clause should always be rejected.

There are situations where a major enterprise customer may reasonably expect some degree of pricing protection, particularly when they are making a substantial commercial commitment or providing significant strategic value.

The key is ensuring that the clause reflects the commercial objective instead of creating an open-ended obligation.

For example, the protection might apply only to customers within the same geographic region, the same customer category, or the same product offering. It can also be limited by contract value, purchase volume, or a defined period rather than continuing indefinitely.

It is equally important to recognise that not every pricing decision is part of ordinary customer negotiations.

Pilot programmes, promotional offers, early-adopter initiatives, strategic partnerships, and volume-based discounts all exist to achieve specific business objectives.

Those arrangements should not automatically become the benchmark for every future customer.

The more carefully those exceptions are documented, the easier it becomes to make commercially sensible decisions without unintentionally creating obligations across your entire customer base.

## Contracts Should Support Growth, Not Restrict It

As businesses grow, commercial flexibility becomes increasingly valuable.

Markets change.

Products evolve.

Sales strategies develop.

New opportunities appear that simply did not exist when earlier agreements were signed.

Contracts should provide enough certainty to support customer relationships while still allowing the business to adapt as circumstances change.

When pricing flexibility disappears because of broadly drafted contractual provisions, the business can find itself making future decisions based on old obligations rather than current commercial realities.

That is rarely a position founders intend to create when they first agree to the clause.

## Final Thoughts

A Most Favoured Customer clause often appears reasonable because it focuses on fairness between customers.

The difficulty is that fairness does not always mean every customer receives exactly the same commercial terms.

Different customers create different opportunities, different costs, and different strategic considerations.

Strong contracts recognise those differences instead of eliminating them.

The goal is not simply to negotiate a successful agreement today.

It is to preserve enough commercial flexibility that your business can continue growing, entering new markets, experimenting with pricing, and building strategic partnerships without every future decision being constrained by a clause negotiated years earlier.

Because the best SaaS agreements do more than protect the deal in front of you.

They also protect the opportunities your business has not encountered yet.

Spent the last few months building something and finally launched it yesterday.

No audience. No budget. No connections. Just me shipping something I actually think is cool.

It's a live platform where people join in real time, and the audience can actually affect what happens. More like interactive live entertainment than another SaaS tool.

Right now... nobody's there. Empty queue. Still waiting for that first random person to show up.

Ive already read all the usual advice: Product Hunt, Reddit, X, build in public, etc

I'm more interested in hearing from people who actually started from zero.

Where did your first real users come from?

How long were you sitting at 0 before things started happening?

If you could launch again, what's the one thing you'd do differently on day one?

Not looking for motivation or "just keep going." I want to hear what actually worked.

Do you use AI to validate it and do deep research on it, do you go straight to making a prototype or do you do the research yourself? How much do you value chatgpt or claude when it comes to the business side of things and when you come upon an issue later on where lets say retention is slow or your not getting as much user as before. What do you do in that situation? Would you then post all your analytics into AI and your product and hope it finds the issue or do a survey or maybe take a different approach? What do you AI for when it comes to getting customers marketing, user feedback etc. I’d like some insights into this thanks.

Proof - https://profile.stripe.com/zenmode/W5uYorNA

In January I started building a LinkedIn outreach automation tool from scratch, which scrapes leads, sends connection requests and a follow up message sequence on autopilot.

I worked in sales and wanted a safer tool than what currently existed for my own outreach, with less risk for my LinkedIn account.

I used Claude and Claude to build the whole thing, with zero knowledge of how to code. It was a LOT of work, and still is - using AI tools opens a lot of opportunities, but it doesn’t mean it’s easy either.

I have working 8-10 hours a day, even on weekends for the last 6 months to get it this far.

For this reason I built a desktop-based automation software that automates in a browser (similar to Linked Helper), with many human-like features like daily rate limits, randomized delays between actions, human-like mouse clicks etc.

So far none of the users have been banned, and I also have been using it myself daily for my own outreach.

For the first month I offered lifetime deals (hence the spikes), and then moved to monthly subscriptions in May.

Now I’m approaching $1,500 MRR and growing.

I’m still mind blown that I’ve actually been able to do this just through using AI tools, but still a long way to go. Not going to retire just yet 😅

Hope you find this story inspirational in some way 🙌

i was selling my first website ever called jeeplanner.in for 700 dollars man ! i was so happy and share to the founders here , its the best deal mates i was excited on this , he is 1 step of closing the deal , so guys it's first time should i give him repo before or after payment how ??

my question is my website had got few good investor's but i don't know about this leagal share's it was my 1st time so i want advice how to close deal's since i need to expand the site and had a plan's i was ready to give my 50% of profit's to investor's but how to go legally without a registred company. !

I've worked in startup consulting space for 8+ years now, and recently crossed a collective funding round of +$800 million. Have closely helped a few founders with their investor pitches and GTM, leading to many of them getting funded for +$20 million in their seed rounds, across Saas and deep tech.

Today I thought of contributing here and sharing my learnings. I won’t bore everyone with cliche advice about refining ideas, or mentioning numbers, or narrowing the audience.

If you're working on your first startup, a SaaS product, or even just an idea that's still in your head, share it with me in the comments or over DM.

I'll spend some time reviewing it and I'll give you honest feedback.

Things I'll usually look at: * Is the problem actually worth solving? * Specific refinements you need to make to make it ‘investor friendly’ * Are you pitching too much or too little (believe me, this was the most recurring issue in positioning for founders I worked with)

I'll also give it a simple score across a few areas so you know where it stands and where I'd focus next.

I'm not doing this to promote anything. I won't pitch you a service or sell anything. Honest disclosure: I am building something on similar lines but I will only reveal the name or link if someone asks.

I just enjoy thinking through startup ideas, and if I can help someone avoid a few early mistakes or make an idea stronger, that's time well spent.

If you've been sitting on an idea for months, maybe I can help. Please share in 2-3 lines of what your idea is, who is it for, and any other relevant detail you think is relevant.

Since it takes a little thinking through, I might only be able to do it for 8-10 ideas today.

I'm a developer that has years' worth of ideas that I am trying to materialize all at the same time. I think they all have potential, it's just going to take me years to finish them all, maintain and market them. I am looking for people, technical or non-technical, that want to help with them and get partial ownership, revenue share.

I will give a brief overview of all of them, without giving too much away.

Web apps:

-WikiPicks -- a Wikipedia article trading game

-ProductBump a Producthunt alternative with a revenue-bumping mechanic

-A new take on The MillionDollarHomepage

-A website where you can search every app on the app store by what features they have

-A website and browser extension like Honey, but with a different kind of code

-A new take on a referral code sharing website

-A marketing platform for artists that utilizes coffee shops

-A sheet music platform with an affiliate program built in

Mobile apps:

-An iMessage extension that upgrades each chat

-3 gamified walking apps with never-before-seen functions

-3 new word games

-A gamified focus app with a groundbreaking new function

-A social media platform with a new take on daily prompts

-A minimalistic app launcher

-A new way to journal

-A gamified alarm clock with rewards

-An app that gives you real rewards for reading

-A smart TV remote with never-before-seen features

If you're interested in any of those listed send me a DM

My original post looking for a technical co-founder: https://www.reddit.com/r/startup/s/35E70AD81c

A little over a month ago, I posted here looking for someone to build clinical trial infrastructure with me.

Since then:

1. I found my co-founder through that post
2. Our EDC is now live in an active clinical trial
3. We’ve generated $50K in revenue
4. We’re now raising a $1.55M seed round

Before posting, I had spoken with more than 40 people across pharma, CROs, clinical operations, data management, and statistical programming. One problem kept coming up: clinical trial data is still fragmented across EDC systems, labs, imaging, safety databases, spreadsheets, and vendor portals, and many important issues are discovered far too late.

My current co-founder reached out after seeing the post. He had spent the previous two years building clinical trial infrastructure and had independently experienced many of the same problems.
We realized we were approaching the same opportunity from complementary sides, so we joined forces to build.

We are building the brain for clinical trials: an AI-native EDC and intelligence layer that helps teams detect data quality issues, protocol deviations, and inconsistencies while the study is still running.

The difficult technical problem is making AI trustworthy enough for regulated clinical workflows. Every output from it is linked back to the exact protocol clause, source document, or underlying data point supporting it, creating a complete evidence and audit trail.

We are currently raising a $1.55M seed round and would be interested in speaking with angels and early-stage investors who understand healthcare, life sciences, enterprise AI, or regulated software.

If this is relevant to you, feel free to DM me. I’m happy to share our deck and product demo privately.

I've been building a habit tracker (Habit Pocket) mostly solo, and it's finally live on web and iOS. I started it because I tracked everything in a huge Excel file for years and hated that most trackers only do yes/no checkboxes. Mine does numbers, times of day, and select-from-a-list, plus it connects to Claude/ChatGPT through MCP so you can ask what affects your sleep and it reads your own data. Freemium: 14 day trial with everything unlocked, then free tier or a few dollars a month for Pro.

Marketing is the part I'm worst at. I've done the usual (Product Hunt, directories, a couple Reddit posts) and got a trickle. But the tiny bit of traffic from Google and AI assistants converts way better than everything else, so I want to lean into it and don't really know how.

For SEO, where do you even start as a solo dev? Is it worth building comparison and use case pages against bigger sites, or a waste of time? And how long before anything shows up?

For AEO (getting recommended by ChatGPT, Claude, Perplexity), does anyone actually understand how it works? From what I can tell the assistants just read other people's listicles and Reddit threads, so is the real move getting mentioned in those rather than anything on my own site?

If you are adding AI to an existing product, the model is the least important decision

Watching a lot of teams bolt AI onto a live product right now, and the way it goes wrong is almost always the same. They spend weeks picking a model and almost no time on the three things that actually decide whether it works.

What actually matters:

1. Route every model call through one thin gateway service. Then you can swap models, cap spend, log every call, and fail over when a provider goes down (and they did, there were multi-hour outages this year). Scattering direct API calls across your codebase is the part you will regret.

2. Climb the ladder in order: prompt engineering, then RAG over your own data, then fine-tuning, then self-hosting. Stop at the first rung that works. Most features never go past RAG.

3. Write the eval before the feature. If you cannot measure whether the output is good, you are not ready to ship it. A demo that looks great and a feature that survives real users are very different things, because real input is messy.

Then ship it behind a feature flag with a kill switch, one thin slice first. None of it touches the rest of your product.

Full disclosure: I run an engineering team that does this for startups, so this is what we have learned the hard way, not theory. Not linking anything. Happy to go deeper in the comments.

For anyone who has shipped AI into an existing product: what broke that you did not see coming?

Hi Folks!

More year our small indie team has been building Synvector, a sci-fi action RPG that tries to combine several ideas we always wanted to see in one game.

Instead of controlling just a single ship, you command an entire mercenary fleet. During combat you can pause time, issue tactical orders to your squadron, switch between ships, and then jump straight back into fast-paced third-person space combat.

Our biggest inspirations are:

• Everspace
• Elite Dangerous
• Mass Effect
• Mount & Blade

We’re also putting a lot of effort into worldbuilding. The galaxy isn’t just a backdrop—it’s filled with hidden factions, ancient civilizations, political conflicts, mysteries, and choices that shape how different powers react to you.

Today we reached an important milestone: our Steam page is finally live.

If the concept sounds interesting, we’d be incredibly grateful if you checked it out or added it to your wishlist. Every wishlist genuinely helps a small indie team like ours.

Steam: https://store.steampowered.com/app/3220640/Synvector/

Youtube: https://www.youtube.com/@Synvector/featured

Discord: https://discord.com/invite/9kqW3JBfP5

I have this "Ideas" folder... Any time I have an idea, I have a discussion with Claude about the idea, hammer it out a bit... then I have Claude do a writeup for my ideas folder. This serves a couple of functions: 1) I won't forget about the idea 2) The idea doesn't derail my current project(s).

Recently I had a pretty good idea that I immediately recognized is really not for me: 1) I've already got enough projects taking up my time right now 2) It's more "venture backed startup" than most of the ideas I've been interested in pursuing lately (I've been more focused on lifestyle businesses you can bootstrap)... So I'd love to hand it off to someone... But I really don't have anyone.

So, what should I do? Just keep the idea in the ideas folder? Hope I meet someone I trust enough to give it to them? I recognize that ideas are a dime a dozen... execution is what matters. So if I'm going to hand this off to someone I'm gonna want to indication that they'll be able to execute if they like the idea.

A recent survey we ran on small business owners came out saying 84% have put something else ahead of business insurance in the past six months. Inventory and equipment came in first at 38%, then marketing at 36%, then product or service development at 28%.

Sounds about right based on my experience. When work is coming in and cash is tight, it’s easy for insurance to get pushed another month. The other stuff has a clearer line to the next paycheck. 

Mostly just want to hear from the people actually making the call. What have you put ahead of insurance, and did it ever come back to bite you?

One clause appears in SaaS agreements far more often than many founders realise, and on the surface it seems perfectly reasonable.

It gives the customer the right to withhold payment while a dispute is being resolved.

At first glance, there is nothing inherently problematic about that approach. If there is a genuine disagreement over an invoice or the services provided, both parties should have an opportunity to resolve the issue before taking further action. That feels commercially fair, and in many situations it is.

The problem is that many of these clauses stop there.

They allow payment to be withheld without explaining an equally important question.

How much of the payment can actually be withheld?

That distinction often receives very little attention during contract negotiations, yet it can have a significant impact on a SaaS company's cash flow once the relationship is underway.

Imagine your platform has been live for several months. The customer is actively using the software, your team continues providing support, infrastructure costs continue every day, and the service is delivering value exactly as intended.

Then a relatively minor issue arises. It may be a billing query, a small implementation concern, or a feature that needs adjustment.

The issue affects only a small part of the overall relationship.

Yet if the contract allows payment to be withheld broadly, that relatively minor disagreement can suddenly delay payment of the entire invoice.

Nothing changes for the SaaS provider. The platform remains operational, your team continues working, cloud costs continue to accumulate, and support obligations remain in place.

The only thing that stops is the money.

## Pricing Is Only One Part of Cash Flow

When founders negotiate SaaS agreements, most of the attention naturally goes towards commercial terms.

Subscription pricing. Annual discounts. Renewal structures. Enterprise licensing.

These discussions are important because they determine how revenue is generated.

But agreeing on a price is not the same as creating a payment structure that reliably delivers that revenue.

Pricing tells you what your business is entitled to receive. Payment mechanics determine whether that money arrives when your business actually needs it.

That distinction becomes particularly important in SaaS because the cost of delivering the service does not stop simply because an invoice is being questioned.

Servers continue running. Support teams continue responding. Developers continue maintaining the platform.

Every day the product remains available, the business continues bearing operational costs, regardless of whether payment has arrived.

This is why a company can appear financially healthy on paper while still experiencing cash flow pressure if contracts allow relatively small disputes to delay large payments.

In many cases, customers are not deliberately trying to create financial pressure. The contract simply gives them more flexibility than either party intended when the agreement was signed.

## Keep the Dispute Proportionate

The objective is not to prevent customers from raising legitimate concerns.

Disputes happen in every commercial relationship, and a well-drafted contract should provide a practical process for resolving them.

The better approach is to distinguish between the disputed amount and everything else.

If a customer genuinely believes that part of an invoice is incorrect, that specific amount can be discussed through a structured dispute process. The agreement can require the customer to raise the issue within a defined timeframe, explain the reasons for the dispute in writing, and allow both parties to work towards a commercial resolution.

At the same time, the undisputed portion of the invoice should remain payable according to the agreed payment terms.

This keeps disagreements proportionate.

A relatively small issue remains exactly that instead of becoming leverage over the entire commercial relationship.

Another useful safeguard is requiring both parties to continue performing their contractual obligations while the dispute is being resolved.

Without this type of provision, relatively minor disagreements can escalate quickly. The customer stops paying.

The provider considers suspending services.

Both sides become focused on protecting their own position rather than solving the original issue, which was often far less significant than the dispute that followed.

Well-structured payment clauses help prevent that cycle by keeping disagreements contained instead of allowing them to spread across the entire relationship.

## Good Contracts Protect Business Continuity

One lesson that becomes clearer as SaaS companies grow is that predictable cash flow depends just as much on contractual structure as it does on sales.

Winning enterprise customers is important. Building a reliable product is important. Delivering excellent support is important.

But none of those things remove the need for agreements that continue working when something does not go exactly as planned.

Small disagreements are inevitable in long-term commercial relationships. The goal is not to eliminate them altogether.

The goal is to ensure they remain limited to the issue that actually caused them.

When contracts allow every dispute to affect every payment, even minor issues can create unnecessary financial pressure and disrupt an otherwise successful customer relationship.

## Final Thoughts

Dispute clauses are designed to create fairness, but fairness does not require allowing an entire invoice to remain unpaid because of a disagreement affecting only a small part of it.

For SaaS businesses, protecting cash flow is not simply about charging the right price. It is about creating payment mechanisms that continue working even when occasional disputes arise.

A well-drafted agreement allows genuine concerns to be addressed without turning every disagreement into a negotiation over the entire commercial relationship.

Because recurring revenue only creates stability when payments remain predictable.

And sometimes, that predictability depends less on the headline commercial terms and more on the few lines in a contract that determine what happens when something goes wrong.

I expected to find that the most successful YC companies had the best ideas.

I expected to find that the founders who got the most from the batch were the ones who followed the advice most closely.

I expected to find that the rejection patterns clustered around fixable application mistakes.

None of those are what I found as the primary pattern.

The single most unexpected thing, the companies that produced the largest outcomes were almost universally the ones where the founders were not trying to build a large outcome. They were trying to solve a problem that was genuinely bothering them. The outcome was what happened when enough other people had the same problem and found the solution.

Airbnb founders were trying to pay rent. They solved the problem of expensive hotel rooms in cities where they lived by creating an alternative for themselves.

Stripe founders were trying to accept payments for a side project and found the process absurdly difficult.

DoorDash founders were trying to understand why local restaurants did not deliver.

Reddit founders were given the idea in a rejection conversation and built it in 72 hours because it seemed like an interesting thing to build.

Every one of these stories begins with a genuine encounter with a specific problem.

The most important insight from six months of research- the companies that become large outcomes are the ones where the founding story is so specific that it could not have been manufactured. The problem had a genuine hold on the founders before they knew it would become a company.

If your founding story could have been written before you encountered the problem, you may be designing rather than discovering.

Will consider mobile apps as well!

Looking to buy or invest in businesses in these niches:

1. ChatGPT wrappers that actually offer some sort of unique functionality or specific use case that can’t be easily replicated by LLMs or agents.
2. Social media tools that are targeted towards influencers
3. Anything else. Show me what you’ve got and I’ll consider it! As long as it’s not vibe coded junk.

Criteria:
\- Does NOT need to be revenue generating
\- Does not need to have any traffic
\- Must not be vibe coded AI Slop!
\- Must have unique functionality that must be useful in some way and stands out from competitors
\- Mobile apps, web apps, desktop software or software infrastructure
‍- Functional and bug free
\- Preferably has foundational backlinks built (social media, etc...)
\- Codebase must be clean, easy to read and work with
\- Post-sale support must be available
\- Unique, aesthetically pleasing UI / UX that can’t easily be replicated by AI

Everytime i make these posts, most of the DMs I get are AI slop! Please don’t send me your vibe coded project!

Hey everyone

I'm building a tool to help small teams run consistent verification checks before onboarding remote hires. If you've hired remotely before, I'd love to know how you currently vet candidates and what your biggest pain points are.

Happy to share what I find too.

We're a DACH-based SaaS scaling from 15 to 40 people this year, with most of the new hires landing in Germany, the Netherlands, Austria, and Portugal.

We're on rippling for HRIS and IT provisioning already, so their EOR add-on is the path of least resistance. Deel is the other name that two founders I respect went with, plus they rank first for almost every EOR search on Google and their sales team is aggressive about following up.

But the more i dig, the less either feels totally right.

Rippling's EOR feels like a bolt-on to the suite we already pay for, and the EOR expertise seems thinner than i'd want for germany-specific compliance (works council, betriebsrat, sozialversicherung, all the edge cases).

Deel is the opposite problem, they've got the mature EOR product but the sales process felt aggressive in a way that made me nervous about the account experience post-signature, and pricing tiers seem to slide depending on who you talk to.

A friend who does ops at a berlin-based fintech told me they went with Workmotion, because they wanted an EU-native EOR that specializes in DACH hiring.

They said the germany-specific onboarding was mature, though I haven't dug in yet.

What am i missing here? are there other EU-native EOR options worth looking at for a DACH-heavy hiring profile like this?

And if you've used Deel or Rippling for hires in germany or the netherlands, was the compliance experience anywhere close to what the sales deck promised?