Finding A Tech Co-Founder

Finding a tech co-founder is hard and pre-assumed to be the first step in building a startup/project when it comes way down the order.

Always deliver more than expected

Larry Page

Having done dozens of side projects and collaborated with multiple non-tech and tech (web development in this context). I have come to an understanding of what building a tech project is and is not.

Every firm today is a tech and data-driven firm. This goes without saying in today’s world. Despite the ubiquitous nature of tech, it’s weird that non-techies find it hard to reach out to tech folks and make things work.

In today’s age, when building the product in a bootstrap fashion, the non-tech folks need to go beyond a mere idea and come back with valid data to convince the tech co-founder to work together. You must validate the market and provide the evidence before the specific tech founder.

• Jobs and Wozniak met at a hacker group for computer nerds.
• There was a defined and specific need for an integrated computer system.
• Collaborated first to build the prototype.

Source

Doing this exercise as such will allow one to do both the homework and, at the same time, save valuable time in terms of figuring out what to build. Once you define the problem, you can find your tech guy by hanging out in forums, conferences or groups which solve or revolve around the problem-solution space.

Customer -> Problem Statement

Even though all firms and businesses are tech-driven, the initiation starts with business and primarily starts with the customer in mind. 90% of my dozen side projects failed because of not start with the customer in mind. By simply doing this, one can avoid building something without need.

IMHO, All great ideas start from a deep understanding of the specific customer base and their problems. Start with the single pain point instead of trying to solve 4-5 issues on the one go.

Post getting a good understanding and a belief that we have a probable use case, the next thing to look for is a well-defined problem statement with clear specifics. This helps us frame the problem as a hypothesis we can validate.

Problem Statement -> Community/(User Research)

Post an understanding of the problem statement and customer. The next step is to build a small community of users or join them. This can be executed as a user research exercise, where one talks to multiple users (possibly 100+). Not sure how to reach the first set of 100+ users? You gotta fix this problem first.

This helps solve a couple of problems:

• Is the pain point genuine and an actual issue for several users?
• How can one go about reaching out to them?
• A ready-made user list to test out the beta version of the product.

Just carrying out this much of an exercise allows one to quickly validate key aspects of the problem statement and the distribution. This 100+ user base is necessary to ensure you build the right thing. This cannot be emphasized enough. Read this book on how to talk to users.

User Research -> Finding a Tech Co-Founder.

This is the phase where one can finally find the tech co-founder. Given that we have a problem statement and an understanding of the first 100+ users. We know what a working solution will look like.

The next step to do post this would be to write a document compiling and putting together all this information in the form of a HEEL.

• You had a hypothesis/idea with a specific customer in mind.
• You ran an experiment (user research) by talking to these users.
• Understood the experience post this
• Took your learning from the entire experience.

The next great idea is to go beyond this and use a no-code tool to quickly put together a hack app using a no-code tool like Glide. This basic tool for all concepts/items within a GMAT exam counters the number of times the concept came up.

The amazing part of these tools is that despite being very simple, they will expose the non-tech folks to an understanding of what an app solution will look like.

All basic apps are, in some form, a type of CRUD.

• Create
• Read
• Update
• Delete

The App above uses an Excel/google sheet at the backend. All the list does is either create an entry, read it to display, update the counter and finally delete an item/concept from the list.

While this has limited functionality, taking this to users and getting feedback will help them understand what this lacks and the specifics on what to improve going forward.

For a more complicated product/functionality. Go out and spin out a Figma UX flow. While a functioning product, we close the loop on what the flow and working solution might look like.

This also helps build empathy with the tech co-founder when building the product.

Reaching Out

Now that we have done our homework survived the tough challenge of user feedback, and built the design prototype. It’s time to reach out to the other end of the problem, reaching out and convincing a good tech guy.

Our job is a little easier now, given that we have done some groundwork and should be quickly able to provide all evidence/data for our idea. This ensures we reduce the number of reasons why someone can reject us. The pitch becomes a lot more clean/smooth.

• The basic idea is not up to their alley.
• The data/evidence is not sufficient.
• The tech stack needed is not relevant or of interest to them etc.

Based on the feedback and the plausible tech stack, we can iterate over the idea or try to collect further information.

What are the exact places to find these people?

• Public/Open Hackathons
• Developer Oriented Forums (Reddit/Hacker-news) specific to the problem
• Open Source Projects (Github) about the problem.
• Product Hunt Makers
• Ask a friend, refer to peeps.

Though these are all decent places to start people, try to see if you can get someone you have studied or worked with together. Despite covering all these basics, there are multiple other ways things can go wrong.

• Your working styles are different.
• The developer is not synced with the required tech stack.
• They are not motivated enough.

And so on…

What do you do when one of these happens? Rinse and repeat. Figure out the issues and iterate by solving the specific problems. You should be able to improve your odds of succeeding.

If you are clear, have gone through this exercise, and are still looking for some developers. You could drop a note below, and I might be able to introduce you to some interesting folks as well.