Thoughts and excerpts post Agentic Summit BLR talk held on July 2, 2025

2025 is the year of Agents.

From copilots in enterprise workflows to autonomous agents navigating data lakes, we’re entering an era where decisions are made not by humans or traditional programs—but by models. Yet for all their promise, AI agents today struggle with a simple, unsexy problem: Reliability.

Hasura recently launched PromptQL, a completely new approach to tackling Agentic reliability. In continuation to Tiru's demo on stage at the Agentic Summit BLR specifically around building automations, this post unpacks the various AI architectures today, where they fall short, and how PromptQL’s unique approach of —Planning & Execution powered by an Agentic Semantic Layer—redefines what it means to build AI you can trust.

See the product demo given live at Agentic Summit BLR here:

Challenges in building Agentic Systems

There are a bunch of challenges that developers immediately run into as they start exploring building AI or Agentic systems for use-cases within their organisations:

1. Generalization Gap: LLMs haven’t seen your org’s data, your dashboards, your business logic - how can they make sense of it?
2. Data Messiness: Real-world data is inconsistent, semi-structured, and riddled with edge cases - current models are bound to fail
3. Non-Determinism: LLMs don’t behave like code. They generate different outputs even for the same inputs
4. Human Learning Curve: Prompting is a new developer skill—and brittle, its hard to get your prompts right without iteration

No, it's no longer about the Data

Data is the new oil - you've heard it being repeated many times over now. And like most things in life - it is partly true and partly not. When most people face the challenges above, they end up blaming others and start finger pointing, mostly alluding to one common point: Data Quality.

But in our experience, also corroborated by the team at Hasura who's been playing with large quantums of data for over a decade now, LLMs are smart enough to navigate data messiness owing to their semantic understanding capability. What then leads to this lack of reliable outputs if its not about challenges with data quality?

Reliability Framework for Enterprise-grade AI

Agents leverage the ReAct (Reasoning and Acting) framework to combine their reasoning abilities with the capacity to take actions, enabling them to solve complex tasks and interact with the environment more effectively. While MCP and the likes are doing a great job of figuring out the "Acting" part of the framework, the first part - "Reasoning" - is starting to look like an orphaned child.

For AI to be truly Enterprise-grade, and to be able to work in production, especially in mission-critical use-cases, we need systems that Reason well while displaying these important traits:

1. Predictable - Same input should give same output
2. Controllable - Should provide ability to direct the system towards an outcome
3. User-friendly - Easy to use and debug without requiring technical skills

This is the framework that we'll use to judge the various approaches taken towards building Agentic systems today.

Current Approaches

There are several popular approaches towards building AI systems, yet most of them are not ending into production. Here are a few of them:

1. RAG (Retrieval-Augmented Generation)

None of us are strangers to RAG, with its architectural pattern of relying on vector embeddings for retrieval of relevant context and providing it to the LLMs to fetch an answer.

Pattern: Search → Embed Context → Generate with LLM
Strengths: Grounded on data and easy to get started with
Issues:
1. Search (cosine similarity) may return different contexts each time
2. Limited memory and context window limits what can be embedded
3. No clear interface for feedback or corrections, especially with humans' inability to read vector data

Evaluation:
Predictability: 🔴 Low
Controllability: 🔴 Low
User-Friendly: 🔴 Low

2. Tool Composition (MCP-style)

If you haven't explored MCP (Model Context Protocol) yet, you have definitely been living under the AI boulder. MCP standardises the way LLMs and (hence) agents can access data and tools exposed by providers and data stores.

Pattern: Multiple tool calls coordinated by an LLM
Strengths: Possible to stitch together multiple tool calls to get to a desired outcome, that too with a unified and standardised tool-calling framework
Issues:
1. Each step is handled by a non-deterministic LLM
2. Tool choice, order, and usage may vary run-to-run
3. Human correction is difficult mid-flow unless explicitly built in

Evaluation:
Predictability: 🔴 Low
Controllability: 🟡 Medium
User-Friendly: 🟡 Medium

3. Multi-Agent Orchestration

Pattern: Role-based agents working together or workflows built as directed acyclic graphs such as in LangGraph

Strengths: Possible to orchestrate multiple parallel agents with a centralised manager to get to a desired outcome
Issues:
1. Faces the same non-determinism as MCP Tool Composition above
2. Adds further complexity in agent communication & coordination requiring technical expertise to troubleshoot

Evaluation:
Predictability: 🔴 Low
Controllability: 🟡 Medium
User-Friendly: 🔴 Low

4. Text-to-SQL Agents

Many vendors such as Defog but no clear winner yet

Pattern: User → LLM → SQL → DB
Strengths: SQL is interpretable and correctable - if output is wrong, analysts can inspect/fix it

Issues:
1. Needs technical ability to understand and parse SQL
2. Hard to embed business context unless done at the start
3. Doesn’t include agentic reasoning or sequencing across steps

Evaluation:
Predictability: 🟢 High
Controllability: 🟢 High
User-Friendly: 🔴 Low

Enter PromptQL

PromptQL is an AI framework built by Hasura that combines (1) a playground server iterating on a query plan using the power of LLMs and (2) a python runtime that executes the generated code over (3) a distributed query engine powered by Hasura's original DDN with (4) native data connectors to your internal and external data sources. In simpler words, think of it as a complex, iterative, and agentic text-2-sql engine that talks to your data.

The fundamental idea behind why PromptQL ends up with reliable AI is by decoupling Planning (which LLMs are great at, thanks to their reasoning capability over large amounts of data) and Execution (which LLMs suck at, and needs to be done deterministically every time). This decoupling is further augmented by bringing in an Agentic Semantic Layer (strengthened by LLMs) that self improves its understanding of the metadata underneath for better Planning as more and more business context is fed in with system usage.

🧠 Part 1: Planning

Create a Query Plan

Agents construct a plan in a domain-specific language (akin to SQL for agent tasks) known as PromptQL that helps decouple planning and execution.

The output plan is interpretable, testable, and modular—separating logic from raw generation.

This reduces LLM involvement to only parts that require creativity or embrace ambiguity.

🧭 Part 2: Execution

Execute Deterministically

The query plan is executed deterministically using a python runtime, ensuring consistent results across runs. This leverages the DDN that Hasura has mastered over a decade, stitching together databases and external data sources seamlessly.

Each step’s output is stored as an Artifact, creating traceability and reuse.

⚙ Part 3: Agentic Semantic Layer

Business Context to Metadata

PromptQL embeds metadata from the organization’s data systems—schemas, metrics, lineage, business rules, into the query plan. As the user iterates with PromptQL, the system builds a semantic understanding of the metadata, which it leverages as context for future outputs.

This provides the agent contextual grounding, tribal knowledge, and alignment with business semantics.

Benefits:

Predictability: 🟢 High. Plans are executed deterministically
Controllability: 🟢 High. Humans can edit plans, tweak DSL, or adjust the semantic layer
User-friendly: 🟡 Medium. Combines natural language flexibility with structured logic but does require ability to look inside the generated code when debugging is needed

PromptQL's approach towards data access clearly trumps the current approaches, especially in its ability to navigate LLMs towards finding the right answer to a user query. But there are areas that continue to require improvement over time -

(1) Supporting unstructured data - think multi-modal text/video/audio
(2) A more intuitive interface for iteration in the Planning phase
(3) Ability to take actions on behalf of the user (maybe via MCP integrations?)

Curious to learn more about PromptQL? See a quick summary here and read more in PromptQL's documentation:

Final Thoughts

Just like SQL abstracted databases for users, PromptQL abstracts AI agent system complexity into something declarative, trustable, and powerful. And this time you don't need to learn a new syntax to get reliable answers.

We are excited about PromptQL's potential in solving agentic reliability, and continue to keep a close eye on other approaches that makes agents truly successful within the enterprise.

Are software infrastructure ("DevInfra") companies starting to re-grow or do they still focus on profitability and revenue efficiency? How are the public market valuations changing for these companies? How are investors - both public and private - thinking about Infra? Is India the next in line to benefit from the rise of DevInfra?

If these questions peek your interest, keep reading on and download our full report here.

Public Markets

At Grayscale Ventures we continuously monitor US-listed Public DevInfra companies, analyse trends, and identify gaps where startups can build. We further hone into what growth stratgies are working for these companies. This is why we created the Grayscale Infrastructure Index ("GII").

In 2025, GII continues to outperform EMCLOUD by almost 70%! Why you ask? We believe it boils down to:
(1) Stickiness of Infrastructure
(2) Demand for AI .

Stickiness - GII companies have a unique characteristic of being highly sticky within tech stacks, resulting in a Median Net Revenue Retention of 112%. Our research also finds that companies have grown ~27% in the last 10 years - primarily driven by this high retention rate.

AI - While revenue growth overall slowed down in recent years, Data Infrastructure continued to grow at 26%, because of new index entrants such as Rubrik and C3. Meanwhile companies like Snowflake continue to grow strong with the increased demand for data in the AI age.

Even as these tailwinds propelled GII companies beyond $42B in revenue in 2024, three growth strategies are consistently emerging from these companies:

1. Platform Approach - companies such as Gitlab and Datadog have shown that taking a platform approach towards a market segment is helping them go deeper into existing accounts by showcasing cost savings and sales efficiency
2. Data Management for AI - meanwhile the AI wave is bringing back Data front and center for enterprises - requiring adoption and purchase of new data products
3. Channel Partnerships - companies such as Rubrik in this vertical are heavily reliant on channel partnerships and alliances, from Hyperscalers that continue to bring enterprises on cloud to System integrators who acts as sales and implementation partners

Private Markets

Analysing the recent YC batches, we see almost 70% overlap between AI and Engineering, Product and Design and Infrastructure categories. Other Seed investors are following suit with two kind of companies emerging at the confluence of AI and Infrastructure:

1. AI for Infrastructure - Trained on enormous amounts of code, AI agents are creeping into the entire dev workflow throughout the application and cloud infrastructure stack - across Coding, Deployment, and Testing
2. Infrastructure for AI - Meanwhile, a new stack is starting to emerge to host and enable Agentic workflows split across Data, Planning and Action

India

What does all this activity mean for India?

India has no shortage of high-quality technical tertiary institutions, but the real strength of Indian developers is seen in handling infrastructure at scale for a population of 1.4B people. By virtue of its size and education, India already has the right talent pool to compete against global DevInfra market incumbents.

This year, our Grayscale India Private Index had to be expanded from 30 companies to 40 companies, assembling the new Grayscale Top 40 which tracks revenue performance of Indian DevInfra startups across stages. More than 30 startups surpassed the $1M revenue mark in 2024, whilst 6 out of the 40 startups maintained $100M+ in revenue. Together, these companies crossed $1.5B in revenue in 2024.

VC investments also surged in 2024 to ~$600M, but continued to lag significantly behind the US peers, showcasing a lucrative opportunity for global growth investors to tap onto these companies.

Grayscale Ventures truly believes in the immense potential of DevInfra in India - even more so in the AI age. We aim to be "Day-0" partners with product-led founders building global Software Infrastructure from India. If you are a founder building in this space, please contact us at ventures@grayscale.vc.

Are software infrastructure ("Infra") companies focusing on growth or profitability? How is that impacting valuations? How are investors thinking about Infra? Where is India in all of this?

If these questions peek your interest, please keep reading on and download our full report here :)

At Grayscale Ventures we make it a point to monitor US-listed Infra companies, analyse trends, and identify gaps where startups can build. Thats why we created the Grayscale Infrastructure Index ("GII").

The GII have significantly outperformed the EMCLOUD by nearly 30%, almost fully bouncing back to 2021 highs by the end of 2023. Why you ask? We believe it boils down to three factors: Interest Rate Expectations, Resilience and Growth Drivers, but we are going to focus on Resilience and Growth Drivers as Interest Rate Expectations are not dictated by company or sector fundamentals.

Resilience - Infra companies have a unique characteristic of being highly sticky within tech stacks, resulting in an Average Net Dollar Retention of 115% amongst GII companies. Along with sticky revenue is an asset light business model that allow for flexibility to expand margins in times where demand expectations are low. Our research finds that Median FCF Margin doubled from 7% to 14% whilst Median Revenue Growth only slowed by 4% between H1'23 and H2'23. In essence, greater efficiency was achieved without sacrificing much growth in a relatively short period of time.

Growth Drivers - We are seeing several trends within the GII. Datadog and Cloudflare has witnessed successful Multi-product strategies for expansion. Infra companies have also started to encroach onto the $37.7B Government software market, with an increasing number of FedRamp Authorisations and FedRamp Reuses every year. Pursing these expansion strategies whilst benefiting off AI-driven revenue streams have sparked bullish interest from investors.

Analysing the recent YC batches, we find that there is increasing focus in two categories Engineering, Product and Design and Infrastructure, occupying about a quarter of recent batches. Other software investors are also following suit. The focus shift is not just driven by the observations in the public markets but also the rapid emergence of AI applications, use cases, and infrastructure needs. AI sub-categories that did not exist two years ago now exist: Coding Assistants, Automated Front-end Builders, Automated Testing, Fine Tuning, Data Platforms, LLMOps, etc. VCs see this boom and are willing to bet on companies that they think can be early movers to capture a share of the trillion dollar (According to Bloomberg) AI market.

What does this mean for India?

India also has no shortage of high-quality technical tertiary institutions like the world famous Indian Institute of Technology (IITs), where Sundar Pichai (CEO of Google, IIT Kharagpur) graduated. By virtue of size and education, India will have the right talent pool to compete against global Infra market incumbents.

The Grayscale Team has assembled the Grayscale Top 30 which tracks revenue performance of private Indian Infra startups across stages. We find that 26 out of the 30 startups have surpassed the $1M revenue mark whilst 6 out of the 30 startups crossed $100M in revenue.

Despite tailwinds boding well for Indian Infra startups, it has only received <1% of VC dollars when compared to its US counterparts - $150M vs. $16B according to Traxcn.

Now you might be thinking...why aren't VCs pumping more capital into India Infra startups? The US is home to the world's largest software market where enterprises pay Top Dollar for software. The geographical disconnect between Indian startups and US enterprises makes it more challenging for them to sell to US enterprises, not to mention the cultural differences when scaling teams from India to the US. That being said, we have seen an increasing number of Indian startups resolving these issues. Companies in the Grayscale Top 30 like Hasura, Postman and Browserstack are already championing for India and have cracked US GTM. In case you have not heard...Browserstack has surpassed $200M in revenue. We are also seeing a long tail of 1000+ Infra Startups originating from India tackling US GTM from the get go.

Grayscale Ventures believes it is 'early days' and sees immense potential in India. We aim to be day 0 partners with Indian founders building in Infra. If you are a Founder building in this space please contact us at ventures@grayscale.vc.

In continuation with my previous post about AI in BigTech vs Startups...

By now you're probably been inundated with several memes of Sundar Pichai, stuck in a time-loop droning “AI”.

It reminded me of a talk I attended as a MSFT dev with a sweaty Ballmer jumping up and down the stage shouting “Developers”. Well that didn't end well for him :)

Google I/O Announcements

Based on the new announcements from Google I/O, it's quite clear that as of now, in the Application layer, big tech is busy injecting AI left, right and center into its existing applications - Consumer and Enterprise. We are likely to see bots, copilots, recommendation systems emerge in pretty much all the apps we use within a short span of months, if not weeks. Here is just a sample list of announcements made during Google IO.

• Google Photos - Magic Editor
• Google Workspace - Duet AI
• Google Search - Perspectives
• Android Studio - Studio Bot

What's also becoming clear is that BigTech is not currently thinking of how to build AI-native or AI-first apps. These AI-native apps need to work at a higher level of abstraction than the current input control parameters that applications rely on, but the incumbents seem to be bogged down by the same thing that enables them - incumbency.

• Think Spreadsheets. Instead of a giant table of text and numbers entered by data, and features such as Autocomplete, Suggestions, etc, what the user really needs is insights and analysis on top of this data presented to them in a much more intuitive manner? In near future, there might not be even the need to “pull numbers into a spreadsheet” and “crunch them”.
• Think Word Processing. Instead of a creators-block-removal paragraph, or a blog post written and edited by a bot - as already implemented by the likes of Notion, Word, and Docs, what the user really needs is a way to transform ideas into text in their own original voice? Or a way to restructure the flow of their existing text and make it short and to-the-point or long and detailed as per their requirement? Does the interface even need to look like a blank canvas any more?

Business Model Disruption

In VC there is a popular theory, and I somewhat agree with it, that for startups to win during a technological revolution, the fundamental question comes down to whether “Incumbents will adopt Innovation faster than Startups find Distribution”? While I do lie in the camp that simply adopting AI as an API will generate much more value in the BigTech companies, I also feel that this statement disregards true business model innovation.

If the blank canvas or an empty spreadsheet is not as valuable anymore, then why do I as a user pay $8 per month for that piece of canvas. If the power is shifting from platforms to intelligence, then I might prefer to pay $10 in the months when I create more content with the help of my intelligent co-worker, but $0 in the months I take a vacation - basically a Credits-based model. Do Microsoft and Google have the willingness to reorient their business models towards pay-per-use-of-intelligence instead of the current platform subscription model? As of now, I doubt that they have any incentive to do so, until the time their core business starts getting threatened, by which time competition would have sprung up already. Does this mean that BigTech gets disrupted? I doubt it - they will be an eventual follower of the AI-native apps and remain relevant because of distribution.

But a handful of startups will emerge true winners of this AI applications race as they will be the first ones to innovate on the delivery, native use, and business model in the AI age.

Today we announce the launch of our new fund - Grayscale Ventures - focused on DevInfra and SaaS investments in India and the region. You’ll hear more about our thesis and focus areas in future posts, but I decided to pen some thoughts on the launch.

Embarking on a new journey

As many of you’d know, for the last 7 years I invested across several companies in the DevInfra/SaaS space - Hasura, Classplus, Ayoconnect, Testsigma - to name a few. I deployed two funds for STRIVE, and as luck would have it, they did well. Just yesterday Preqin announced our second fund to be the best performing sub-250M venture fund in Singapore.

But as we started to prep up our third fund at STRIVE, more and more I felt the need to go back to my roots and focus on the two big (and related) shifts I’m seeing in the market - talent explosion in India and the proven playbooks of building DevInfra and SaaS companies from India for the world.

The Early Believers

I’m beyond excited that some of the best operators and founders in our network - from Slack, Zendesk, Hasura, Apollo, Ayoconnect, etc - decided to back us on the pursuit of these two trends. Investing in a first-time fund is always risky, and I am truly indebted to those who have believed in us in such volatile environments.

Our aim is to bring onboard the best SaaS and DevInfra operators globally on to our platform - as investors and advisors - and help our portfolio companies expand to every corner of the world leveraging the insights and experience of these operators. I can proudly say we are off to a good start.

Going Back to the Core

At my core, lies a geek who sat up late last night setting up a Gastby instance on a Netlify server while struggling to get Ghost working on a DO droplet (thanks Nishant for all your WA troubleshooting). If all this sounds g(r)eek to you, that’s the point. These are my dev roots that I can now return to.

Now I know that I am no longer in the race for becoming a “10x engineer”. But at Grayscale, I’ll have the chance to enable such devs to fulfil their dream of building a legacy. And through them, I plan to live vicariously for the next two decades.

P.S. Besides Grayscale gives me a chance to go back and tinker with code, an itch for a few years. Next time Sid comes and tells me to stop fooling around and move on to Webflow, or pay up that SaaS company providing a template blog instead of hosting a bunch of OSS systems on a server that might break any day, I can say to him “This is part of my job, dude. I’m building a thesis here”

Leaving old friends behind

When you start a journey, you end up saying farewell to many special people. This time around it was a pretty hard thing to do. I’ve worked together with Yusuke Amano, Tatsuo Tsutsumi, and our Japanese colleagues for so many years now, it's become second nature. I’ve learnt a lot from them, especially the Japanese art of balancing aggression with calm, exploration with focus, and velocity with patience.

But thankfully, it’s not really a goodbye, as we continue to service STRIVE and its portfolio companies - our portfolio companies. I’m even more thankful to not walk this path alone, and instead have Sid join me on the ride. While Grayscale is a new journey, it builds on from our previous STRIVE journey.

Some Core Values

As we embrace the unknown, we carry two things along with us - a bag full of learnings, but more importantly, a keen sense of our values and those we are searching for in the founders we back.

Over the years we feel we have come up with a darn good framework of sussing out who we want to work with - that’s also a post for another day. What’s more important though are our own values which we go back to again and again - to enable the builders in their 0-1, no matter what. Every step we take, every action we perform, every shareholder we bring on, every investment we commit to, every “Pass email” we send - should be enabling the builders around us.

To be able to do this, we’ll rely often on one word: “Product-led”. Not only will we be focusing on Product-led founders, we ourselves will aim to be Product-led. To us that means being iterative, honest, great at communication, and trusting in technology.

Parting Words

This is not an easy time to build - neither for a Company nor for a Venture fund. But it’s most definitely the best time to build, as the noise settles down and the signal shines through.

Let’s build.

As people would know, there are 0 promotional messages on this blog. However, for open-source I am willing to make exceptions, and the Indian open-source community is the closest to my heart.

Hence, I am glad to announce our partnership with FOSSUnited for the IndiaFOSS 2.0.

IndiaFOSS is a yearly conference to interact with the Free and Open Source Software community in India. The conference hosts some of the best minds in OSS in the country and this year the line-up of speakers is particularly exciting.

📍 23–24 July 2022, Bangalore
Tickets: https://indiafoss.net

I’ll be attending the event as a Community Partner and more importantly a curious audience member. Will you?

It all starts with the People with a Mission.

I was introduced to Gautam by a portfolio founder for whom we have a lot of respect. In his words “Gautam is one of the best Devs I have worked with”. This sort of validation ranks the highest in our opinions, so I went into the meeting excited. I was not disappointed.

The Broken Piece

Like any VC, we like chasing giant markets with BHAGs.

So I asked myself a simple question:

Why is it that my $100 wireless vacuum cleaner, an Airbot Supersonic, does not connect to the internet and my iPhone, and notify me when it needs a new filter? Or that the battery level is at 30% and I should charge it before the next time I take a swing at the carpet?

The answer is not that connecting this device to the internet is hard - that it’s difficult to place a $10 microcontroller and a BLE chip in there. The answer is that managing a seamless infrastructure between the device, the cloud, and the mobile client is hard, and scaling this infrastructure to millions of devices is nigh about impossible for companies that dedicate their engineering bandwidth to hardware, not software.

Why Now?

While markets can be large today or in the future, timing them right is the key to success.

Manufacturers and OEMs find it extremely hard to build a backend infrastructure team today. They tend to attract great hardware/embedded talent but not top-tier software/infra talent. LinkedIn India ranks Site Reliability Engineer or DevOps as #2 and Backend Developer as #11 on the top 15 jobs-on-the-rise report in 2022.

Side joke, LinkedIn’s own website is suffering from poor infra management, see the non-rendering images in the screenshot attached. CDN issues anyone?

As a result of this talent gap, the OEMs and manufacturers of devices tend to limit full cloud connected support only to the most premium segment of their devices, if at all. Imagine facing this, while more and more manufacturers needing to connect their devices to cloud and transform themselves.

Enter Bytebeam

Gautam and his cofounders — Ravi, Bharadwaaj, and Achal met through shared stints together in the past. The most significant of these was leading Engineering, Data, and Embedded divisions for Ather Energy, India’s foremost EV manufacturer.

There, Gautam and his team discovered how tough it is to make devices smart, and keep them smart, while running at scale. Not only do you have to excel on the hardware and embedded software side, you need to be able to build and maintain backend infrastructure and client software, at scale, for devices moving on the field, each with myriad ways and endpoints to connect to the internet. This internet on the edge compounds the scaling challenges typical to an infrastructure — how do you handle patches of low connectivity, dormant connections, packets of missed data, and so on? How do you update the devices over the air, firmware and client? How do you roll out feature upgrades and A/B test product updates?

This is where the dev world needed a simpler way to connect to the devices on the edge, a way to manage all of the infrastructure seamlessly. Companies such as Apple spend billions of dollars in R&D each year to solve this for themselves, but who will solve it for the smaller companies?

Bytebeam has come up with a unified platform to allow device manufacturers to manage all their IoT requirements such as connectivity, cloud backend, over the air updates, authorization, observability, visualization, and bug fixes on a single platform.

How to Distribute?

I have no doubts that the Bytebeam team has built an exceptional product and found early PMF. But the world is riddled with tombstones of companies that found PMF yet could not figure out the right distribution channel. This is where Gautam’s experience and affinity to Open-source shines through.

Open-source can be a natural distribution channel in this market as most of the devs in the IOT world already rely on open-source technologies, starting from Linux to Arduino to Flask, all the way to the cloud compute and storage, and then monitoring in Grafana. OSS also ensures cloud vendor neutrality for the manufacturer. The challenge comes in developers trying to stitch together this stack themselves, hosting, and maintaining it, while ensuring security and data privacy for the end customers. To us, there is a clear gap existing in building a Firebase/Supabase for the IOT segment.

The Wedge in?

While a product’s positioning and distribution might be clear, we always prefer attacking a challenging market with a thin wedge and expanding on it.

Bytebeam is planning to use an MQTT broker as a wedge in because MQTT is the base layer protocol that every IOT developer relies upon for device communication. Currently, the most popular options for a broker are to use either EMQX, an open-source broker built by a Chinese company backed by Hillhouse and GGV, or a cloud provider’s own broker — example AWS IOT.

EMQ has a downside that their headquarters are in China (similar to Clubhouse’s challenge of using Agora and sending data to Chinese servers)— imagine a US device manufacturer potentially exposing customer’s geolocation data to Chinese servers(!) AWS and Azure IOT stacks are cloud specific and don’t allow portability. This, in our opinion, is the possible market gap to explore, create a wedge, and build an overall end-to-end platform around the IOT stack.

Conclusion

What I LOVE about the Bytebeam team, apart from three decades of combined experience working in this space, is that they are building to handle scale from day 1 and thinking of attacking a core part of the dev production stack. While they iterate on the right wedge, continuing to be scrappy, I expect them to scale rapidly once they are confident of their PMF. We have seen this open-core journey at Hasura and Testsigma before, and are happy to work with the team on our learnings.

I am excited for the decade of smart devices and playing a small role in it.

In the last few years, I have invested in several developer-infrastructure companies, including Hasura, Testsigma, and 100ms. At each one of these companies, we have taken an open-source strategy to engage with the community and get product feedback early.

One of the key decisions that the founders had to make early on in their journey of launching open-source products is, “Which license to choose for making their open-source code available?” As we started answering this question, we realized the open source licensing norms, especially for commercially inclined companies are in a state of flux. In this post, I decided to unpack some of the popular options, as well as the decisions that other larger companies have made in this regard.

But before we begin please read this standard IANAL warning:

I am not a lawyer, and my post and conclusions below are my own personal inference of each license, as well as what I would do if I were launching a commercial open-source product in the market today. Please seek proper legal advice before following any of the content, tips or advice mentioned in this article.

I am also not sure whether I managed to get every legal aspect right in this article, so please feel free to point out any errors and I will publish edits over time.

To kick off, we firstly need to agree on what are open-source licenses? The definition of open-source is governed by OSI, the Open-Source Initiative. You can see a list of OSI approved licenses. Anything that OSI has not approved is, by definition, not open-source. Yet some of these fall under other categories of licenses which are generally called “Source-available”. In my post, I am clubbing the source available licenses such as SSPL within open-source licenses conversation but I repeat again: SSPL is Not an Open Source License

There are primarily two categories of licenses out there, Weak and Strong. Here is a table that reflects a summarized comparison of the more popular ones:

Popular License Choices

We compare these licenses on the following parameters:

• Is the license OSI-approved?
• Does it mandate Copy-left i.e. all modified and extended versions of the code need to also follow the original license?
• Does it allow Redistribution i.e. can some one distribute your code as a service?
• Does it allow Derived Work Redistribution i.e. can some one modify the code and then provide it as a service?
• Does it allow Monetization i.e. can some one redistribute and sell your code as a service?

Permissive (Weak) Licenses

MIT

• One of the most flexible Open-source licenses out there, it’s the default choice for people who want to publish truly open-source code and care very less about risk of copying/monetization
• It does require the original copyright and license notice to be included either in the distributed source code or software
• However, there are no restrictions regarding redistribution or monetization
• It is also compatible with many other open source licenses, meaning that MIT-licensed code can be used in other open source projects that use different licenses

Apache

• Almost as permissive as MIT license, this license was developed to combat frivolous patent lawsuits. The license grants you a patent license along with a copyright license
• It requires license notifications and copyrights on the distributed code and/or as a notice in the software
• However, derivative works, larger projects, or modifications are allowed to carry different licensing terms when distributed and are not required to provide source code
• Similar to MIT license, If someone decides to create open source projects in direct competition to your commercial offering, they’re allowed to do so without your permission. It gives the community the control and power they deserve for contributing to and evangelizing your project

Copyleft (Strong) Licenses

These licenses were created to deter attempts by third party organizations (mostly cloud providers) to use open source work for commercial gains.

Copyleft as a concept is simple. It mandates that if someone modifies the software and distributes their own version, the modified version must copy the same license as the original version.

There are multiple types of licenses with copyleft characteristic:

AGPL

• The AGPL or Affero GPL, a version of the General Public License (GPL) aims to enforce full copyleft rights on all software that use it
• Note that here I talk only about AGPL, instead of GPL, as it was derived from GPL keeping in mind server-side applications, which is the predominant way software is distributed today
• The license started becoming popular in an attempt to protect derived works of the original open-source code to be commercially offered by third parties

The key clause in this license is: “your modified version must prominently offer all users interacting with it remotely through a computer network … an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge…”

• The definition of modified version or derived work in the license is fairly broad, and potentially opens up even a genuine user towards potential lawsuit if they are building on top of your software and allowing their customers to “interact remotely” with the software
• Because of this strong copyleft nature, the license puts some teams off of open-source packages as it potentially forces all other code they may write to become AGPL-ed software. A good example of this is Google’s strict internal policy against using AGPL software.

SSPL

• Recently, MongoDB and Elastic came up with their own version of non-open source but “source-available open core” software license by further modifying the AGPL license to specifically cater to the software being provided as a “service” instead of a “remote network interaction”
• More importantly, SSPL requires that those making SSPL-licensed software available to third-parties (modified or not) as part of a “service” must release the source code for the entirety of the service, including without limitation all “management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service…”
• This way Elastic and MongoDB’s are protecting their hosting business, by making it almost impossible for a cloud provider or a vendor to comply with the SSPL license while providing a hosted version of the open-source products
• Needless to say, there is a strong debate ongoing on adoption and use of such SSPL software

Important Transitions

While you may think that choosing a license is a once-and-for-all decision, history says otherwise. A number of companies have transitioned their licenses from weak to strong (mostly) and strong to weak (rarely). Some have done these changes multiple times in their lifecycle. If there is one learning I have from reading the below changes, it’s that we don’t yet have a gold standard to follow and your license choice depends on your product, your business model, and most importantly, your fears.

Here are some examples of license changes that happened recently:

Confluent: Moved from Apache to Confluent Community License

Elastic: Moved from Apache to SSPL (and Elastic License)

Grafana: Moved from Apache to AGPL

MongoDB: Moved from AGPL to SSPL

Redis: Moved from AGPL to Apache (with Commons Clause) and again moved to Redis Source Available License

Cockroach Labs: Moved from Apache to BSL (Business Source License)

Conclusion

Again, IANAL (see disclaimer above), and my conclusion below is my own personal inference of each license, as well as what would I do if I were launching a commercial open-source product in the market today. Please seek proper legal advice before following any of the content, tips or advice mentioned in this article.

• If you are building a commercial product, are not scared of cloud providers or third party copying your code and distributing it, already have a relevant commercial-licensed offering to distribute along with the open-source solution, I’d consider using the Apache license. It’s one of the most flexible and open source licenses, and community adoption is likely to be the highest.
• If you are worried about third parties, especially cloud vendors, commercializing your code and want to desperately prevent it from happening, but your product is unlikely to be directly integrated into your customers’ products and hence will not be “remotely interacted with” by their users in turn, and is instead a standalone product that will be used only by your customers themselves, consider using AGPL because it is an OSI-approved license. But remember, that your community adoption will likely be lower, especially in the enterprise segment.
• In all other cases consider using SSPL under a source-available license to truly protect yourself. But remember that you will not fall under the definition of open-source and hence cannot call yourself an “open-source company”. This way your community adoption will likely be the lowest among the three.

I hope this post helps you think through your open-source licensing choices. Do reach out to me on LinkedIn/Twitter with a short note in case you have any follow-up questions.

A few days ago, I had a chat with an LP who is looking into the Indian B2B market for the first time. His question to me was simple:

“Do you believe that a large enough business can be built by charging subscriptions to Indian SMBs?”

My answer was simple:

“No”

But a moment ago I had explained how we are investing heavily into the Indian B2B market targeting the SMBs, explaining why this market is so hot, why Messrs Scott Shleifer, Masayoshi Son et. al. are dumping hundreds of millions of dollars on the market and why India B2B products are no longer restricted to Global SaaS businesses but also businesses targeting Indian SMB. So how do the two statements add up?

I don’t see companies building a significantly large subscription businesses targeting the Indian SMB market. But the SaaS-enabled marketplace business model is often overlooked by those not investing in the Indian SaaS category. And this is the gold mine that a handful of investors are searching for.

I am not alone in saying this. As you read, massive companies are being built by exceptional founders in the Indian B2B category taking this exact approach. But instead of building a $100M subscription revenue businesses from Global SMB/Enterprise, their goal post is different:

How to get to a ₹10,000 Cr Revenue business?

Why this arbitrary ambitious target? If you look at recent IPOs on the National Stock Exchange (see Dixon Technologies) or even NASDAQ, crossing a ₹1,000 Cr revenue mark usually equates to a $1B valuation. But in the age of billion dollar fund sizes (see Tiger Global’s latest fund of $6.7B fund or Sequoia India’s latest funds of $1.35B), a Unicorn valuation doesn’t cut it any more, it’s the age to build a Decacorn.

As a general rule of thumb, an Indian B2B marketplace businesses ends up with 10–20% take-rates. A ₹10,000 Cr Revenue business can end up yielding ₹2,000 Cr of Gross Margin and (hopefully) at steady state at least ₹500 Cr of EBITDA. At a conservative 30x EV/EBITDA this would yield a company worth ₹15,000 Cr or $2B. But at an inflated tech multiple of 100x, ~$10B.

Hello, Decacorn 👋

Before you say, making ₹10k Cr Revenues as a B2B marketplace is not likely in India, take a look at some benchmarks:

Flipkart is currently doing ₹30,000 Cr+ revenues in India. Amazon is currently doing ₹10,000 Cr+ revenues in India, and even Zomato crossed ₹11,000 Cr in gross order value in FY20.

So if it’s possible in B2C, why not in B2B, especially those serving SMEs, which are a backbone of the country and the largest contributor to the Indian economy?

The evolution of Bharat SaaS

So how do B2B startups aim to hit this coveted ₹10,000 Cr revenue target? The answer is simple, you build stickiness through a tech product (SaaS or otherwise), but layer a marketplace on top to drive the revenue.

In a manner akin to the SaaS animals chart by Christopher Janz, but modified to suit the Indian B2B context, we get something like this:

To figure out where you need to sit on the map, evaluate the number of potential customers in your industry, take a general rule of 10–30% market penetration, and see how much annual sales per customer you need to be passing through your platform. Similar to how ACV (annual contract value) is ultra-important in SaaS businesses, Annual Sales per SME is super important in a B2B marketplace business.

Note, when I say SME as a customer, I’m talking about the Buyer in the marketplace, not the Seller.

Placing some of the larger, well known B2B marketplace startups in India on this chart:

Khatabook — a digital book-keeping app. The company already claims 20M registered users, but it is yet to figure out a proper monetisation strategy. Whether the strategy is payments, commerce, or lending — the company will need to make at least ₹10,000 per customer per year to build a sizeable business

Meesho — a social-commerce platform. The company is already having 10M+ resellers (micro SMEs) on its platform, and passes through ₹7,000 Cr GMV of goods through its platform

Udaan —a wholesale trading platform. The company claims to have more than 1M SMEs onboard, and a ₹15,000 Cr+ GMV

Ninjacart — a fresh foods supply chain platform. The company claims to have more than 100k retailers buying ~₹1L of goods per year, giving it a ₹1,000 Cr+ GMV

Infra Market —a construction material marketplace. The company primarily sells construction material to infrastructure projects and transacts with over 1000+ contractor-SMEs, and currently at ₹3,000 Cr+ GMV run-rate

Zetwerk — a contract manufacturing marketplace. The company is transacting with 250+ customers globally, mostly mid-sized enterprises, and is hovering around ₹3,000 Cr+ GMV

While Khatabook and Meesho are busy chasing the micro-SMEs (housewife-resellers and home-store Kiranas), the likes of Udaan and Ninjacart are out hunting the mid-sized traders, wholesalers, and retailers. Meanwhile Infra Market and Zetwerk are out riding Elephants — the large-sized enterprises in the market

I’m sure by now you have noticed an important factor in the image. The missing middle!

While the first set of startups (Meesho, OkCredit, Khatabook, Udaan…) that gained traction in the B2B space were targeting the bottom of the pyramid — the second set of companies (Infra Market, Zetwerk) came in and started targeting the top of the pyramid. This allowed them to grow quickly, much faster than their smaller-animal counterparts.

At STRIVE we truly believe that the next set of scaled-up companies are likely to emerge from — you guessed it — the missing middle…

This means startups targeting the thousands of mid-sized SMBs, making upto a crore per year in sales per customer, by linking goods, services, or customer leads to these SMBs are likely to be the next emerging category of winners in B2B marketplaces.

Already, within our portfolio we are seeing the growth of this category with Classplus, ReshaMandi, Medtrail, SuperK, BuildSupply, with each of them doing business in the range of ₹10L to ₹1Cr with their B2B SME buyer in industries with 100k-1M SMEs.

As a fund, we are spending an inordinate amount of time on the Cows and Tigers category of companies. Using the playbook of our SaaS GTM learnings from global markets, modifying them to suit the local Indian context, we have seen our portfolio come up with exciting approaches to target, acquire, and onboard these SMEs onto their platforms. As you move into the business of targeting the Cows and Tigers, the approach towards sales acquisition and customer identification changes significantly.

In the next few months, my team and I will try to distill some of these approaches, and hopefully if you’re a founder building in this space, you will come forward and share yours!

10 things you need to be mindful of as you construct your ESOP scheme

Founder 1:

“We can’t pay you much salary, but how about $100k worth* of ESOPs?

Fine print: *The exercise price is equivalent to $100M company valuation, which we expect to be valued at in our next round of fundraising”

Founder 2:

“So we just received an acquisition offer, but it’s essentially a fire-sale. You know those ESOPs we offered to you at the time of joining? Well the thing is we never really got around to setting up an ESOP structure. So maybe we can just forget about it and all of us move on?”

Founder 3:

“It’s been 5 years of your service to our firm, thank you for your amazing contributions! Well, as we have not yet exited, and now that your options are approaching maturity, you’ll have to start exercising them.

1. Please pay $50k to the Company for exercising these options worth $1M
2. Do remember to pay the $200k tax bill you’ll have to pay on the unrealised capital gains of $1M

But don’t worry, we’ll help you find liquidity within next couple of years and eventually you’ll be a millionaire!”

Employee 1, 2, 3:

Fu$#! 🙈

All of the above instances are common occurrences in the startup world, where employees end up getting screwed on their ESOPs. Like it or not, ESOPs can be the most valuable or the most frustrating part of an employee’s journey within a startup.

Off late, I have noticed that most early stage startups, even after announcing and committing ESOPs to employees, don’t end up formalising a proper ESOP policy. Part of this is because of lack of admin bandwidth during the early stages, and part of this is due to the founders’ lack of knowledge. So I decided to write a post, hopefully inspiring founders to structure their ESOPs early and fairly, while avoiding some common pitfalls.

1. Vesting

Starting with the basics, it’s important to get the vesting schedule and structure right. This part defines at what pace are employee’s options going to vest, or in other words, at what timelines can each employee exercise her options.

Market Standard: 4 year vesting, with 1 year cliff, and monthly vesting schedule thereafter. What this means is that the employee will not earn any Options till she completes 12 months at the startup. Immediately after 12 months, 1/4th of the awarded options will vest, and thereafter 1/48th of the options will vest every month for 3 more years.

2. Exercise Price

“Stock options are like free money, right?”

Turns out, not really.

Something that is quite basic, yet confusing for many folks: a stock option is not a Share. You have been granted an “option” to purchase shares of the company in the future at a pre-agreed price — the strike or exercise price. The employee has to pay the company this price to exercise these options and receive Shares in return. If the exercise price is much lower than the price at which the shares can be sold —then the option is almost free money.

Example, let’s assume Joe gets stock options at the company’s Seed round valuation of $10M, but sells the shares when the company gets acquired for $100M valuation. In this case,

Joe’s gain = Share Price at $100M valuation — Share Price at $10M valuation

What is confounding for people is that most taxation authorities treat this gain as income, even though it is unrealised. Hence, receiving and exercising these options means you are liable to be taxed.

In Singapore, these gains are taxed at the time of exercising the options. So if an employee waits till a liquidity event occurs before exercising options, they can sell the shares in that liquidity event and (ideally) get some upside after paying their exercise price and tax bill. But if you’re a tax resident of any other jurisdiction, your treatment might be different.

Market Standard: What is the typical Exercise Price? Ideally, and most commonly, it is the fair market value of the Shares in the market at the time of Option grant, usually dictated by the last or ongoing financing round. But some companies use a fixed nominal amount, example a few cents, as the Exercise price.

Important Note: To protect the employees’ interests, ensure that the company can re-price any unexercised Options, whether or not they have been vested, in order to reduce the Exercise Price in case the fair market value of the shares decreases after the Grant

3. Rights of Shares

Assuming an employee exercises their options, they become shareholders in the Company. Does this mean they enjoy all the rights of shareholders, at par with the founders and investors? Typically not.

Market Standard: Stock options typically convert into Ordinary shares that do not enjoy rights such as ROFR, pre-emptive, anti-dilution etc. Further the shares are subject to drag-along rights from Investors (if mentioned in the Shareholders agreement), forcing the employees to sell their shares in case of a dragged liquidity event initiated by the investors.

4. Liquidity Accelerated Vesting — double trigger or single trigger?

This is where we start to go into gibberish territory. An accelerated vesting clause dictates what happens to the ESOPs in case there is a liquidity event (a.k.a. exit) of the Company.

A “Single-trigger acceleration” means that, on an M&A exit or a listing, all unvested options of employees immediately vest, and they can exercise all of their options, receiving shares in the company and thus partaking in the exit. This is obviously employee friendly, and sometimes seen in the market.

Market Standard: But the “Double-trigger acceleration” method is becoming increasingly common in the market as M&As mature in the region. In this method, there needs to be a second trigger for vesting acceleration — the employee being made redundant as part of the exit process. When acquirers buy a company, they typically prefer to retain the existing team, and not let them vest all of their unvested shares. In this method, the employees end up continuing with their usual vesting schedule, under the new company, usually with a stock swap to the new company’s shares.

Now you may think this second scenario is unfair to the employees, but sometimes the exit is contingent upon the management being able to retain the workforce, and without this important clause, the exit might not even go through. To mitigate these situations, I am noticing ESOP schemes in the region conveniently deferring the vesting acceleration decision to the time of exit, making it an eventual decision of the Board to adopt single or double trigger acceleration. Nothing wrong here in my opinion, as long as the board is functioning well, and considering the interests of all stakeholders at the time of exit.

5. Buyback

While it is easier to handle scenarios of clean liquidity events, a trickier situation emerges when an employee is leaving with unvested options.

In the case that the employee is a “Good leaver”, unvested options lapse, but the vested options end up needing to be exercised, either immediately or within a given duration. This definitely puts pressure on the employee to pay the exercise price or forego the options, similar to the case in (2) above.

But even more interesting is the scenario of a “Bad leaver”. In such a case, the company usually retains the power to cancel any outstanding vested and unvested options. Further, the company also tends to have a right to buyback exercised options at strike price paid at the time of exercising the said options.

Now this is obviously taking everything back what the employee every owned or had a potential to own in the Company. The natural question is, what defines such a drastic “Bad leaver”?

Usually this is attributed to:

(i) breach of a employment agreement or corporate policy,

(ii) gross misconduct, fraud or gross negligence,

(iii) misappropriation of Company proprietary information,

(iv) indictment, conviction or plea to a felony

6. Transfer of Shares

As you can see from (3) and (4), options tend to play the role of golden handcuffs. Naturally you may ask next, can the employee transfer their exercised option shares?

Market Standard: Well the answer is usually No. As these shares are Ordinary shares, they usually sit way below the rights of investor, and even founder shares. Companies tend to retain the control on transfer of these shares. On rare occasions, the employees can transfer the shares to:

(a) the Company — if the Company has fundraised recently or has crossed some major milestones and has the cash to afford a buyback,

Example — see Zerodha’s recent buyback of ~$9M worth of ESOPs

(b) an existing Investor — if it is difficult to purchase Primary shares in the company

Example — see Razorpay’s announced buyback of $10M worth of ESOPs

(c) an incoming Investor — if the current round is quite full, and the incoming investors want more ownership than they are getting in Primary shares

Example — see Unacademy’s announced buyback of 30% of ESOPs

All such transfers are normally controlled via the Board’s permission.

7. Taxation and other Liabilities

Assuming that the employee gets to vest or exercise their stock options, this usually generates taxation and other liabilities. (2) above is such an example of a tax liability.

Market Standard: Typically, companies add the following simplistic clause, shirking responsibility in the case of any such situations — “All taxation, stamp duty, levies, penalties are employee’s liability”

It’s arguable whether such a blanket statement is healthy in an ESOP scheme, but given the complicated laws around ESOPs in emerging markets, it is simply a risk the companies are unwilling to take.

8. Option Expiry

All options, including ESOPs, come with an expiry date.

Market Standard: In the case of ESOPs, this timeline is 10 years or lower, meaning that the employee needs to exercise the vested options 10 years from when the options were granted.

But what happens if the company does not exit within 10 years, yet is a large company with significant worth of shares? In such a case employees tend to have no other choice than to exercise their options, convert them into shares by paying the exercise price, and waiting for a liquidity event to occur. In fact this is a situation that has tied up many employees to huge unicorn companies that haven’t managed to find liquidity yet or announced buyback programs.

9. ESOP Trust

One interesting challenge occurs in executing ESOPs in younger markets such as Singapore. Singaporean private companies cannot have more than 50 shareholders, and as ESOPs get exercised, the employees end up becoming shareholders.

Market Standard: As a result, a trust usually gets created with the Board’s approval for allowing employees to be shareholders but at an arms-length distance. This trust, and the expenses for the same, are managed by the Company.

10. Authorised Leaves or Sabbaticals

What happens to the vesting timeline in case of longer-term leaves, say maternity/paternity leaves? What about sabbaticals?

Market Standard: In such a case I have seen Companies taking a humanitarian stance towards vesting. Unvested Options continue to vest as per the vesting schedule in case of authorised long leaves/sabbaticals. But in the case of voluntary time-offs for longer durations, the Company tends to have the right to alter the vesting schedule accordingly.

So there you have it: 10 common pitfalls to be avoided when structuring the ESOP.

Important Note: Do not treat any of the above statements as legal advice. If you’re all excited to set your own ESOP scheme up, do consult a lawyer who can help do this for you for a nominal price. Eventually, you will need your Corporate Secretary to adopt the ESOP scheme for you.

If you want to skip the legal help, and want to stick to standardised agreements, you can run with some online policy templates, example Kindrick Partners’ great guide and template on ESOP scheme in Singapore. One thing to note is that unlike mentioned above in (4), Kindrick’s template goes with a Single-trigger accelerated vesting, which they claim is more common in Singapore, but I have personally seen less of.

Another law firm, Cooley Go, has a great article on ESOPs as well, but they don’t provide a template scheme as of now.

If you do come across other templates, or have follow-up questions, feel free to DM me.

My previous post on Community-led Growth (CLG) was one of the most read posts on the blog 🙏. Many founders and growth marketeers reached out to discuss, share their opinions and ask questions. As I went through these conversations, I realised that there are lot of unanswered questions on the topic, the most common of them being “How do I replicate this within my product/company?”. So I decided to list five simple questions you need to answer to be able to initiate Community-led Growth within your company and I call this the 5-C framework.

Step 1: What is going to be the Core of the community?

As I mentioned in my previous post, what distinguishes a community from a network is the common interest or goal that aligns the community, where members want to benefit from as well as contribute back.

To be able to incite this contribution you have to unearth what will the members really care about i.e. the Core. Remember to keep the Core niche enough to attract the right interest!

As an example, our portfolio company Hasura built its community around GraphQL, and not backend development. It was a niche enough topic, that developers looking for content or help on GraphQL reached out to this community for. And there are very active members who want GraphQL to develop into a default protocol for backend-frontend middleware, who actively contribute back to this community.

Step 2: What is the right Channel to use?

Once you have figured out the Core of your community, you need to understand what’s the right Channel to bring your community together on. This feels like an easier question to answer, just think where your potential members of community are usually active, and use that as a Channel.

A rookie mistake though is to limit this to your own website. If you don’t already have high active engagement on your website (how will you if you never formed a community?) then this is a bad idea.

An easy question to answer here is whether you need community contributions to be asynchronous or synchronous.

Another thing to keep in mind is that the contributions, deliberations, debates within the community should be easily discoverable by members outside the community. Frankly, this part is not yet solved in most of the platforms above unless you use forums-based tools.

Step 3: Who will be the early Contributors?

Once you have figured out the right Channel, it is time to think about the early Contributors. If you have the Core right, finding early engaged members for the community should not be hard. But what is hardest is to find members who will contribute back.

As a result, you have to start parsing carefully through your early community members to find those who are highly engaged, have a lot of energy, are not bogged down by too many other engagements, and are willing to co-create this community with you.

You also have to figure out, what’s the optimum size of your initial community? The answer to this is a bit unclear, as not many successful examples exist, but in my experience I have noticed that 10–20 initial engaged nodes are enough to get the community rolling to a few hundreds of people in a short span of time. My intuition says this is due to the 3 degrees of separation that usually exists between common interest group of individuals, resulting in 20 members compounding to hundreds/thousands in a short span of time.

Most communities during their scaling journey do need to cross the chasm, so be prepared to to push the community beyond the tipping point by having a sizeable initial audience. Too large, and members don’t find meaningful connections. Too small, and members don’t find meaningful content.

Step 4: Who will Coordinate all the efforts?

Once you have your early Contributors onboarded on their preferred platform, it’s time to seed the community. Of course the initial Contributors will start doing this, but you need Coordinators, a few individuals who orchestrates the discussions on the community. These are usually your own team members, because they know which direction to take this community towards, but can also include some close associations within the community.

In my experience, there should be at least one founder involved in the Coordination efforts in the early days.

Some times this might take up to 30–50% of the senior management’s time, but you’ll find the invested effort showing ROI in relatively short-term compared to Content and other such marketing initiatives.

Step 5: How do you maintain Consistency?

As you start seeing some green shoots of success, you have to ensure that the Community doesn’t spiral into the death valley. Often, members join in with high expectations, get disappointed with the content or community engagement, and leave, likely to never come back. This is where Consistency becomes a key for sustainability. You need to ensure that the community starts flourishing organically. What topics will seed discussions and collaboration? Pay close attention to what initiates healthy debates in the community, those are important topics to keep talking about.

As an example, if you are using Slack, you can build channels to sub-categorize a lot of conversations that start bubbling up naturally in the community.

This requires concerted effort from the community managers, calendaring an inorganic schedule of content, but also jumping on any organic opportunities to build engagement. As you put in this effort, also start asking yourself —

How can you make yourself redundant and let the community flourish organically?

And there you have it. The 5-C framework to jumpstart your CLG — Core, Channel, Contributors, Coordination, Consistency together all of them yielding a nice bubbling cauldron of Community.

I know it sounds easy. I also know from experience that it is very difficult to execute, so all the very best on your Community efforts. If you have any other requests of content I should write around CLG, or if you have any questions on the same, feel free to message/DM on LinkedIn.

Yesterday, our portfolio company Hasura announced their $25M Series B round, led by Lightspeed US. It has been an eye opening ride for me personally, seeing first hand how large and scalable devtool companies can be built from any part of the world.

We are seeing a wave of new DevTool companies come up in Asia, mostly from India. This year our deal volume in the sector jumped to 4x already, and likely to end up at a significantly higher number. Bear in mind these are only the companies from Asia that we have evaluated for an investment. The likes of Postman, Hasura, Druva, and BrowserStack are already giving confidence to more developers in India to step out of their comfort zone and start building for other developers.

One thing though that has been plaguing me this year is the fact that most of the founders are quite nascent in their thinking and approach towards DevTools GTM. A developer is not a trained marketeer. Devs love building, but they usually find it challenging when the time comes to market their product. And hence I thought of writing this post, packed with insights I have picked up along the Hasura journey.

The three pillars of Dev Tools GTM

Dev tools marketing strategies are notorious to be truly bottoms-up. A developer customer tries to go beyond PR bullshit, and only adopts or buys when she sees real value. The following three pillars have evolved over time to be the default GTM for companies in this space. Post COVID these trends are accelerating even more.

1. Content

Typically dev infra companies start off with a content strategy. I might be stereotyping, but developers are usually shy and introvert. Heck I am one of them and have spent all my early career amongst these geeks. Naturally, it’s harder for devs to go seek out other devs to give them product feedback. Instead the easier initial marketing strategy employed is to build a product to solve a personal pain point, write some content around it, and voila, there are some users.

a) Blog/Tweetstorms
This content type is written on dev-specific channels. It can range from your Company Blog, Medium, Substack, HackerNews, Dev.to posts

Pro tip: Check out tools like BuzzSumo where you can search for content that is doing well in your space, either posted by your competitor or that incumbent you’re disrupting. It works great for generating new content ideas and pre-empting what the audience wants to read!

b) Q&A
Answering questions related to the topic you are building on Stackoverflow, Reddit, HackerNews, and other such channels helps make you a KOL in the space. Most devs already employ this strategy when starting up. Once you have scaled a bit, typically you’d use a team of DevRels to help do the same thing.

c) Events (Offline or Virtual)
This space is becoming very interesting. Typically devtool companies used to host, organise, sponsor dev events around the world. Founders would fly from conference to conference, taking up speaker engagements to spread the word.

Post COVID, all of this has gone digital. I am very confident that Dev events have switched to digital for good. Companies big or small are struggling to get their act together on this new format. As a small company, you can curate the right speakers and audience with minimal budget, and end up shocking some of the incumbents with the results you generate.

Pro tip: The newest kid on the block is a Twitchstream to walk your users through a live session of your product. Go into depths of your product, while getting feedback from your users live.

Check out HashiCorp’s Twitchstream where they run regular dev streams

2. KOLs

Another strategy that a lot of dev tools companies use is targeting KOLs/influencer devs in their space. By hook or by crook, you end up involving these “top devs” who enjoy almost demi-god symbolism in their dev circles.

Firebase went through this approach of targeting KOLs in its early days.

Twitter is obviously the best channel to target these KOLs. But involving them into a conversation is not easy. While ProductHunt is good for getting some initial users on your product, it doesn’t necessarily bring you very strong KOLs giving you their opinions on the product.

ProTip: HackerNews is a great first step if you don’t know where to begin. Use a Show HN tag and off you go. See Hasura’s original HackerNews post on building a BaaS (Hasura product before the pivot)

3. Community

Save the best for the last.

Last week I wrote about building a Community as your growth strategy. As I wrote in my previous post, Community is a great growth strategy if you can find a group of like-minded people willing to contribute back into a topic alongside benefiting from it.

Hasura itself has taken a Community-led Growth strategy. “Continue investing in our community” is the #1 focus area for Tanmai, CEO of Hasura. It was a major reason for Lightspeed’s recent investment into the company as well.

Over years, building a community has naturally evolved as a must-do in the dev ecosystem, mostly thanks to Open-Source.

Elastic, MongoDB, Grafana, Discord, Postman, Hasura, TensorFlow, Kubernetes, PostgreSQL are just some of the examples that come to mind. There are hundreds more.

Hasura embarked on this community journey from Day 1. They started with open-sourcing their GraphQL engine, and eventually built a Discord community around it. Today they stand at 18k+ Github stars (for perspective, k8s is at 70k) and 7000+ Discord members.

But open-source is not a must have to build a Community around your product. Many successful companies have done this by treating their developer user-base as partners on their journey.

Unity, which recently filed an S1 for their IPO, is a platform for Game developers, with a strong community layer being built since 2016.

Pager Duty has been running a similar developer community since 2017. Starting from a blog and a forum, it later expanded to partner integrations, guides on DevOps, and frequent guest speakers. It’s not a coincidence that PagerDuty enjoys great developer love.

Do remember, all of the above strategies are tools in your arsenal to reach your audience faster and better. You can take any combination and order of these, best suited to your company and your own strengths and weaknesses.

Let’s Build!

Community — the condition of sharing or having certain attitudes and interests in common — Oxford dictionary

I’m sure you have all heard about Product-led Growth (PLG) taking over Marketing and Sales-led growth. It’s so engrained a philosophy in the tech community that most of the people can’t even remember a time before PLG.

While PLG is the leading example of product and growth strategy in today’s age it’s not very clear for most people what the right GTM approach is to combine with PLG. As a result, people resort to Content or Paid marketing to get to their market. For the last year or so though, we have been seeing a big underground trend emerge in our portfolio companies — growth coming from building Communities. While very new, Community-led Growth (CLG) has helped these companies accelerate rapidly, especially during COVID, all the while creating formidable moats in the business. It is still Day 1 in this journey, but given that there is very little being written or said about this trend, I thought of writing a few examples and nuances for others to benefit from it.

So what is a Community in the digital sense?

An online community can act as an information system where members can post, comment on discussions, give advice or collaborate — Wikipedia

You might be wondering, yes we have been building and participating in Communities since the age of Social Networks. And aren’t Facebook and Instagram communities in their own rights? Yes and No. What differentiates the communities I am talking about is that they are not just a social network that has people bringing their existing relationships onto the digital platforms and enhancing them.

Instead, a Community is formed out of a group of people helping, advising, collaborating with each other towards a common interest or goal. There are two key aspects to this:

1. An urge to contribute to the community

2. The perception of benefitting from the community

As you can see, a community differs from a network with the common goal or interest that brings it together. As an entrepreneur, it’s your job to align the goals of this community with the goals of your business.

A true community is characterised by High Engagement, Members acting as Leaders, and light-touch Moderation. These communities are organic, brought together by the sponsor, but then left to flower on their own with minimal supervision and sustenance required. Here are some examples of companies who are leveraging their communities as they grow.

Why are Communities so important?

While following Product-led Growth helps you build the right product for your customer, it doesn’t help you distribute and reach your customer. We have seen many companies struggle to scale while having a good product that works for a niche of customers. This is where CLG comes in.

There are a few main functions where your Community comes handy as you build your business:

1. Acquisition (Marketing)

The community’s growth is a natural addition to your top-of-the-funnel (TOFU). It’s a 0 CAC, organic channel that you create, naturally evolving over the life of the community.

Our portfolio company Raena leverages its community of personal-care and beauty sellers for its organic growth.

From the start of this year the team adopted a community-led growth strategy. The result is very clear. While most companies are struggling to maintain their numbers during COVID, Raena has seen an astounding growth (30%+ m-o-m) with no marketing costs. As you can see in their growth chart, this has come in step with their community member growth. The company is now profitable and on a very solid path to success.

2. Retention (Customer Success)

The community also plays a big role in supporting each other and reducing the reliance on customer support or success functions to onboard, prove value and retain your customers.

Our portfolio company Hasura has been using it’s Discord community for ages to help onboard, guide, and ramp-up users on its products.

Most, if not all, customers come from this Discord community and has led to eye-popping ARR growth for the company on the back of expansions. Best part, companies are already users of the product even before they become customers, thanks to the Community educating them on product and onboarding.

3. Feedback (Product)

Probably the most under-rated aspect of a community is their ability to provide direct feedback, at scale, straight to the company or its leaders. As an organisation grows, it becomes harder for Product teams to have an ear on the ground. The CLG engine should feed directly into your PLG engine.

Product companies have for the longest time sought direct feedback from their users in the community. It’s likely the most natural way of building your product. For example, see how Ryan Hoover from Product Hunt made product decisions by asking the community.

4. Business Moat

Besides all of this Community naturally creates a moat for your business. In fact, one can argue that a big reason behind the acquisition of Github and ProductHunt was the large scale and engaged Community they had managed to build.

How to build this Community in your Company?

Now that you might start believing in the power of a Community of your users/customers, a natural question would be “How do I replicate this?”

Expect a separate post on this topic, but while we are at it, there are numerous tools and platforms you can start leveraging on to initiate this Community journey in your own company.

Platforms such as Meetup, Slack, Discord, Commsor, HeySummit, Icebreaker.video are all great places to start.

Start small, have the right intentions, and grow…

On a side note, we are very excited about tools and platforms being built to manage such communities, be it a dev-community or generic. If you are building something in this space, do reach out to us! You can ping me on LinkedIn or Twitter.

Want me to write about tips on building a community from our portfolio companies? Shout out below!

It is Day 56 since the Singapore 🇸🇬 circuit breaker was announced and I have already lost count of the days since I stopped going to office. If there is one thing that I look forward to every afternoon though, it’s that evening run 🏃‍♂️ 🏃‍♀️ where I can zone off from work 💻 and tune into something else.

During these runs, especially when I’m alone, I have started renewing an old habit: listening to podcasts 📣. Call me a workaholic, but these podcasts are not just for fun, they are centred around the Asian startup ecosystem. What better way to zoom out from the daily work routine than by getting a macro perspective on varying topics affecting your startup ecosystem?

Let me start with my favourite podcast of all: Masters of Scale. Reid Hoffman’s deep and articulate voice, questioning some of the world’s best entrepreneurs, interspersed with Reid’s thesis and analysis, gift-wrapped with Hollywood-level post production, podcasts can’t get better than this. Unfortunately, not much, if at all, of the content here is Asian and hence around a year ago I decided to discover similar stuff in the land of the billions.

It took me a good year or so to curate these podcasts and as I did not find any lists out there talking about relevant Asian startup podcasts, I thought I’d enumerate 10 of them that I specifically listen to, while giving some feedback on each to help you decide the ones you might want to subscribe to yourself.

1. Accel INSIGHTS Podcast by Accel Partners, India

Created by Accel Partners from India, this is one of my favorite podcasts to listen to mostly due to their deep dives into SaaS industry. The podcast tends to feature the who’s who of Indian ecosystem with some great lessons from star founders. Occasionally it features senior partners from Accel India giving their opinions on all things tech.

2. Evolving for the Next Billion by GGV Capital

Previously known as 996, this is a highly popular podcast by GGV Capital. In-depth conversations with some of the best Chinese and now other Asian, founders, there is never a dull episode to this podcast. Hans Tung’s nimble thinking combined with an analyst’s thoughtful questions keeps the content engaging, although a bit longer than typical podcasts. It’s also fun to mentally spar with the thesis of the famous VC firm.

3. Tech Buzz China by Pandaily

If there is one podcast that I can rely on to give me the most transparent version of news on China, it’s this one. Rui and Yingying, the podcast’s popular hosts, unearth meaningful and intricate stories on popular startups and sectors from China. While there are usually no guests in this one, the hosts have perfected the art of building engaging audio content with stories frequently weaved in and concluding summaries. Coupled with business model evolution of growth stage startups and unicorns from China, this is my favourite way to learn more about the Chinese ecosystem.

4. 100x Entrepreneur by Siddhartha Ahluwalia

Among the longest running and most consistent podcasts from India, it features the up and coming VCs and entrepreneurs from the country. While the content can be long and monologuish sometimes, overall I like the honesty and candidness of the speakers.

5. Building it Up by Bertelsmann

Ankur Warikoo, a well-known founder from India was hosting this one for the longest time. For the last few months the show has been a bit inconsistent with it’s episodes though. That said, it tends to host a lot many serial entrepreneurs from the Indian startup ecosystem.

6. GOFIGURE by GoJek

It’s one of the few podcasts coming out of Indonesia. It is also one of the rarer occasions where a growth-stage startup talks about the ecosystem and company building at large. Nadiem Makarim, Indonesia’s most celebrated startup founder, used to be a regular host. They haven’t posted an episode since November 2019, but even the older content has unique insights into the build-up of a unicorn in Southeast Asia.

7. ASIA VC Cast by Daniel Song

Another of those podcasts that seems to be weakening in terms of new episodes, but started by Daniel Song, a VC-turned-founder this one covers short sessions with investors from Southeast Asia. The library of existing content should be enough to get you upto speed with what’s happening in the region.

8. Upside Town by Yash Sankrityayan

One of the freshest podcasts in Southeast Asia started by my good friend Yash from Jungle Ventures, this is the newest and currently the most active podcast in town. Looking forward to more fresh content here!

9. Startup Snapshot by TechInAsia

When scouring for more content, it’s hard to miss the biggest tech media company in town — TechInAsia. This podcast, while featuring journalists’ point of views on startup topics, is probably the only one in Asia that comes even close to the post-production levels of Masters of Scale mentioned above.

10. Asia Tech Podcast by Graham Brown

And last, but not the least by miles, how can one miss Asia Tech Podcast? With well over 500 shows and counting Graham Brown has interviewed probably every possible founder and VC you have heard of. I guess he’s giving things a pause for now, but I hope to see this one return soon to the mix.

And that completes the round up of the top 10 Asian startup podcasts list. Do note, lower ratings ⭐️ from my side doesn’t necessarily mean that the content is not good. It’s my very subjective opinion comparing each of them. Regardless of the ratings, I like all these 10 podcasts and regularly listen to them. I’m also thankful to the creators, hosts, and guests for sparing their time to create and provide this content for free, for our benefit. Keep hosting!

Not just another “conserve your cash because of virus apocalypse” post

By now you have likely read all the doom and gloom memos and posts floating around in the US tech industry. Sequoia’s Black Swan memo, Fred Wilson’s Market Meltdown post, Mark Suster’s Funding in the Time of Coronavirus slides are just a few of them.

Here is the TL;DR.

Is Coronavirus the black swan of 2020 that leads us to a recessionary phase of the cycle?
It seems to be.

Will this impact your business adversely?
One way or the other, it will.

Is Asian fundraising environment going to be affected also?
Most likely yes.

Can you do something about it?
You sure as hell should hope so.

Now I have read the Sequoia memo same as you have. Frankly, the advice in it left me highly motivated albeit a bit wanting and confused as to its relevance. The memo talks about runway (increase it), fundraising (remove the need), sales forecast (make it), marketing (rationalise it), headcount (reduce it), and capital spending (evaluate it). Now all of this is great if you were a Sequoia (read any big fund) portfolio company, but based on probability you are likely not. Hence if you are a NORMAL startup founder who has raised a few dollars or none, then fundraising was never easy, runway is always too short, sales forecasts are rarely accurate, marketing is peanuts on a dollar already, head count of the team lies at 10 including your dog, and capital spending is Swiggy/GrabFood delivery. Umm, sorry to be asking this, but reduce what and increase what?

It’s unlikely that you’ll be able to bring a drastic change in your business or in your financial situation in the next few weeks. You will be affected by the externalities regardless. But in fact, the biggest risk that you likely have is internal, not external.

What happens if one of the team members in your tight cosy office contracts the virus? Do you shutdown the office? Do you switch to remote? How do you control the spread? How do you keep running the business?

Seeing the virus growth unfold in Singapore for the last few weeks and the actions taken by the government, I have realised that IT IS possible to control the spread and impact of the virus, even on your business, if you build the right operational playbook. I thought of penning down a few pieces of actionable advice ranging from team management to cash flow planning that we are discussing in my humble portfolio catchups/board rooms.

1. Build a Continuity Plan

First and foremost, I urge you to devise a plan to tackle the situation that the virus hits one or more of your team members. If I were you, I’d be building this plan in the following way.

Plan A: 0 infections in the team
Plan B: 1 to 2 infections in the team
Plan C: Multiple infections in the team

The tools in your arsenal then are carving out affected teams from the main team.

Sub-team: In this case, cordon off a functional team either on a separate floor or a separate location. See how this impacts productivity for a few days and change accordingly

Division Rotation: When the virus started spreading in Singapore, DBS implemented a Business Continuity Plan where a third of the entire DBS office was working from one office, another third from another office, and the final third started working remotely. This limits the risk to certain pools within your team, and you’ll have continuity of business for the medium-term. Remember that the virus doesn’t severely infect most people, hence you should expect affected individuals back on their feet in a short while.

Fully Remote: Some of my portfolio companies have already shifted to fully remote work. If your sales are done via inside sales calls, and your functional teams are still small, this is likely an easier option for you.

Handling remote work is not easy. See some of the recommendations on the same in this report and this post.

At the minimum I recommend asking your managers/VPs/team leads to start figuring out a plan to move their team to remote work on urgent notice without impacting the business severely. Maybe even ask them to do a test run for a few days. If you are interested to learn more, see Enterprise Singapore’s BCP guide.

2. Build a SWAT team

If your team does get affected from the virus you’ll likely face massive disruptions in the internal workflow. At such a time, you’d need a SWAT team that goes in and fixes fires. Choose a set of folks (around 10% of your overall workforce, if you’re 10 people, yes it’s likely going to be you) who’ll cover up these holes and gaps. The team should ideally be made of people who can wear multiple hats quickly, would be willing to work the extra hours apart from their usual role in the company, and know the company’s business end-to-end well.

3. Build Redundancy in the team as long as your Cash flows allow

Nature’s best way to tackle black swan events is redundancy. There is a reason humans have two eyes, two legs, two arms, two kidneys, and two lungs. These redundancies in the body are there to protect you in case of black swan risks. It’s counterintuitive but now would be the time to add a bit of redundancy in your team. Likely your next question is, where do we get the money to build redundancy? Well, I’d suggest instead of hiring an expensive resource at this time, you might be better off hiring two inexpensive resources for the same work. I’d recommend building 110–120% bandwidth for all the client facing, field, operations roles at lower cost resources. Net net, you’ll end up at the same burn, and if things don’t go for the worse, you’ll eventually grow into the extra capacity you built.

4. Build Redundancy in your supply chain

If your business depends on cross-border trade or a few critical suppliers, now is the best time to start building multiple supply chains. You have no clue when the vendor supplying you from a certain country or city disappears off the grid due to lockdowns or manpower crunch. Have a couple of fallback options for every critical piece of product in your system.

5. Build Redundancy in your customer base

Try to reduce over-reliance on a small set of customers. If you have very few customers, focus your energies on closing new business in the next couple of months, instead of chasing account expansions. If you can target new verticals/markets, now might be a good time to experiment on those to protect you from geographic/concentration risk.

6. Collect faster

Almost all B2B businesses have a collection cycle. In normal times you’d be fine with slightly delayed collections or longer payment cycles. But right now you should be dedicating bandwidth towards collections. The virus has not impacted cash flows for most companies yet, so you should be able to collect. This will also prevent any collection write-offs, bad debt.

7. Move costs to lower-cost-base markets

One of the easiest steps for companies who still want to grow their teams during recessionary times is to spin up remote teams in lower cost-base countries. You can keep these teams in-house or outsource completely depending on criticality of tasks. It’s an easy way to replace that next expensive hire with 2–3 inexpensive remote employees. You can try this for less critical feature engineering such as integration implementation or even less critical customer support.

8. Cut G&A expense

If you read my blog, this is my pet peeve. Now would be the best time to let go of the fancy office, free lunches, yada yada you have been spending on with not much avail. It’s easy to justify it to your team at these times, and it will do you good in the long run till the point you become self sustainable or are in control of your destiny.

9. If fundraising, be clean and quick

Start thinking of 1 month fundraise process rather than 6 months. Go in, test the fundraising waters, and if they are too cold, jump out and drop the plans. You’ll know within a matter of a month how your story is doing in the market and whether investors are likely to move in next few months at the price you’d like to raise at. If the price is substantially under your preferred price, raise less for now and wait for the markets to improve. At least you preserve dilution.

10. If you have raised debt, be extra cautious

With even predictable cash flows at risk in such times, repaying debt is the hardest of things to do. Try not to rely on debt as a cash flow source for the near future. If you already have debt, then set aside interest repayments and principal properly to bake it into your runway. You can even try to renegotiate your debt earlier rather than later if you foresee yourselves missing any repayments in the future.

These are my top 10 based on recent discussions with portfolio companies. If you are implementing any others steps in your company to brace for impact, please do share in the comments below and help us all!