Here’s a common scenario: a non-technical founder wants to build a technical product. All advice comes down to three basic options:

• Learn to code
• Hire a dev shop 
• Find a technical co-founder

These three options aren’t mutually exclusive. You can learn to code so that you can collaborate better with developers. You can find a technical co-founder who can help vet dev shops. While learning to code takes time and partnering with a technical co-founder is easier said than done, both options are generally good advice for getting started.

However, some people say that those two options are the only path forward. They warn against even considering a dev shop if you’re non-technical. The dev shop will rob you blind. They will keep your code hostage while finding all sorts of ways to keep charging you. They won’t care about the code quality. Their incentives run counter to yours. You won’t have any way of verifying whether they know what they’re doing.

Dev shop horror stories exist, but I don’t think we need to throw out the baby with the bath water. Ideally, you know something about software development or have a technical co-founder, but you can also wait years for the ideal scenario to come together. Finding a technical co-founder who you mesh well with is no easy feat. Keeping that relationship strong is unimaginably hard. While there are thousands of React tutorials and ChatGPT can be a useful crutch, developing an understanding of software architecture and design patterns takes years of experience.

If you’re non-technical, you shouldn’t rule out working with a dev shop, but you should have a strategy for vetting them.

Get to know whoever is in charge

You want technical ability, accountability, and good communication out of the dev shop. If you’re non-technical, you might not be able to tease out the first of those, but you can get a sense for the other two. How is the communication with the dev shop prior to hiring them? Are they helpful? Do you enjoy talking with them? Are they transparent? First impressions matter. If you’re just being funneled through their sales team and not getting a sense of who will actually be working on your project, it’s generally not a good sign.

Start small

Dev shops are used to scoping work. If they’re already at capacity, they might not jump at the prospect of a small engagement, but it’s worth checking. Can they work with you on defining a project that is small enough that it doesn’t break the bank but still provides value and insight into how they work?

Listen for no

Overpromising is a huge red flag. You’re at a disadvantage since it’s hard for you to get a sense of realistic scope, complexity, and cost. Even seemingly small projects involve constant communication, resolving unexpected technical issues, and learning new tech (APIs, etc). It’s easy to get carried away with ideas. An honest, experienced dev shop should caution you and manage expectations.

Meet the team

You will most likely have a primary point of contact in a product manager or even tech lead, but you shouldn’t be cut off from the rest of the dev team. The dev shop should keep you informed about who is doing the work and team members should be available to you.

Ownership

The codebase, hosting, and all intellectual property should be in your name and under your control from the outset (contingent on payment being made). As long as you're paying invoices on time, the code is yours. If the dev shop isn't clear about ownership and access, you should proceed with caution.

Testimonials and case studies

A common tip is to check out the dev shop’s testimonials and case studies, but these are easily cherry picked out of their portfolio of work. No one talks about the projects where they failed. However, if you have a good gut feeling about the dev shop, they provide social proof that can help validate your decision. You can always contact these past clients directly for unfiltered feedback about their experience.

Your best bet is to ask your network for dev shop recommendations. But focus on recommendations based on firsthand experience from people who you know and whose judgment you trust.

The dev shop's soft skills

Without technical knowledge, you will need to rely on your ability to assess the dev shop’s soft skills. Look for early signs of them being responsive, ethical, and competent in running a company. Many projects fail from bad faith players or poorly run businesses. Avoiding a dev shop with any hint of these issues will be just as important, potentially even more, than being technical.