Welcome to the series How to build a tech product. This is article #4 of 11 articles that touch upon various aspects to consider while building a tech product.
In the previous post, we looked at documenting products requirements now let us look at the first step to bringing your product requirements into reality.
Defining architecture of a product is a fairly exhaustive exercise and should be done by architects based on the products requirements & taking inputs from key stakeholders of your business.
This article covers what you as a key stakeholder (founder, product head, etc.), should look for when it comes to understanding and reviewing the technical architecture of your product. On the other hand, the techies i.e. the architects / sr. developers can use this article as a high-level checklist for their product architecture.
What does product architecture mean?
An architect who plans and designs buildings not only defines what the building looks like from the outside. But also has to plan and provision for the internal structure of a building viz. beams and columns to hold the structure up, the electrical, plumbing, materials that need to used and more.
Similarly product architecture defines a technical structure (blueprint) that consists of components and their interactions, created with the end goal of meeting your business needs and goals.
Your product's architecture sets the roadmap for your tech implementation. Think of it as a strategy document that sets the tone for your product build. It needs to take in to account not just business requirements but also limitations and all known parameters under which a product needs to be built.
A good product architecture should help improve product quality, reduce risks, and save time & money
Product architecture check list
There are a host of aspects you should review your product architecture against. Here are some of the ones that are typically used. The idea is to identify any gaps in your architecture both from a business or technical stand point.
✅ Coverage
Your architecture should cover all aspects of your business / technical requirements. At times, business requirements might not cover all aspects of the product and these unsaid requirements should be surfaced as part of your technical architecture discussions.
Example 1️⃣ Most web applications nowadays depend on integrations with external systems like payment processors, messaging gateways, CRM, analytics, etc. Ascertain which of these systems are critical to business function, how is the integration handled are there are any fail safes required in case if any external system stops responding?
Example 2️⃣ While making a B2B SaaS product, the technical architecture should take in to account whether an administration panel is required to administer user accounts. Also, what type of functionality should be exposed on this admin panel and whether this administration panel needs different roles and privileges? There is a good chance your business requirements might not have covered the admin panel in depth and much of the focus during the initial discussion (rightly so) has been about the core product.
But covering aspects like the admin panel and avoiding scope creep is critical to stay within costs and timelines.
✅ Constraints
Constraints are limitations or restrictions, within which a product needs to be built. The reality is most projects do not have unlimited time and money to be delivered. Constraints can go beyond time & money, you also need to consider constraints across all related areas like business, technical, environmental, resourcing, etc. Being aware of your constraints & circumventing them is probably one of the most important aspects of building a successful product.
Example 1️⃣ For most projects, the most important business constraints are costs & timelines. Costs should be broken down into at least two parts, the first part should be the cost assigned to building the product from scratch. The rest should be assigned as the cost to maintain / enhance the product. Most product builders completely neglect the 2nd cost head.
Timelines and costs go hand in hand, your desired timelines should help ascertain whether you should break your product in to multiple phases and deliver it in parts.
Example 2️⃣ Technical constraints could be related to your end users. Do you need to support different screen sizes, bandwidth / network constraints, linguistic considerations, etc. Each of these will pose a challenge that needs to be taken into account and solved for.
Example 3️⃣ Environmental or regulatory constraints can increase the tech and compliance scope for your product. Say, you want the user to pay on your platform without redirecting to your payment processors web page then your platform should be PCI DSS certified. Depending on the industry your product belongs to you, will need to take into account regulatory constraints.
Example 4️⃣ Choice of tech stack and programming language will have an impact on your tech resourcing costs. Once you have identified the tech stack, figure out if you or your team have the capability to find, hire and retain the tech talent required to build and maintain your product.
✅ Scalability
Scalability entails checking if your product can grow with your business. Your business projections will inform this heavily.
Example 1️⃣ You should take into consideration, non functional aspects. Like how many users are expected to use your application and what does the projected user growth look like. Can the planned infrastructure be scaled horizontally and / or vertically to support this user growth?
Example 2️⃣ Say, your product needs to expose APIs to customers then you need to plan for API end point security & throttling incoming requests.
Making your software product completely future-proof is hard (IMHO near about impossible). Plan scalability of your product architecture for max 3 years of your business projections. 3 years can be a long time in life of a startup / product. There are countless external factors that can make the business & product decisions you took look silly. Don't sweat it! Plan for the near to short term and be ready to adapt.
✅ Performance
Performance and scalability can some times go in opposite directions. As your product scales to handle more users / data your application performance can start degrading. Performance concerns like maximum page load time, app screen load / navigation, API response should be defined up front. These parameters should be used as key considerations during code design and testing by the technical team.
Example 1️⃣ For a data heavy application database queries fired by the application should not take more than 0.15 seconds. If this is set as a thumb rule, then all queries will need to measured against this parameter. Any queries that need more time will need a design discussion.
Example 2️⃣ Ideal page load times for an e-commerce site should be 2 seconds or lower anything above this starts impacting conversions. This makes load testing a necessity, ideally done on your final product with closely simulated live user usage with your full data load and all your static content.
✅ Adaptability
You have identified a partner to fulfill certain requirements in your product and your products start interacting using APIs. Things turn sour after awhile, and you need to switch from partner 1 to partner 2. This ideally should not result in major change to your business & product. Another example of building in adaptability would be, you have implemented a key business logic within your product. Your developers should be able to implement a change in logic as and when required without a major overhaul. This will be possible only if the technical architecture allows clear separation of issues.
Example 1️⃣ You have identified a payments processor and have integrated their APIs in to your product. Later down the line, you decide to change your payments processor due to better commercials, failure rates, etc. This change should entail integrating APIs of the new payments processor and should not have an impact on the rest of your product. This will be possible if there is necessary abstraction built in to your technical implementation.
✅ Security
Security at a minimum should entail implementing recommended best practices as per your product type. Most of these best practices are well documented and are available online. From a product live data point of view, you should define the level of access controls you want to put in place.
Example 1️⃣ For most web applications the OWASP top ten is globally recognized as first step towards a more secure application. Similarly depending on your product type, follow and implement industry recommended checklists for security.
Example 2️⃣ For your support team to be effective at their job, what type of user data will they need to access? Do you need to keep a log of who has accessed which data set from your live systems? The answers to these type of questions will inform the level of security concerns your product needs to consider right at the outset.
✅ Diagnosis friendly
All products have bugs and encounter issues that are discovered after go-live. Large tech companies take an average of 52 days to fix security vulnerabilities reported to them.
Given the lower complexity and usage of your product, you would definitely want to provide issue resolution and bug fixes in your product much faster than big tech. To enable this, you would need smart monitoring and logging systems in place. This will help your tech teams to proactively analyse, fix and test issues in your product.
Example 1️⃣ Consider implementing error tracking and application monitoring tools like Sentry.io or Honeybadger. These tools help in reporting issues seen in your live environment as soon as it is encountered along with a complete trace of what transpired.
Example 2️⃣ Implementing behavior analytics tools like Smartlook or Hotjar help to ascertain if your product is being used by your end user as you intended.
Plan your infrastructure
Create an infrastructure diagram for your live work loads. Clearly depict the various components you require along with their interactions and functions. Most cloud providers have a infrastructure cost calculator. Use these calculators to get a sense of costs and look out for steep increase in costs as you increase instance sizes.
When it comes to infrastructure, for a product that can slowly ramp up with its user base going with a cloud provider like Amazon, GCP, Digital Ocean or Azure is the safest bet. Most of these cloud providers will provide certain basic (low CPU / memory) infrastructure elements for free - use these for your dev & testing work loads.
If you are a startup founder, look out for startup programs that might be beneficial for your business. Most of these programs provide cloud credits which can be very useful to get your business going without incurring a large infrastructure cost in your early days.
Laying the foundations
There are certain practices that you need to instill right at the outset as part of your tech build out.
Task workflow - Use a tool for task allocation across your dev team members. DO NOT use emails / chat / web meetings / phone calls to dispense requirements. Use a task management tool. Add tasks to a tool with a clear description of what needs to be done. One-liners are not good enough! A lot can get lost in translation, develop the discipline to write the task down with screen shots and a good description. We have been using Clickup across our organization for task management and this has resulted in a drastic reduction of internal emails and who does not like less emails.
Prototyping - Use a paper and pencil and draw out screens you feel you need. It's cheap and does not take a lot of time. Even after you engage with a UI designer first ask for wireframes before they submit the UI design in all its glory. Review these wireframes and ensure the flow plus user experience of your product fits with your requirement. Taking this route saves a lot of time and extra effort for your tech teams. This practice of prototyping should be followed across the lifetime of your product and not just at the beginning. Even after rigorous feedback cycles are followed, unfortunately, feedback for a product will still trickle in once the complete product development is done. To (try and) reduce this latent feedback, if possible, create working UI screens with out plugging in your server side and get feedback on this working UI prototype. Generally end (business) users provide their best feedback after using this working prototype.
Code - All your development work needs to be in a source control repository like Git. This includes configuration files, scripts and any other technical documents. Follow a standard Git branching strategy and use it across your environments. I would suggest to adopt a simple workflow like GitHub flow. If needed create separate repositories for different parts of your application for ex. static-site-repo, mobile-app-repo, api-repo, server-side-repo. Doing this allows you to control access to your code repositories on a need basis.
Next up
Now that we have seen how to define the architecture of your product, lets see how to choose a tech stack to build your product