By Dmitry Yakovlev, Software Architect, DataArt
I was inspired to write this guide based on observations I made while collaborating with high-tech startups at early stages of development. Some of them succeeded in reaching their goals, some of them failed. The last thing that triggered this piece was a recent engagement with two ventures—one successful and one not—that happed at the same time. After reviewing and comparing what and how was done in both cases, I wanted to give a few recommendations to startups looking to outsource software development to an IT vendor.
Point #1: Hire a CTO, but don’t let him dictate the business
Before jumping into stormy waters of software outsourcing, make sure your team has someone technical enough to communicate with engineers. Ideally, this person will have experience in delivering software projects and will be a bridge between the world of business and the world of technicians—you’ll need someone who can speak both languages. Later, if the venture survives and decides to move software development and maintenance in-house, the CTO can form and lead an IT department with his first-hand knowledge of the system.
But be cautious! Technicians are too often obsessed with technological perfection and worry much less than needed about making profitable business decisions. Chasing one-for-all-time solutions leads to missed milestones, disappointed capitalists and running out of funds. Too many startups have invested tens of millions of dollars into technology and forgot to think enough about the minor details, like sales.
Bottom line: Having a CTO is essential for success, but business should have a priority over technology.
Point #2: Pick a vendor of matching size
Size does matter. An equal partnership is rarely possible between a huge IT vendor and a tiny venture, which will surely be underserved, will lack managerial attention and will have no leverage to demand it. From this point of view, picking a service provider of the same weight looks quite attractive as being a major client of such a small company assures a good position for pushing the vendor. However, there is an extra dimension to consider—financial. Startups, depending on their funding situation, tend to generate substantial account receivables in a vendor’s balance sheet (and they do so!). Such a debt can kill the small vendor and drive the venture itself out of business.
My recommendation is to consider vendors to whom you may bring a substantial but not critical amount of business.
Point #3: Consider culture and communication style
Startups are often run by two-to-four people whose schedule is rather random, while capacity to produce written functional requirements is limited. Such a lifestyle demands a development team to enjoy ‘lightweight’ communication with business stakeholders—occasional chats. A team that can’t accept such a style has slim chances to implement what their stakeholders are dreaming about.
Tolerating startups with their ever-changing wishes should be hardcoded into the culture of the vendor. The development team has to be easily able to handle constantly moving scope, unscheduled meetings, urgent requests after midnight, unexpected demos to investors, scrapping features implemented yesterday and fountains of new ideas incompatible with solution architecture. Quick turnaround time, initiative and creativity are really appreciated by startups (which in return should acknowledge that the team can also have an opinion, otherwise it won’t work).
My advice is to ensure you feel comfortable working with the vendor at a personal level and to build good relationships with key team members while negotiating contract terms.
Point #4: Never ever go with a fixed price contract
One of the most devastating mistakes a startup can make is to push a vendor for a fixed price (implying fixed scope) contract. Led by illusion of risk-safe engagement, such a startup spends many months in an attempt to define the scope of the project detailed enough to generate a quote. The problem is that the scope expires as soon as it was quoted, so both parties get into an endless cycle of adjusting the terms of the contract. In many cases, a vendor cuts the process as it has better ways of utilizing resources. But even when such a fixed price contract is signed, soon after the implementation begins the startup realizes it’s caged by the original scope as the cost of amending the contract is often prohibitive.
What startups really need is a dedicated team working on a time and materials basis. Not bound to any predefined scope, the venture can play with the requirements to build a solution that really works. In the beginning of the article, I mentioned two recent engagements we had with startups. The first one spent four months negotiating a fixed-price contract, got alienated with the team, went to another vendor and came back in two months, but nobody in the team wanted to start the process again. By that time, the second startup had built a strong dedicated team and managed to deliver a working prototype which they demonstrated to investors.
The lesson: Keep your options open and remember that your main competitor is time.
Point #5: Avoid outsourcing to multiple vendors
Vendor lock-in is a fair concern for companies outsourcing critical parts of their business. While mature companies mitigate such a risk via portfolio of vendors doing similar jobs, this approach might not work so well for startups. Being a small company, a startup is hardly capable of carrying the burden of managing even a couple of vendors due to increased complexity of communications, blurred responsibility, competition between the providers, and a lot of politics on top of that. A more practical approach for young businesses is to gradually transfer knowledge and responsibilities to the in-house team (another reason to have a CTO). Once the project is delivered, it’s perfectly ok for a vendor to pass maintenance to the client; discussing such a perspective with the vendor from the very beginning will help to smooth the process.
There are cases when having several vendors is inevitable, e.g. each having specific expertise (say, business intelligence or mobile apps). Supporting such a configuration is easier for the venture as each vendor has a niche.
Recommendation: Start with just one vendor and accumulate knowledge in-house.
Afterword
All the points given above are a biased view of a technician whose mind is damaged by a decade of providing software development services to a variety of clients, many of which happened to be startups.
# # #
Dmitry joined DataArt in 2003 as a software developer, and has been instrumental in building the company’s online travel technology solutions practice which he currently leads. He’s a recognized expert in designing online booking engines, inventory management and content management systems for the travel industry. He contributed to expanding the travel and hospitality practice by 50 percent in 2008, and has worked on all key accounts in the space. Prior to joining DataArt, Dmitry worked for academic institutions and research centers as a researcher. He holds a MS in Chemistry and a Ph.D in Quantum Chemistry from St. Petersburg State University (Russia).
