5-Step Process to Pick The Right Tech Vendor For Your Business
“We stand on the brink of a technological revolution that will fundamentally alter the way we live, work, and relate to one another. In its scale, scope, and complexity, the transformation will be unlike anything humankind has experienced before.” — World Economic Forum.
Digital Transformation is inevitable. Forbes reported that 70% of companies either have a digital transformation strategy in place or are working on one. 55% of startups have adopted a digital business strategy compared to 38% of traditional companies. The top industries for digital-first business strategies are services (95%), financial services (93%) and healthcare (92%).
The pandemic is currently propelling startups and traditional companies towards the digital shift at an unprecedented rate. As per an IFS study, 70% of businesses have either increased or maintained their spending on digital transformation.
While incumbents and existing businesses are ramping up their resources and operations, small companies and startups are turning to technology vendors to help them set up a website, develop an app or build a product to streamline their operations and offer services to customers.
We are moving towards the digital age and, to become a part of this tide, we must embrace systems and processes that make our transition easier. Thinking, planning and building digitally will set us up to be agile, flexible, and ready to grow.
Choosing a tech vendor who understands the needs of your business and who you can trust can be a challenging task. A nice-looking, user-friendly and fast product amounts to only half the success. On top of that, time is costly. Not launching your tech element at the right time will cost you immensely. You have to make faster decisions that are objective and explainable with preferably just one factor — a score.
Before I get into the main crux of this story, here’s a brief introduction. I’m Diksha Bathula, and I’m a Product Consultant for Alacriti. As part of a recent project, my team had an opportunity to work with a client to evaluate a few tech vendors as per their business requirements.
This article is a summary of the processes we undertook to arrive at a final decision. Our approach was seemingly simple. We wanted to assess the vendors fairly and objectively, and the best way to do that was to evaluate them based on scores.
Evaluation of tech vendors has been a topic of discussion for a long time now. Though there is a lot of valuable content out there which can help you make the right decision, I’m hoping that this article will help you back your choice with objective observation and analysis.
I have structured the rest of the article into five sections:
- Drafting Goals and Needs
- Meetings with Potential Vendors
- Vendor Evaluation Framework
- Scoring Template
- Final Decision-Making Process
No matter the kind of product you are looking to outsource to a tech vendor, the framework in this article will help you navigate through different vendor proposals while placing a great emphasis on adhering to an unbiased and fair evaluation.
So, let’s dive right in.
1. Drafting Goals and Needs
As a company that is looking to outsource development to tech vendors, I’m sure you have a good idea about what your product should be, what it should look like and what it must achieve. A good practice would be to turn your ideas into a product specifications document (product-specs doc) that you can share with your prospective vendors and iterate on if required.
The product-specs doc must be catered entirely to your company and in a detailed manner, reflect the conversations you’ve had with your team. You have to be sure about the goals you set for the product and clearly define your needs and requirements to your vendors.
Pay attention to the details. Start by outlining the purpose of the product, your target audience, the kind of features you’d want to see in the product, any references to external websites or platforms, and finish it off with a rough sketch of your product roadmap.
Do not be afraid to be too specific. The more detail you provide, the easier it will be for both of you to get on the same page.
Drafting your goals and needs has a two-fold advantage —
- You will understand if your goals align with vendor opportunities and start to see a clear, if not a complete picture about what you are looking for
- You will allow your potential vendors to get a better understanding of your expectations and assess their capability of building the product for you.
2. Meetings with Potential Vendors
After drafting your goals and needs, it’s time to hit up Google. Research, learn and review about your vendor and their proposals before setting up a meeting with them. I can’t stress this enough as this helps both you and your vendor to understand your requirements in-depth, clarify any conflicts or doubts you have and move ahead with clarity. Thorough due diligence minimizes your risk of picking the wrong vendor.
Since time is crucial, try to use it wisely. Companies usually find themselves in a limbo where they are spending countless hours meeting with numerous vendors and getting nowhere. It is vital to keep the aspect of time in mind and realize that you don’t need to have more than three meetings with all of your potential vendors to choose the right one.
Meeting 1 — Reach out and share your product specs document
In your very first meeting with a potential vendor, reach out to them via text, email or a phone call. The aim of this meeting is simple — introduce yourself, tell them what you are looking for, share your product specs document with them and ask them to revert to you with a product proposal. Some vendors may also request a walkthrough session with you to make sure they understand all of your product requirements before they start working on a proposal.
Meeting 2 — Understand the vendor’s product proposal.
Once you receive a proposal from your vendors, go over it carefully and ask yourself a few questions — Do you see your own goals and needs reflected in the text of the proposal? Can you relate with the picture that the vendor has painted for you? Is there a path charted from A to B in a way that makes sense for your company and takes you where you’d like to be?
You can also set up a meeting with them to briefly grasp their proposal. You can expect the vendors to say that they understand your requirements and talk a bit about the feasibility of the features, their tech stack for the product, offer some suggestions and propose alternative solutions. They might also suggest developing your product in phases and outline a minimum viable product (MVP) for development. A cost estimate with a breakdown for support, maintenance and infrastructure, along with a development timeline, may also be provided.
You must take all of this with a pinch of salt, make notes of their observations and suggestions and after a thorough analysis, make changes to your product specifications if required. You might realize after meeting with a few vendors that they aren’t the right fit for your company, making you free to eliminate those vendors whose ideas don’t match with yours.
Once you decide which vendors to have the next meeting with, reach out to them for time and ask if they could walk you through any of their products and demonstrate the application to you. Insist on a demonstration as it will help you see their products live and in-action, gauge how well they can solve additional problems that may arise in future and evaluate their capability in real-time.
Meeting 3 — Evaluate their capability and discuss the proposal
When you are finally ready to talk to your vendors in detail about their proposal and evaluate them on different aspects, set up a meeting with them. The agenda of this meeting is to understand the expertise, capability and deliverability of your vendors and use the opportunity to discuss their product proposal and assess the kind of ownership you will have on your product.
As the first two meetings will help you eliminate a few vendors, you will most likely be speaking to 5–6 vendors for this meeting. We talked to five vendors and met them over video calls in one week. Having these back-to-back calls, although a bit exhausting, was helpful as we sat down with each vendor with an open mind and made a note of our observations without any selection bias.
After this meeting, you can objectively score the vendors as per the evaluation framework in the next section and narrow your list down to top three.
3. Evaluation Framework
The framework is five-fold and straightforward. Although there are many parameters to evaluate tech vendors, this framework identifies the five main parameters that will help you make an objective choice. Each one of these main parameters is, in turn, divided into sub-parameters.
3.1 Expertise
A tech vendor’s expertise in building products that are similar to yours has a tremendous advantage. It is always better to do some prior research about the vendor and clarify any questions you have about their business. Your first two meetings with the vendors will give you answers to most of the questions that you will ask in this section. Nevertheless, take advantage of this meeting and don’t hesitate to get clarifications to any questions you might have.
a) Experience
A company with good experience is always a safe bet. Ask your vendors for how long they have been in the market? What kind of clients do they have? How many projects are they currently working on? Ask them about the different divisions within their company and number of employees working under each of these divisions. For example, if a company has two divisions — products and services — it would be nice to know about the ratio of employees in each of these divisions.
These questions may seem obvious, but taking the time to answer them will help you understand their company better and determine their real value.
b) Product Domains
A company with experience in building products in a domain similar to yours and well-versed in different areas will be able to understand your requirements better. Ask your vendors about the various domains they have worked in. Do they only develop products in those domains, or do they offer consulting too? Have they worked with any communities?
If you are looking to build a product with different elements, these questions will help you transparently assess their capability.
c) Engagement Model
There has to be clear communication between you and your vendor at all times during the product development. It is essential to understand their engagement model and ask questions about project management. Most software companies apply the Agile approach with tools like Jira. Agile is flexible and allows developing products in iterations with rich documentation that enables changes during the development process.
Ask your vendors about their engagement model. How often do they communicate with their clients? How will they communicate with you? Will you have access to any tools within their systems to keep track of your product?
d) Team Size
Knowing the number of employees and the size of teams within their projects will give you an idea about who to communicate with and how many resources will be available to you at any point of time during the product development. Ask your vendors about their team sizes and how many resources do they engage in a single project.
e) Pricing Model
Pricing models will help you understand how vendors approach and handle their projects. It is more than just numbers. You will know how you can leverage their models as per your requirements and choose the one that aligns with your goals and timeline.
Ask your vendors about their pricing models and the number of projects they are currently working on under each of those models. A few options of pricing include —
- Fixed-price: Also called “Fix-Bid” where you will pay a fixed lump sum cost for the development of your project.
- Time and Materials: Popularly known as the T&M Model, is where you will pay your vendors as per the time spent by the vendor and the materials they will use to build your product.
- Subscription Model: Also called “Value-Based Pricing”, is where you pay a recurring fee periodically (monthly, quarterly, bi-annually, etc.) to receive a product or service regularly.
- Incentive-based: This model offers payments and bonus for vendors when they successfully achieve a specific performance level that is above the expected or agreed service level.
- Revenue Share: In this model, if a customer buys your product, the vendor gets a share of your revenue.
f) Similar Products
Once you learn about the different domains your vendor dabbles with and their project management models, you can start asking them if they’ve built any product that might be similar to what you are looking for. This question will prompt the demonstration of their application and allow you to ask them more questions about their product.
3.2 Technical Capability
By talking to the vendors about their expertise, you will have a pretty good idea about what type of company they are. Now it’s time to delve into evaluating their technical capabilities through the demonstration of their product.
a) Tech Stack
The tech stack of a vendor is a list of all the technologies and programming languages they use to build their products. You can expect them to propose a tech stack similar to the product on demo or adopt a different stack for your product. You can always let them know if you are not comfortable with any technologies so they can pivot their strategy around your requirements.
You can start evaluating this parameter by asking about the kind of technologies and languages they usually work with. It’s always nice to learn about their flexibility and comfort around using different tech stacks.
A vendor may use the latest technology, but software and systems change at an exponential rate. Find out if your systems are compatible with the vendors before you get on board. This is important as once they deliver your product to you, you might want to look for people who work with similar technologies to take over the maintenance of the product. It is easier to find people who work with industry-standard languages (Java, MEAN, NodeJS) and technologies than those who work with a completely new tech stack.
b) UI/UX Experience
Evaluating your vendor’s UI/UX experience will be easy once you take a look at their product. Good-looking pages and user-friendly interfaces are essential, but it will be nothing when you have slow running pages or crushes all the time.
Since most companies do not have in-house custom UI development, they will propose developing your product with basic yet appealing screens or leverage extensively available UI/UX templates online. You don’t have to worry about this aspect because a simple UI, that is no doubt appealing to the eyes, is good enough for the MVP. The vendors will take your input every step of the way to make sure they develop a UI that is feasible and acceptable.
c) Third-Party Integrations
The product demonstration is also an excellent opportunity to evaluate your vendor’s expertise with third-party integrations. Ask your vendors to demonstrate features and integrations like e-KYC, payments, SMS or other APIs and learn how many products have they done this for and what the onboarding process was like.
3.3 Deliverability
Once you finish talking to your vendors about their technical capability, it is time to move on to discuss their approaches for delivering the product. In this discussion, you can continuously keep referring back to the product-demo and understand this parameter in the context of all other products they’ve built.
a) Testing Mechanism
Talk to your vendors about their testing mechanisms by asking how do they approach product testing? What are the phases within those testing mechanisms? Do they test the code while developing or after development? How much of it is tested manually with QAs and how much of it is part of automation testing?
A useful metric to understand the quality of their testing efforts would be to ask them about their code coverage. Code coverage is a measurement of the number of lines, statements or blocks of code that are tested using a suite of automated tests. Code coverage shows you how much of your application is not covered by automated tests and is therefore vulnerable to defects. Code coverage is typically measured in percentage values — the closer to 100%, the better.
b) Ongoing Support
The vendor you choose may help you reach your current business objectives. Still, it would be best if you looked to the future to consider how your requirements might change and find a vendor who can scale accordingly and provide you with ongoing support and extendability.
Ask your vendors if they will provide you with any ongoing support once they hand over the product to you. How responsive are they with emergencies? What are their SLAs? Is the cost of the support included in the proposal? If not, what kind of pricing model should you expect for support? Most companies adopt a T&M contract and provide their clients with 2 or 3 support engineers who will be available to troubleshoot any problems. Some might choose to adopt a fixed priced model which is like a support team on retainer.
c) Extendability
You will inevitably want to add more features to your product after the first version. While some vendors hand over the product to you, and you are free to look for new vendors to take over, it is always nice to have the ones who’ve built it for you take care of the enhancements. Since they know the inner workings and understand your business objectives, a chance for conflict will be rare, if not never.
So, make a point to ask your vendors about their approach to extendability and enhancements. Is this component a part of the proposal, or would it cost extra? What kind of pricing model should you expect? How many resources will they provide you with? What is the duration for extendability? How would you engage with them?
d) Hosting Services
Once your product is developed, it is crucial to know where the vendor would be hosting it for you as, usually, the cost of hosting will be billed on actuals and directly to you.
Ask your vendors what kind of hosting services are they comfortable with? Most companies use AWS or Azure, so you can expect your vendor to take either one of these two names. Ask them how many products are they currently hosting on these services? What kind of load on the hosting service do they expect your product to have? What will the infrastructure costs be like? Is the cost a part of the proposal, or would it cost extra? Verify if it will be billed directly to you.
3.4 Ownership
Ownership includes all those factors that will help you retain control over your product and make any future migrations easy. The aspects that must be under your control are the source code, product documents and the IP of your product.
Furthermore, there are two scenarios in which you might be locked-in with your vendor once your product is developed —
a) Soft Lock-In
A soft lock-in is where you are locked-in with your vendor after product delivery to avail support, extendability and onboarding. Being in a soft lock-in is pretty standard, and this scenario will exist in the initial run until you get the hang of the product, establish a tech team within your company or partner with a new vendor.
You completely own the product and IP, and the vendor is essentially fulfilling his contract unless he has promised you ongoing support, maintenance and extendability as part of his proposal.
b) Hard Lock-In
A hard lock-in is where you are locked-in with your vendor in one of the two aspects —
- The vendor owns your product and your IP and will onboard you onto the product on a subscription basis. Imagine something like Slack or Airtable. The data is yours, but the product is owned and managed by the vendor. Be wary of this aspect.
- The vendor uses a tech stack that is different from the current industry standard. As mentioned earlier, issues will arise during the migration of your product. It is always easier to partner with those companies that work with standard technologies to avoid these issues.
3.5 Product Proposal
Now that you are finally done with understanding the capabilities and deliverability aspects of your vendors, it is time to discuss different aspects of their product proposal.
a) Product Understanding
You will start getting a fair idea if the vendor understands your product requirements right from the moment they start demonstrating their application. They will usually draw parallels to what they’ve built and what you are looking for to illustrate this aspect. If you have any further conflicts or clarifications, now would be the right time to discuss those.
b) Product Development
Most vendors will have a good idea about how to go ahead with building your product and mention their development plan in the product proposal.
You can further understand their plan by asking them if they are looking to leverage a similar and already existing platform or plan on building a new platform for you. If they are going to use an existing platform, what kind of elements would they use from that platform? Is it the same product that they’ve demonstrated? Ask them to explain to you those elements that they would reuse in your product.
If they are proposing to build a new platform for you, ask them about their project management. How would they plan the entire project? The plan will most commonly be to start with gathering requirements, designing flows, wireframing the product, detailing the feature set, building the UI/UX components and finally starting development with testing to follow.
You can also consider bringing someone on board who can help you with the project management and essentially act as a bridge between you and your vendor to simplify the technical components for you.
c) Product Architecture
Product architecture varies from product to product and depends on what kind of problem you are trying to solve. It plays a significant role in how to design, make, sell, use, and repair a new product offering. The most common architecture these days is the microservice architecture.
Make sure to ask your vendors about the kind of product architecture they expect your product will need and receive an in-depth explanation to understand how your product will function at every turn.
d) Product Data
Data is the key to understand your customers and ensure your business success and growth. Ask vendors to explain this component to you in detail. What is their approach with data? What kind of data do they expect your product will need? Where will they store the data? Which data systems will they use? How will the data be fed back to you?
Talk to them about data security. Find out what processes they have in place to protect your data and manage your security. Is there a backup plan in case of a security breach or a deadlock? Is there any end-to-end encryption?
e) Development Duration
When you start working with your vendors, it is better to plan the development because you don’t want to be in a situation where everything is ready for the product to launch, but you don’t have a finished product.
So it is always okay to reconfirm how long it would take for them to develop the product. Would there be any buffer given any change in requirements? The development duration will not change in many cases, but you should maintain a buffer of a week or two on your end, just in case. You can also consider taking a trial period, to understand how fast the developers work and to make sure that the software contains the features and functionality you need.
f) Pricing and Cost Estimate
Finally! The cost is an important parameter. When you talk to your vendors about their cost estimate, check for hidden costs or additional fees in the form of UI/UX development, ongoing support, extendability, hosting and infrastructure costs. Reverify all these aspects and come up with a total, final cost estimate.
4. Scoring Template
Now that all your meetings with the vendors are done, you are free to start putting the observations for all the parameters down in a document and start scoring them. Scoring is essential because this will avoid further meetings and conflicts amongst co-founders and help you save time to make a decision.
Here’s the scoring template that we used to evaluate our discussions with the vendors. You are free to make changes and plug-in new parameters as per your business requirements.
Since your conversations with different vendors will have either changed or reaffirmed your expectations on the product, the scores might be somewhat relative, and this is okay.
a) Scale
Scores in the template are based out of a scale of 5. Avoid using decimals to, in turn, avoid making half-hearted decisions. This is what each score means.
- 5 — Excellent: This is the most positive rating on the perceived health scale, a five-point scale ranging from “excellent” to “poor”.
- 4 — Very good: This is one point on the perceived health scale, a five-point scale ranging from “excellent” to “poor”. The rating “very good” comes between “excellent” and “good”.
- 3 — Good: This is the midpoint on the perceived health scale, which is a five-point scale ranging from “excellent” to “poor”.
- 2 — Fair: This is one point on the perceived health scale, a five-point scale ranging from “excellent” to “poor”. The rating “fair” comes between “good” and “poor”.
- 1 — Poor: This is the most negative rating on the perceived health scale, a five-point scale ranging from “excellent” to “poor”.
b) Evaluation Criteria
The criteria are simple. Make observations against each parameter in a manner that is concise and summarizes the entire parameter for you. For example, when making observations against the experience of a company, you can write something like “5 years, good clientele, two divisions”.
c) Average Scores
Once you score all the observations against the parameters, group that particular section of parameters and derive an average score for the main parameter. For example, once you score for experience, product domain, team size, engagement model, pricing models and similar products, calculate the average score of these parameters and arrive at a final score for expertise.
With this exercise, you will end up with average scores for the main parameters and know where each of your vendors stands.
d) Vendor Ranking
It is now time to rank your vendors as per your business requirements. A weighted score is the best approach to take when you want to make an objective decision. In this part, each main component is assigned a weight out of 100%.
For example, you can start by assigning —
- 10% to Expertise
- 20% to Technical Capability
- 20% to Deliverability
- 20% to Ownership
- 30% to Product Proposal
Your business requirements dictate what kind of weights each of these components must carry. Some companies place more weight on expertise, while others weigh deliverability higher. Some might remove pricing and cost estimates from the product proposal and turn it into a main component with a weight of its own. You understand your constraints and product requirements better than anybody else, so this is entirely up to you.
This exercise concludes your evaluation, and you are left with Top 3 vendors to make the final decision.
Final Decision-Making Process
You have to be ready to realize that a lot of vendors you talk to may not be the right ones for you. In that case, you will have to move on and consider another vendor.
While making the final decision, you can also consider getting an independent, non-biased opinion from your tech contacts by merely sharing the evaluation document with them. Make notes of their feedback and get ready to negotiate with the Top 3 vendors.
Negotiate the aspects of technology, costs, support, maintenance and anything else that you want or don’t want in your product. Some vendors are very negotiable and will cut their price in half with the right conditions, while others stick to their retail price. There are several different ways to pay for outsourcing your technology, and you must choose one that fits with your cash flow requirements, rather than the one reflected in your vendor’s proposal. After negotiations, you can use the same template to reevaluate the top three and pick one final vendor.
You can conclude the whole process by doing a reference check on the vendor of your choice by asking them for references. You only have to get on a phone call and ask them similar questions that you’ve asked yourself.
Completing these five steps will provide you with all the information you need to make an educated, prudent and objective decision in choosing your tech vendor.
Thank you for reading. I hope this will help you choose the right tech vendor for your business. If you liked it, show some love by clicking on the “clap” icon :)
