How We Build World-Class Tech Products?
In my previous blog post, I discussed how to objectively measure website and app quality and evaluate quality from day one using a well-designed observability setup with open telemetry at its base.
Toward the end of that post, I covered our definition of a good tech product. This is how we define it -
1. App launch time (or website loading time) should be as fast as possible. Less than a second is the benchmark here.
2. API response time should be as low as possible, specifically P99 and P95 latency. Less than 150 milliseconds is a good number to start.
3. Database query and write times should be as low as possible. Read latency should be less than ten milliseconds. (For a single query).
4. The crash-free rate should be as high as possible. The last three platforms I built had a 100% crash-free rate (yes, it's possible) at a sufficiently high scale. But anything above 98% is a good number here.
5. The Number of bugs users encounter per month should be a single digit (less than 10). Bugs are inevitable, especially if you are developing rapidly. However, the number can be kept in single digits if careful enough.
6. The app/website/platform should have the same performance at any scale for any feature.
7. The cost of the entire tech product should be as low as possible. If your infrastructure is over-provisioned, you may get a short time gain in performance, but you are setting yourself up for failure when the actual scale hits. Also, you are just hurting your bottom line.
Some potential clients read my post and asked me the real question - How do we do this? How do we make such bold promises?
The answer is that we adhere to certain principles while building products. These principles have been formed from a decade of experiential learning, running product and engineering teams in startups, and advising large-scale teams as consultants. We also borrow learnings from some of the best engineering leaders in the country, whom I am lucky to call friends.
While each of these principles can be the topic of their own blog posts, I will try to give you an overview of each of these in a layperson's terms.
Step one of the playbook is defining the problem statement and scope well
In almost every discovery call with the client, We get the same set of questions along the lines of -
- I have this idea: how much time will it require to go live?
- Can you give me a rough estimate of how much this will cost?
- How many developers will this require? Can we do it faster by throwing more people on this?
- How many people will you be dedicating to my project?
Hey, founders and business leaders, I understand where you are coming from. If I were in your position, I would probably ask the same questions.
But here is the catch - While we answer these questions from a high-level understanding, the real devil is in the details.
Poor requirement gathering causes over 90% of product/feature launch delays, bugs, performance, and other product issues.
If you have been in a management position in product and engineering in any organization and systematically carried out retros for all those sprints that got delayed and still produced bad-quality products - you must have reached the same conclusion.
Before starting work, We ensure we detail everything possible to the nth level.
Immaculate documentation gets rid of human errors
This step is where the real magic happens. When we define the scope and problem statement, the output is a well-defined product requirement document that lets us objectively determine the time and effort required for the design and engineering.
If it's a visual product or feature, the next step is to create a low-fidelity or high-fidelity design in Figma or Sketch. We also capture the essential UX elements here and obsessively cover all edge/corner cases in use journeys to ensure that nothing falls through the cracks.
After that, we write a detailed Engineering document (ERD) that details the logic of all the APIs, client-side interactions, database schema, and much more.
We have templatized these documents to ensure that this entire exercise runs like a well-oiled machine, and we keep iterating on these templates based on the retrospective learning we get every month.
If you want access to these templates, schedule a call with me.
No sprints, kanban for the win
The reason why we deliver products in record time is because of our project management approach.
Unlike traditional engineering teams that follow a sprint-based framework (called scrum), where work is divided into time-boxed iterations typically lasting from two to four weeks, we follow a different approach called Kanban.
Kanban follows a fluid approach to project management and focuses on delivery rather than planning. Since our planning is all done in the form of documentation before we begin programming, this approach suits us best in terms of execution.
In Kanban, items are released as soon as they are completed without waiting for a sprint to conclude. Kanban also allows changes to be incorporated at any time, enabling teams to adapt quickly to new priorities or feedback. It is specifically beneficial when working with startups, where the priorities can change within days or weeks.
Observability from day one and bugs are always Priority one
I already covered it in my previous blog (that's what prompted this post). You can read it here
From day one, we start our solutions with observability in place. This allows us to detect, pinpoint, and fix issues as quickly as possible. We get alerts in our Slack, email, and Telegram channels, and every bug is picked up as a high-priority item in our Kanban flow.
Trunk-based development with CI/CD in place
Trunk-based development requires some programming background to understand, but let me try my best to explain it in layperson's terms.
Think of trunk-based development as a way for software teams to work together more effectively. Imagine a tree where the trunk is the central part, and all the branches are small changes or features being developed. In TBD, all developers work on this "trunk" (the main codebase) instead of creating separate branches that can become complicated and hard to manage.
Why is This Important?
- Speed: Our team can develop and release new features much faster by having everyone work on the same main codebase and integrate their changes frequently—ideally several times a day. This means that we can respond quickly to changing requirements or customer needs.
- Quality: Because changes are small and integrated often, it's easier to catch and fix problems early. It leads to higher-quality software with fewer bugs when it reaches your customers.
- Collaboration: When everyone works from the same codebase, it encourages teamwork and communication among developers. They can learn from each other and share knowledge more efficiently.
- Flexibility: Our team can deploy new features with techniques like feature flags, even if they're not fully finished or tested yet. It allows us to experiment and gather feedback without risking the entire system's stability.
Plug-and-play architecture and configuration first approach
When architecting products O(log n) labs, we take a fundamental plug-and-play approach to ensure no vendor lock-in. Extensibility and fluidity are built into the system and architecture design to ensure that engineering systems adapt quickly to changing business and growth needs. This is especially helpful in cases where the business is trying to experiment with a new technology or flow or build a POC or automation.
The Final Secret Ingredient
The engineer inside me wanted to make this post very long and explain each of the sections in detail, but the founder inside me knew that nobody would read a post that was longer than 5-10 minutes. So, I will end this here with the final page of my playbook— hiring people with a strong sense of ownership, an insatiable thirst for knowledge, and an intrinsic need to prove themselves and make a big name.
Everything I mentioned above is possible because of the kind of people we hire. And I am fortunate to have worked with everyone who has ever worked on my team.
If you are someone, who fits this description - Please find our job posts on our wellfound page (we're always hiring)
And if you are someone who is interested in learning this playbook more or you want us to apply it to your organization/product, please schedule a call with me today.