Choose the Right Technology for Your Platform in 5 Steps
You’ve been in the industry for a long time and realise that the industry is ready for a new disruptive product or a platform. You’ve brainstormed with yourself about this idea every day and with your peers and team every week. The ‘what’ of the matrix is clear to you – what is that new product that you want to build. You then begin to research the tech stack that would go with the needs of the platform and you find yourself with several combinations of possibilities, with the number of combinations rising with each conversation that you’ve have with people from the industry and those from the technology side of things.
The clarity of ‘what’ has given way to a muddled picture of the ‘how’. You find yourself overwhelmed by the options and start getting concerned if the product with come to fruition or not. Add to that the constantly changing technology landscape, and you are at the end of your wits. This is you, a technologist, trying to build a platform. Imagine the plight of a non-technology founder or leader who wants to build such a product or platform.
Let’s hop back a few steps and identify how you can simplify your decision-making process regarding this conundrum, and in the process, simplify your life too!
Complexity
Development of many platforms begins with an MVP and rightly so. Get to the shortest path to success and see how the response comes in. While the MVP might sound like the lowest common denominator, the architecture of the MVP is dependent on not just the immediate complexity of the platform but also a near-term view of what the product might look like, beyond the MVP, in the near future.
Are there too many concurrent transactions? I there a legal framework that needs to be adhered to, when handling user data? How often would the data need to be updated? What’s the response time expected by the users for a particular task?
There are innumerable questions and the answer to each question adds to the complexity of the platform. The technology platform that you should go with, depends on these initial complexities. We are talking about scalability, concurrence, security, adaptability, server response time, and a lot more.
The complexities of the ‘how’ can easily be simplified through building of user stories and use cases, that then help you identify the best technology stack. But that’s not the only factor. Let’s explore the second factor in this decision-making process.
Time to Market
You want your product in the hands of the users in the shortest time possible. Existing framework can use leveraged to build an MVP quickly but with a few trade-offs – inconsistent UX, bad data management, high number of libraries to achieve simple goals, and the list goes on. The issue is that what’s available off the shelf is a broad-based solution that might not cater to your product’s exact needs. If it did, then your product idea has probably already been productised.
You slowly realise that your definition of time to market needs to be changed to factor in customisation of existing frameworks and platforms. While this can speed up your time to market, it might result in technology overheads later in the product’s journey, when you move beyond the MVP stage. Oh, and you can’t ignore security at all. All this contributes to your decision of arriving at a preferred technology stack. In this scenario, you could be looking at a stable framework that scales with your business.
Transaction Volume
This is a tricky one because the transaction volume can only be assessed better with actual transactions. It is also a simple one to handle because the main variable is scalability. If the platform or the product is built to be seamlessly scalable right from the beginning, a welcome surge of transactions and user interactions will not overwhelm your technology infrastructure. What about a barrage of unsolicited traffic, you say? Well, that where the platform security policies come into play, right from the time the technology infrastructure is deployed.
Many product owners discount security and bring it as a priority when it’s already too late and the systems have been compromised. There’s a reason why you keep hearing about data breaches fairly regularly – no prioritisation of security.
Coming back to the transaction volume, if you’re building a fintech platform for the masses, you’re looking at massive transaction data that you would want to handle properly and maybe mine it for insights later on. This means that your platform needs to be geared for a high number of transactions right from the beginning. This might not be the case for a platform that caters to online bidding for highly rare and expensive artefacts.
Size of Data
Size of data is somewhat related to the transaction volume but not entirely. Imagine that you’re building a platform that’s big on proprietary video content. Now, the size of data from one video dwarfs the size of data created by transactions. But then again, you want your users to perform several transactions while engaging with the video content. So, you have reliability of the platform on one hand and the ability to serve huge amounts of content-related data on the other. This adds to the first aspect of complexity. See what’s going on here? Yes, everything is related and everything is contextual to your product.
When figuring out the solution to this data problem, you’ll have to understand the latency in serving data, the storage where the data is served from, the storage where transactions are stored, and this is just one aspect of your product, there might be many more.
Open Source vs Licensed Technology
If all this complexity wasn’t, well, complex enough, you need to deal with the biggest aspect of them all – the cost of technology. While licensed technology is ensures that someone else owns the responsibility for things to work the way they should, it comes at a high cost. Each license might set you back by a handsome figure. On the other side, if you decide to go with Open Source technology, you cost of licensing is minimal or zero but there is a cost involved with building the platform and maintaining it. At the end of the day, it is a balancing act between what you desire and what you should be spending on, just like the dilemma about buying a new car, or a phone, or something else.
Both technology options have their benefits and problems but open source at least gives you an option of taking the framework apart and build it to your customised requirements. Doing so with a licensed technology will add several hundred hours and exponential cost, to your product roadmap.
The aim of this point of view is not to cloud or confuse your judgement. It is to lay bare the facts. At Tekenlight, we have worked with a open source technologies that work in tandem with licensed technologies, to build a hybrid system that gets your work done and a lot more. It brings in flexibility that you desire at a cost that’s comfortable to you. Drop us a line if you want to have a longer discussion on these aspects and we will be happy to speak with you.
And congratulations on taking that step towards building the market disrupter!