u/Competitive_Long509

I've been working on supplier selection for a new project over the past couple of weeks. Instead of just collecting a few quotes, i tried to build a proper comparison.Production capacity, quality systems, technical capability, lead times, communication, past projects, certifications, ownership structure, potential risks.

I even organized everything into a comparison matrix so management could clearly see the strengths and weaknesses of each supplier. To make it easier, i also used a few sourcing tools, including Alibaba, SourceReady, Thomasnet, Global Sources, and even some internal ERP and supplier databases, alongside our internal records to compare supplier capabilities and keep all the notes in one place. After everything was scored, one supplier stood out pretty clearly. They weren't perfect. Their price was slightly higher than the others. But their responses were consistent. Their technical team answered questions directly. Their production capability was well documented. Overall they simply looked like the lowest-risk option. My thinking was pretty simple. This project is important enough that paying a small premium is worth avoiding larger problems later.

Then the final management meeting happened. The supplier that got approved wasn't the one i recommended. It was another supplier that everyone already knew had a few obvious weaknesses. The deciding factor? They were cheaper. That's it. Now i'm sitting here looking at my comparison spreadsheet wondering why i spent so much time evaluating supplier risk when price ended up outweighing everything else. Maybe it'll work out. I honestly hope it does.

But i can already imagine the conversations we'll probably be having a few months from now if those known issues start becoming real problems. For those who've been in procurement longer...

Sharing a small thing that made my MCP work less painful. Early on I had each tool sort of aware of which model was driving it, because different models needed slightly different prompting and I was passing provider specific stuff through. It worked but it was tangled.

The shift was treating the model side and the tool side as fully separate. The MCP servers just expose tools and don't know or care what's on the other end. Model selection happens one layer up, so I can point a client at a cheap model for routine tool calls and a stronger one for planning without touching any server code.

What still bites me is schema consistency. Had a cheap model return a tool call with the argument name slightly off (something like file_path vs filepath, can't remember exactly) and the server rejected it. A stricter system prompt mostly papers over it but you still end up testing per model.

If anyone has cleaner ways to keep client-side flexibility without leaking model quirks back into tool definitions, share them. Mine still feels held together with prompt tape.

Wanted to share a mistake that still makes me cringe when i think about it. A few months ago, we placed an order for 5,000 units of a product after going through the normal sample approval process. The sample looked great. Everyone agreed on the color. We exchanged messages with the supplier. They confirmed they understood what we wanted. Everything seemed straightforward. Then the production order arrived. And the color was completely different. Not slightly different. Not something only a designer would notice. Completely different.

When we pushed back, the supplier's response was basically: "it's the same product." , "the color variation is acceptable.", "this is normal production.", we argued back and forth for weeks. Eventually i realized something painful. The problem wasn't just the supplier. The problem was us. We had relied on chat messages and verbal confirmations during the sample stage. We never formally specified: exact pantone color codes, approved color references, product photos attached to the contract, acceptable color tolerances.

Everyone thought we were talking about the same thing. Apparently we weren't. Once i reviewed the paperwork, i realized how weak our position actually was. The supplier wasn't technically violating anything that had been written down. They were violating expectations. And expectations don't hold up very well in disputes. Since then i've become much more obsessive about documentation.

If a color matters, it goes into the contract, if an appearance detail matters, it goes into the contract, if a sample matters, photos get attached to the contract. Our team has also started organizing supplier communications and approval records much more carefully. tools have helped us keep supplier notes, product specifications, and sourcing history in one place, which makes it easier to verify exactly what was agreed upon before production starts. Expensive lesson.

Hopefully someone else can learn it the cheap way. Has anyone else had a supplier dispute where the real problem turned out to be missing details in the contract rather than the supplier itself?

When i first started learning procurement, the process sounded very logical.

Receive a request, understand the requirement, find and evaluate suppliers, compare options and negotiate, select a supplier. Honestly, it sounded like a very structured and professional process. Then i started working. And suddenly the process became: "we need this urgently." "how fast can you get it?" "can we have it by next week?" "actually, can we have it by friday?" Sometimes the request arrives so late that people are already discussing delivery dates before supplier research has even started. The reality is that many sourcing activities get compressed into incredibly short timelines. Market research gets compressed.

Supplier discovery gets compressed. Quotation rounds get compressed. Stakeholder discussions get compressed. Everything gets compressed. Except for one thing: risk.

Because even when timelines are unrealistic, the due diligence still has to happen.

supplier qualification still matters. Production capability still matters. Financial stability still matters. Quality systems still matter. And figuring out whether you're talking to an actual manufacturer or a second-layer trading company still matters.

Nobody wants to hear: "We skipped supplier validation because the project was urgent." Especially after something goes wrong. One thing i've learned is that urgency doesn't eliminate procurement responsibilities. It just makes them harder to execute properly.

I'm curious whether others have experienced the same gap between procurement theory and procurement reality. How do you balance: "we need it immediately" with "we still need to do this properly"

Recently, while working on product development and supplier selection, I realized there's a challenge that's even harder than finding suppliers. It's figuring out what type of company a supplier actually is. Many founders run into this situation when searching for manufacturing partners:

The supplier claims to be a factory. Their website highlights advanced equipment and production lines. The sales team seems knowledgeable about the products.

But after digging deeper, you discover they're primarily a trading company. To be clear, I don't think trading companies are automatically bad. For early-stage startups, some trading companies can actually provide valuable sourcing and coordination support. Especially when you're sourcing multiple product categories or placing smaller orders. The problem is that if you believe you're working directly with a factory, many of your decisions may be based on incorrect assumptions. For example:

Misjudging cost structure and margins. Longer product development timelines

Slower technical communication. Less clarity when quality issues arise. After a few painful lessons, I've started paying much closer attention to supplier verification.

Currently, I focus on several areas: Can they clearly explain their manufacturing process? Can they provide specific information about equipment and capacity? Can they answer technical questions quickly? Can you communicate directly with engineering teams? Which products do they manufacture themselves, and which are outsourced? I've also found that communication patterns reveal a lot.

For example: Every technical question requires them to "check with the factory."

Answers about manufacturing details remain vague. They can discuss sales well but struggle to discuss production processes. These are often signals worth investigating further.

Recently I've been trying to build a more structured supplier research process.

Once the number of potential suppliers grows, important details can easily get lost. I've been using LinkedIn, ImportYeti, company registration databases, and SourceReady to cross-check supplier information and keep research organized.

Even then, I don't think there's a perfect method. I'd love to hear from other founders:

How do you typically distinguish between: Actual manufacturers. Trading companies. Trading companies presenting themselves as manufacturers. And what are the biggest red flags you've learned to watch for over the years?

Ran a leak scanner, caught my DNS resolving through my ISP even with my VPN connected. Firefox's network.trr.mode was set to 2, "use DoH first but fall back to system resolver." So every DoH failure sent the query out my real connection, cleartext. Resolver came back as Comcast (AS7922) when I was supposed to be exiting in NL.

Setting network.trr.mode to 3 fixed it. DoH only, no fallback.

WebRTC was fine this time. What got me was that I'd been running like this for weeks. Every IP checker said the VPN was working, but none of them check whether your DNS resolver actually matches your exit country or ASN. That's a completely different test and most common sites skip it.