u/Fine-Variety-9759

I learned a painful lesson twice.

I launched a product, and it failed. Looking back, I realized I had made a major assumption without talking to enough people with real industry experience.

While building my second product, I recognized that mistake. Halfway through, I realized again that I really needed someone with deep industry experience involved.

But I didn't have the money to hire someone, so I had two choices: stop building and wait until I could get the right expertise, or keep going with what I knew.

I kept going.

The frustrating part is that halfway through, I already knew I was probably making the same mistake. I knew there was a good chance it would fail.

But I kept telling myself things like, "This is still a good direction," "I'll learn by building this," and "Maybe these extra things I'm adding will eventually make it work."

I was basically finding reasons to continue because I liked the direction and didn't want to accept what I was already seeing.

Eventually, I failed again.

The hardest part is that I already knew the lesson from the first time. I just couldn't see the truth clearly while I was emotionally invested in what I was building.

Now I'm wondering about the difference between not giving up and simply continuing because you've already invested so much.

Have you ever realized halfway through that you were heading in the wrong direction, but still continued because you had already invested so much?

I have seen a situation that made me think about how startup businesses actually work.

Let's say a developer's market salary is ₹1 lakh per month, but a startup hires them for ₹50,000 because the company is still small and doesn't have enough revenue yet.

The founder brings in the client. The developer delivers the work. The project succeeds and may even get extended because of the quality of the work delivered.

For example, I know of a small startup with only a few people. The founder brought in a client, but one of the developers worked closely with that client, delivered good results, and helped maintain the relationship. What started as a smaller engagement eventually turned into a much longer project.

Later, when the developer asked for better compensation or shares in the company, the response was something along the lines of:

"I brought the client."

"If you bring a client, then we can talk about revenue sharing."

I can understand both sides. Bringing clients is difficult and without sales there is no business. At the same time, execution, retention, and long term delivery also create value.

So I'm wondering how most startups actually think about this.

If a company cannot afford to pay market rates, should the difference eventually be compensated through higher salaries, bonuses, profit sharing, or equity?

Or is the common view that client acquisition carries most of the value, so founders naturally keep most of the upside?

I'm not looking for who's right or wrong.

I'm trying to understand the ground reality. How do most founders and employees actually think about this in practice?

When an employee asks for a raise, profit sharing, or equity, is the common response usually:

"I brought the client, so the upside belongs to me."

"If you bring clients, then we can talk about sharing revenue."

Is this simply how most small startups operate, even if some people disagree with it? Or do successful founders usually find other ways to reward people who create significant value for the business?

I'd like to hear real experiences rather than ideal answers. What have you actually seen happen in startups?

I have seen a situation that made me think about how startup businesses actually work.

Let's say a developer's market salary is ₹1 lakh per month, but a startup hires them for ₹50,000 because the company is still small and doesn't have enough revenue yet.

The founder brings in the client. The developer delivers the work. The project succeeds and may even get extended because of the quality of the work delivered.

For example, I know of a small startup with only a few people. The founder brought in a client, but one of the developers worked closely with that client, delivered good results, and helped maintain the relationship. What started as a smaller engagement eventually turned into a much longer project.

Later, when the developer asked for better compensation or shares in the company, the response was something along the lines of:

"I brought the client."

"If you bring a client, then we can talk about revenue sharing."

I can understand both sides. Bringing clients is difficult and without sales there is no business. At the same time, execution, retention, and long term delivery also create value.

So I'm wondering how most startups actually think about this.

If a company cannot afford to pay market rates, should the difference eventually be compensated through higher salaries, bonuses, profit sharing, or equity?

Or is the common view that client acquisition carries most of the value, so founders naturally keep most of the upside?

I'm not looking for who's right or wrong.

I'm trying to understand the ground reality. How do most founders and employees actually think about this in practice?

When an employee asks for a raise, profit sharing, or equity, is the common response usually:

"I brought the client, so the upside belongs to me."

"If you bring clients, then we can talk about sharing revenue."

Is this simply how most small startups operate, even if some people disagree with it? Or do successful founders usually find other ways to reward people who create significant value for the business?

I'd like to hear real experiences rather than ideal answers. What have you actually seen happen in startups?

We're building an AI healthcare receptionist platform that handles inbound patient calls, patient verification, appointment booking/rescheduling/cancellation, clinic FAQs, human call transfers, SMS notifications, call recordings, transcripts, AI summaries, analytics dashboards, audit logs, RBAC, multi-tenant support, and future EHR integrations. Outbound calling will be added later.

The deeper we get into the design, the more it feels like the difficult part isn't the LLM itself. It's conversation state management, tool execution, EHR integration, retries, human handoffs, observability, and keeping voice latency low enough that patients never notice delays.

One thing I'm struggling with is that different people are recommending different directions. For the platform and real-time voice side, many are recommending a TypeScript/Node.js stack (Next.js + NestJS). But when it comes to agent orchestration, conversation state, memory, retries, and workflow management, many are recommending Python with LangGraph.

So now I'm trying to figure out whether I should keep everything in Node.js, introduce a separate Python/LangGraph service, or choose a completely different approach.

If you were building this today, would you choose:

1. Node.js + NestJS
2. Python + FastAPI
3. Node.js + Python (LangGraph or similar)
4. Something else

More importantly, why?

We're building an AI healthcare receptionist platform that handles inbound patient calls, patient verification, appointment booking/rescheduling/cancellation, clinic FAQs, human call transfers, SMS notifications, call recordings, transcripts, AI summaries, analytics dashboards, audit logs, RBAC, multi-tenant support, and future EHR integrations. Outbound calling will be added later.

The deeper we get into the design, the more it feels like the difficult part isn't the LLM itself. It's conversation state management, tool execution, EHR integration, retries, human handoffs, observability, and keeping voice latency low enough that patients never notice delays.

One thing I'm struggling with is that different people are recommending different directions. For the platform and real-time voice side, many are recommending a TypeScript/Node.js stack (Next.js + NestJS). But when it comes to agent orchestration, conversation state, memory, retries, and workflow management, many are recommending Python with LangGraph.

So now I'm trying to figure out whether I should keep everything in Node.js, introduce a separate Python/LangGraph service, or choose a completely different approach.

If you were building this today, would you choose:

1. Node.js + NestJS
2. Python + FastAPI
3. Node.js + Python (LangGraph or similar)
4. Something else

More importantly, why?

I'm working on an internal healthcare product that uses AI to handle appointment booking, rescheduling, cancellations, and basic clinic inquiries.

Before jumping into implementation, I've been wondering how experienced engineers and architects actually approach a project from scratch.

My current thought process is:

• Understand the business workflow
• Create flow diagrams
• Identify edge cases and failure scenarios
• Create architecture diagrams
• Evaluate vendors and services
• Pick a tech stack
• Estimate traffic and scalability needs

But I'm not sure if this is the right order or if I'm missing important steps.

When you're starting a new project, how do you approach it?

Do you study existing products first?

Look at open-source implementations?

How do you decide what research is worth doing versus what can wait until implementation?

I'm less interested in specific technologies and more interested in understanding the thinking process that experienced engineers follow before building a system.

I'm working on an internal healthcare product that uses AI to handle appointment booking, rescheduling, cancellations, and basic clinic inquiries.

Before jumping into implementation, I've been wondering how experienced engineers and architects actually approach a project from scratch.

My current thought process is:

• Understand the business workflow
• Create flow diagrams
• Identify edge cases and failure scenarios
• Create architecture diagrams
• Evaluate vendors and services
• Pick a tech stack
• Estimate traffic and scalability needs

But I'm not sure if this is the right order or if I'm missing important steps.

When you're starting a new project, how do you approach it?

Do you study existing products first?

Look at open-source implementations?

How do you decide what research is worth doing versus what can wait until implementation?

I'm less interested in specific technologies and more interested in understanding the thinking process that experienced engineers follow before building a system.

If you received a good job opportunity in the US or Australia, would you move there? Do concerns about racism, discrimination, visa uncertainty, or feeling like an outsider influence your decision?

For those who have lived or worked there, how has your experience been? Was it better or worse than you expected?

I'm working on an internal hospital project where we're building an AI phone agent that can answer calls, collect patient information, book appointments, create tasks, and route requests to the right team.

From a developer's perspective, the idea feels almost too simple.

That's what worries me.

If it really is this straightforward, why isn't it already everywhere?

For people who've actually deployed systems like this in hospitals, clinics, or call centers, what were the problems that only showed up after going live?

What did you think would be easy but turned into a headache in production?

I’m from a development background and trying to move toward sales.

One thing I’m realizing is that getting real conversations is actually hard. Even getting one proper call takes a lot of outreach.

I don’t want AI roleplays or fake practice platforms. I want real human interaction and real conversations.

As a beginner, what’s the best/easiest way to practice this seriously?

Should I join a part-time role, small agency, outreach work, or something else?

I’m a founder running a small technical team. We build web apps, mobile apps, and AI based solutions for clients. Most of our work so far has come through referrals and connections, and we’re also trying outreach campaigns now.

But I’m wondering how other founders here actually got their early clients consistently without depending on their network.

What worked for you guys in the beginning?

https://preview.redd.it/f4lhkhg0cq2h1.png?width=1498&format=png&auto=webp&s=2bea195f041880c191b15b0714135030fd2d8eca

I’ve been planning to move into freelancing seriously and recently started exploring Dribbble because a lot of people recommend it for getting clients.

I have around 3+ years of frontend experience working with Next.js, React, Angular, Vue.js, and building modern UI/frontend systems. Since I wanted access to project briefs, I upgraded to the Standard plan thinking I could start applying and slowly get conversations going.

But after opening the briefs section, I honestly got discouraged.

I started seeing projects under $100 already having 20–30 submissions, sometimes even more. Seeing that many people competing for really small-budget projects made me feel like I’m walking into some kind of trap where beginners just keep applying endlessly without getting real opportunities.

Now I’m genuinely confused whether this is just the normal starting phase of freelancing, or if platforms like Dribbble are no longer realistic for someone trying to get their first few freelance clients.

Did anyone here actually get clients from Dribbble in their early days? Or does it only start working after building a reputation/network over time?

Would honestly love to hear real experiences instead of YouTube “freelancing guru” advice.

I’m completely new to sales and come from a developer background. Recently I started realizing that good sales/discovery calls are actually very structured and psychological rather than just “pitching a product.”

Things like:

• how to identify the real pain
• how to guide a discovery call
• how to drill deeper into problems layer by layer
• what kind of questions to ask
• how to avoid pitching too early

all seem like skills people learn over time.

I want to properly learn the fundamentals of this. Can anyone suggest a roadmap on where to start, what videos/books/frameworks helped you most, or how you learned this in real-world scenarios?

Also, is there any practical way to get real-time experience without joining a full-time sales job/company switch?

Manufacturing owners / operations people - honest question.

If a company offering ERP, workflow, or automation services reaches out through LinkedIn or cold email without visiting your facility first, what’s the first question or doubt that comes to your mind?

For example, one of my first thoughts would probably be:
“For a simple workflow, will these guys really charge this much?”

Interested to understand how people in manufacturing usually think about this.

Trying to reach manufacturing companies through email outreach to offer IT/workflow services, but I don’t want to burn money on expensive outbound tools initially.

Right now I only have 1 inbox and my goal is simple: book even 1 real appointment in the next 30 days just to validate the process before scaling properly.

This is the kind of email body I’m currently testing:

“Hi [Name],

Came across [Company Name] through LinkedIn and was going through your CNC machining and production operations.

I kept wondering how teams usually avoid over-ordering raw material when actual shop floor consumption and inventory numbers don’t fully match in real time.

Feels like a lot of working capital can quietly sit idle because of that uncertainty.

Worth a quick chat if this has been annoying lately.”

Totally okay if replies take 2–3 weeks. Looking for a lean/minimal-cost setup that actually works for manufacturing outreach in 2026.

Has anyone actually gotten clients/leads from manufacturing companies through LinkedIn, cold email, or calls without having strong industry connections?

Our ICP is around 50–100 employee manufacturing companies for IT support/services, but one of my friends told me that in manufacturing, only direct relationships and referrals work — cold outreach usually doesn’t.

Just trying to understand if this is realistically possible or if I’m chasing something unrealistic.

I want to help manufacturing companies with IT-related work and software support, but I’m trying to understand the practical side of how people usually connect with companies in this space.

Manufacturing seems very different compared to other industries when it comes to communication and relationship building.

If you’ve worked with manufacturing companies before, what’s usually the best way to reach out and start the first conversation? Phone calls, email, LinkedIn, referrals, something else?

Also, who is typically the first person you talk to inside the company?

Just trying to learn how things actually work in this industry from people with real experience.

I want to help manufacturing companies with IT-related work and software support, but I’m trying to understand the practical side of how people usually connect with companies in this space.

Manufacturing seems very different compared to other industries when it comes to communication and relationship building.

If you’ve worked with manufacturing companies before, what’s usually the best way to reach out and start the first conversation? Phone calls, email, LinkedIn, referrals, something else?

Also, who is typically the first person you talk to inside the company?

Just trying to learn how things actually work in this industry from people with real experience.