Search

What to have in mind before giving away equity to a tech partner




Many startups will at some point in their journey be looking for a software development company to support their growth. However, the market for such services is very crowded with hundreds of vendors to choose from. It is a challenge to know whom you can trust and even harder to know which vendors to pick and how to ensure a successful collaboration. Just because there are many vendors out there saying they are ready to work with your startup doesn’t mean that all of them are willing or able to work in a way that will actually help your startup succeed. In many cases, consultants and development houses can actually do the opposite by bleeding a startup dry with their hourly fees and greedy behavior.


To avoid this fate the most important thing to consider when choosing any partner is to have their interests aligned with yours. Not only must you find a vendor that will deliver the development work you need, but it should be someone that does this in a way that accelerates your business and helps you succeed over the long term rather than just extracting billable hours from you. This is especially important when your startup is paying for the development in equity shares of the company rather than by paying hourly rates. You need to remember that you are then paying for the service with part of your future value, so if you eventually succeed then any bad deliveries along the way can turn out to have been really expensive!


One big problem that a lot of startups run into is that they agree to pay a fixed amount of shares in exchange for delivering a platform according to a defined specification. While it might appear that this will give the development house an incentive to do good work, in reality, a lot of vendors will see this as a short term business deal instead of a partnership and will just try to get their shares quickly by cutting any corners they can to get the software delivered, often using junior developers and reading the specification like a devil’s advocate. This means that under the hood what gets delivered will be a mess of duct tape and chewing gum that will be impossible to maintain and improve in the future.


Even as they get paid in shares of your success they actually have no direct interest in adding value to your company; they will just want to get the shares as cheaply as possible. It doesn’t really matter that the shares will be worthless if your startup fails, because for them it is probably just a small stake in one of many startups. Essentially they are betting that you will work really hard to add value to the company later despite their sloppy work, because no matter how bad their work was you will have a lot more to lose on a failure than they do.


What you want to do instead is to make an effort from the beginning to build a real partnership by ensuring that the vendor gets equity only if they actually help you succeed.


One way to do this while balancing both of your interests is to use a milestone-based equity approach and specify clearly how the milestones should be evaluated and what quality is expected. Since evaluating technology is hard, then using milestones based on pure technology deliverables can often land you in the same mess as above. Instead, a key success factor is that the milestones should primarily be business based instead of technology-based.


Another important element is to plan for a long-term relationship so that the partner can be incentivized to actually make the startup thrive instead of just delivering a technology platform according to spec and then moving on to the next contract. To do this you might need to give away a large piece of equity to the partner over a long period of time, but when this is paid according to business milestones then the cost in equity will always be value-based and in a way that keeps the vendor invested and engaged in delivering quality without you having to care about the amount of developer time spent.


So what kind of business-based milestones would make sense to use for a technology partner?

Actually, that would be most of the business milestones that you should already have for the startup itself, especially those related to customer onboarding like the following:

  • Core milestone: Delivering a working MVP prototype of the system for doing sales demonstrations and successfully onboarding the first beta-users(s) into a functioning end-to-end flow of your primary service.

  • Secondary milestones for onboarding beta-users onto new integrations or new modules that enable sales to customers in new categories or with different needs.

  • Tertiary milestones for upgrading beta-users to become paying customers of modules that have been developed to the point where they are considered fully functional and no longer in beta.

  • Future milestones: Deploying working and fully functional integrations to other systems that are important for internal business efficiency in your startup, for example, automated accounting/ERP, CRM/service-management tools, etc.

From these initial semi-technical milestones you can then move the partner further and further into pure business goals so that they can work independently and proactively on the system to make improvements that will give you value. Setting a milestone for getting 100 (or 100k) users will for instance give the partner a vested interest in making sales and onboarding processes work smoothly while setting a financial milestone based on revenue instead would get them more invested in increasing paid usage and paid time spent on the service.


As you can see from these examples a real partner doesn’t get their equity just because a part of the software has been developed or even deployed to production, but only when business goals are met such as having actual users starting to make use of the software. This ensures that the partner is not only incentivized to deliver the code, but also to ensure that onboarding processes are working smoothly and that the functionality works as expected. They might even reach out to their own network to assist with sales if this helps them reach their milestones!

This also creates a framework for building an ongoing relationship with the partner as the startup grows far into the future, which incentivizes the vendor to deliver maintainable quality code as they themselves might be working on improving their own deliveries for many years.


What is your experience as a startup in partnering with software vendors?


Let us know if you need help connecting to software companies at raja@mytheia.com or via our website. We can advise you along the way and connect you to our vetted network of partners.



About the Author:

Svein-Magnus Sørensen is an experienced software architect and has been working as a software consultant for more than 15 years. He is one of THEIA's advisors and he is currently employed as a Managing Architect in Netcompay. Throughout his career, he has been involved with several startups both as an employee, advisor, vendor, and investor, and this is his best advice on what works for a small startup that is looking for a development partner to actually help them succeed.



51 views0 comments

Recent Posts

See All