If outsourcing your drawings left you with more questions than answers, you’re not wrong to be skeptical. But it usually wasn’t the idea that failed, it was the way it was done.

---

Years ago, as the engineering manager for a $30-million-a-year millwork company, I wrote a letter to my company president laying out exactly why we should never outsource drawings again.

I meant every word of it. We’d been burned. The results were bad, the process was full of friction, and the drawings we got back weren’t buildable. My engineering team ended up with more questions than answers, redoing everything from scratch and wishing the project had never left the building in the first place.

So if you’ve been through that, I’m not going to tell you your skepticism is misplaced. I had it too. I now run an outsourcing company precisely because of that experience, and everything about how we work was built to prevent the exact pain that made me write that letter. Here’s what I’ve learned about why outsourcing goes bad, and how you tell the difference before you get burned again.

Why it actually goes wrong

It starts with no real onboarding. The number-one reason outsourcing fails is a lack of clear communication and onboarding up front. Anyone who’s going to draft for a millwork shop has to start by gathering context on how you build and how you draft, your title blocks and CAD templates, your layers and model-space organization, and the way you make decisions about the detailed construction of your work. All of that matters. A partner who skips it is guessing, and you’ll pay for the guesses later.

And here’s the uncomfortable part, a lot of it is the shop’s side of the table. It is impossible for a partner to deliver accurate, complete drawings if the client can’t define what “accurate and complete” even means for them. It happens constantly: a shop hands off a project, gives us their CAD templates and even their Microvellum library, we get on a call and ask the questions we need to start, and we hear, “well, it depends on the job how we’d detail that kind of cabinet… I’ll have to ask someone who isn’t on this call.” Or we get a vague answer, follow it exactly, and then get told later that it was wrong, or to just “draw it how you think.” No partner on earth can win that game.

Then there’s the generalist trap. Hiring a CAD generalist gets you quick, cheap drawings that might get you approvals. But they leave you with a pile of unanswered questions, the kind your engineers or production team have to chase down late in the game, asking the client for answers when they should already be fabricating.

Which leads to the half-a-job handoff. Too many shops end up accepting CAD-only drawings just to keep the project moving, which means they’re redrawing everything in their CAM software late in the schedule anyway. You outsourced the work and still did it twice.

And even the “safe” option has a catch. A lot of shops fall back on individual freelancers, often an engineer or drafter who used to work for them full-time and went remote. They’re familiar and they do good work. But they’ve got very limited capacity, they tend to do things their own way, and they don’t keep up with your company as it evolves. It works right up until it doesn’t scale.

Red flags and green flags

If you’re going to try again, here’s how I’d vet a partner so you don’t repeat the experience.

Red flags:

• They don’t work when you work. A 12-hour time difference sounds great in theory, someone drafting while you sleep. In practice, you lose a full day for every question or correction that needs coordination, and that adds up fast. When you can’t hop on a quick call to answer a question in real time, your schedule pays for it.
• They don’t work in your core software. If your partner isn’t native in Microvellum, Cabinet Vision, or Mozaik, whatever you run, you’re going to do the work twice.
• There’s a middleman between you and the drafter. If you can’t talk directly to the person actually doing your drawings, information gets lost in translation.

Green flags, and these aren’t just the opposite of the red flags:

• A technical expert who speaks your engineer’s language. Your partner should know your software as well as you do, if not better. Microvellum, Cabinet Vision, AutoCAD, whatever you run, you need people you don’t have to teach the basics to before you can even get started. If your engineer can talk shop with theirs and be understood, that’s a great sign.
• Real industry experience. The best partner is someone who has actually been in your shoes, who has faced the exact problems you’re facing right now, firsthand, not just as an outside service provider reading off a checklist.
• Trust you can feel after one conversation. This one’s a gut check, and it matters more than people admit. If you get off the intro call, or your very first interaction, and you still aren’t sure you’d confidently hand them your project and count on them as part of your delivery team, then they aren’t the right partner. Full stop.

How burned shops come back around

We’ve worked with a lot of clients who got burned so badly they went years refusing to outsource anything. Most of them came to us by referral, from other clients who told them what a different experience looked like.

When they do, we don’t start with drawings. We start by understanding their current processes, their drafting standards, and how they build. We run them through our established onboarding process to document those standards, then kick off with clear scope and real decisions about how to organize and detail every scope item, not “we’ll figure it out as we go.” And we prove it in small pieces: we start with a single deliverable and quick wins, so everyone can confirm we’re on track before we go wide. That’s how you rebuild trust that a bad experience destroyed.

The hard truth

Sometimes it isn’t the vendor. We’ve had plenty of shops that simply aren’t a fit for outsourcing, yet. Either their standards live entirely in one person’s head and were never written down, or they don’t really have standards at all that we can document into logical decision trees.

If everything you draw has to be articulated and decided case-by-case by a single individual, someone who isn’t available, or can’t put into words how they make those calls, then no partner can be efficient or add real value. That’s not an outsourcing problem. That’s a documentation problem, and it’s the first thing to fix, whether the work goes out the door or stays in it.

The bottom line

Getting burned by outsourcing isn’t proof that outsourcing doesn’t work. Usually it’s proof it was done wrong, no onboarding, undefined standards, a generalist who didn’t know millwork, a time zone that cost you a day per question, or a drawing that was never going to be buildable.

I wrote the letter. I lived the pain. And then I built the company I wished I’d had on the other end of that project. If you’ve been burned before, the goal isn’t to talk you into trying again, it’s to make sure that if you do, it’s built to work this time.