by SankalpIn the technical world, non-technical founders risk being seen as unqualified especially when dealing with matters related to technology. While there are many success stories of tech founders ( Google. Facebook, Amazon), there are also other companies which have succeeded without techie founders. Take the case of former English teacher Jack Ma & Alibaba; neuroscientist Rashmi Sinha who founded SlideShare, and product design student Evan Spiegel who created Snapchat.
When working with technology partners, you need to keep in mind that the success of a project depends more on you as funder than vendor. You need to be clear in your head. Ideas are seldom clear in the first go, they need multiple iterations to be finalized. As a founder remember you have an idea but it is not concrete so do not lose patience, on the other hand if a vendor informs he has understood everything after the first discussion, just walk away.
You should further educate yourself on concepts like waterfall, agile, risk
With this basic understanding that explains some aspects of being a successful founder let us get into top aspects to watch out for when looking for a technology partner.
#1. Own your source code, email and environments
Source code is your intellectual property and should remain with you. You as founder need to have complete control over it and be an administrator of the same, this allows you to change vendors at will remove access and be in absolute control. Similarly own the hardware, domain names (read website names), certificates(SSL) and others. These items and more should be paid by your credit cards and you should have commercial rights on them just as you would have on any trade mark.
Beware of deals too good to be true, avoid vendors who say they will manage and own everything in a package, these deals eventually milk you.
Further ensure you are the administrator on all these systems and your email id is the primary email on these systems. Amazon provides free hosting for small size environments for a year, this can reduce costs
Ensure you sign a contract along with a handshake and those clearly spell out that items like source code, environments etc will be your IP.
Readup on github, jira, godaddy, amazon AWS.
Go informed, go smart in discussions.
#2. Evaluate multiple technology options
“When the only tool you have is a hammer then all problem look like nails”
Technology is just a tool and you need to ensure your craftsman knows how to use more than one tool. Run away from shops that insist that there exists only one option for development. Ask for technology options, understand the design choices and short term and long term benefits and costs of each option along with risks.
You may not understand all the options but you could judge if the vendor does. Individuals who are one technology shops often fail in their projects, this is because may not use the best tool for the job.
Right choice of technology goes a long way to success.
#3. Steer away from WordPress, Magento & other in the box vendors
Ask yourself a basic question, as a startup are you not challenging the models of business, are you not building something new and something never done before? If that is true why would existing software and technologies work for you.
This would imply heavy customization and unintended use of these platforms will be done and will lead to issues down the line.
It should be understood vendors who are incompetent building a solution from scratch and rely upon prepackaged solutions will not be able to run with you to new horizons.
#4. Understand commercial models
There exist various models of execution such as fixed bid where scope is fixed and risks are owned by vendor and time and material bid where you buy hours to get the job done. Ask for commercial proposals for both. It needs to be understood that software development is an art and contains many risks. Fixed big costs also incorporate cost of the risks a vendor who doesn’t understand these models and there differences has no experience in building systems.
#5. Fortnightly demos and define payment milestones
Once you are in a stage where scope is closed insist on a plan that allows fortnightly deliverables that may be demoed and be available for you to test. This will allow you to have private beta starting early on rather than something coming up later. This will also also allow you to give feedback and learn. Once these fortnightly sprints are tied to costing, pay up when the deliveries are met.
#6. Demand to understand project risks and issues on a weekly basis
Projects don’t slip by a month on last day, they slip one day at a time. This is a principle we have lived by. We have further learnt risks and issues when managed in time can have minimal impact on a project. Finally all projects have risks and issues, it’s just a question of managing them. Have risk and issues meetings every week this will allow finding and resolving them early on. If a vendor is not raising concerns then perhaps they are not managing them.
#7. Build a QA practice and tie payment milestones to them
Learn more about QA practices and learn to define bug priority. Insist on acceptance criteria based on bugs and have the vendor stick to them. Tie fortnightly payment milestones to the said acceptance criteria. This will ensure you have a greater predictability on product delivery.
#8. Have the team work from your site
Close collaboration is key to success, inistit that team works from your office with you.
#9. Estimate the project yourself
Instead of thinking prices are too high try an estimation exercise. Insist on detailed proposals and time taken for project with number of team members and their experience and skills. Then go find salaries of said people with given experience. Do a calculation and add a profit markup. If the vendor is not earning a decent profit they will not deliver your project.