Akshay Rangasai
 minutes ↗

Product led growth as a concept is making the rounds. Investors cannot get enough of it, Twitter is filled with threads about this topic, and many dedicated channels and podcasts are talking about this “new” growth paradigm. However, product-led growth is not something new and has existed for ages. The internet and digital products (Tech companies - Primarily SaaS and consumer internet) have brought this in focus. Growth in organizations has always been tied to marketing and sales, but product-led growth forces us to change that perspective and think about organizations differently.

In this post, we will explore the history of growth for companies, the rise of product-led growth, and why the key to driving it is to think about engineering and product teams as revenue generators rather than just cost resources that need to be allocated optimally.

How the internet changed growth for companies

Historically, the three key pillars to driving growth are Price, Product, and Distribution. Price and product dictate demand, while distribution ensures products are available to satisfy demand. The new world with digital products changes a little bit but with massive consequences. Nevertheless, to understand why we need to focus on product as the key driver of growth, we need to dive into the history of product development and how businesses monetized products.

Before the advent of computers, most of the real-world products were physical objects that needed to be manufactured, priced and distributed. Product development took ages, manufacturing took as much time, and as if this was not enough, you needed to find distributors to distribute products. Computers solved this problem by making each step easier and faster and created a whole new category of digital products.

The software was quicker to make and did not have the manufacturing overheads, but distribution was still a problem. The other big problem in both models was the product itself. You did not know if the product was good or not till you bought it. The ability to have information to make sound product decisions was again constrained by distributing a publication (Like Gartner). If you subscribed, you got it; if not, you didn’t. This meant that product development was a cost, and sales and marketing were revenue-generating functions. Distribution was key. Most companies treated engineering and product as allocated resources, and sales took a lot of the value generated from selling this product. This was just how the old world worked.

The software also hacked the working capital cycles that plague most manufacturing companies. Not only do you need to set up the infrastructure and pay wages to workers, but you also had to foot the bill for each item being made, and then you made it back when selling the product. As your company scaled, so did the requirement of capital. Scaling rapidly was not just a function of people but also a function of how much money you had, or how many loans you could get to foot this bill. Software hacked this cycle; it was infinitely distributable, without any additional cost of production. If you had enough distribution, you could scale easily. The collection cycles also made the companies cash-rich and did not need as much money as other product companies to grow.

Then came the internet. While you can claim that the internet made distribution cheaper, it isn’t really clear if it did. It made distribution faster, but discovery (of products and customers) was still an unsolved problem. Gartner subscriptions came via email and mail. Search engines made distribution cheap. Discovery, which was one of the hardest problems to solve, got solved because of the speed and reach the internet offered. AWS made software development cheaper, you did not need a boatload of capital to start a software company. Gartner is getting replaced by Capterra and G2 for the same exact reason of discovery is cheaper, as is distribution.

All the constraints that existed before to make sales the top dog in a company have been eroding over the years. These advances have made it a level playing field (for the most part). Information availability (G2, Capterra), near 0 cost of distribution and setup means that the only way a company can differentiate itself significantly from competition and win is through product.

The new role of engineering in product-led companies

Cloud computing has made CI/CD possible, and this rapid iteration helps create value immediately instead of long product cycles. Every new feature that is released is monetizable almost instantaneously. Your engineering and product organization is directly contributing to revenue in a measurable way. This is not just an account expansion, or user acquisition focused growth; Retention is also significantly affected by your product's quality. Retention is the first step to growth.

Engineering has always been an expensive talent in organizations. Whether it was for silicon chips or software, it was a scarce skill always in demand. The old paradigm of product development classified these skills as costs, making sense in that era. However, for product companies selling software and other digital goods, engineering should be seen as a lever for revenue generation.

Newer organizations, especially in software, still treat engineering as a cost and allocate resources based on the cost that is saved by deploying this skill across the organization. Thus we see 100s of companies building their own recurring subscription infrastructure when multiple SaaS companies exist to solve this problem. Non-customer facing development improves efficiencies within the organization, but allocating the same resources to customer-facing development could potentially have a significantly greater RoI if internal tooling is handled by other bought software or potentially spending as little time as possible in building internal tools (Non-customer-facing software).

What we think this means is that org and incentive structures need to change. It is not just a sales and marketing team generating revenue but also teams of product managers and engineers responsible for revenue growth. This may sound too harsh given how teams are structured now, but with better focus and newer org structures, this will only seem natural.

Our experiences and conclusion

We think it is time for companies to rethink their build vs buy decisions and consider product and engineering revenue generators. Opportunity costs in whatever form must also be taken into account while making these decisions. In the new age, the product will determine the winner, and it is essential to align your teams on this mission.

Our experience building Appsmith has yielded disproportionate returns by keeping engineering’s primary focus on customer-facing features and requests. We are seeing impressive growth over the last few months with pure product improvements and additions (support is included, of course, by our engineers!). Maybe we were lucky as we are building an internal app builder, and our team was forced to eat our dog food, but this is something that we believe has worked well for us, and we think other organizations should consider it more seriously.

If you have any questions, suggestions or feedback, please feel free to share it at

Cover Image Credits: Photo by Isaac Smith on Unsplash

Building a Github Star Tracker for your Open Source Project

Building a Github Star Tracker for your Open Source Project

Building a Github Star Tracker for your Open Source Project
Akshay Rangasai
 minutes ↗

Github interface is not very convenient to track the stars of your open source project, and it needs a lot of clicks, and hard to access all required information. We at Appsmith, as an open-source project, always wanted to keep track of our stars and see who is interested in our product. So we built an application using Appsmith to see the profiles of users who starred our repository. In this tutorial, we'll learn how we can build this star tracker app in just 10 minutes.

The Idea!

  • This star tracker application has a table to show a list of users who have starred a repository.
  • A container that shows more details of selected users like Name, Location and Company.
Check out the live demo of the app here.

Building the Application

To begin, you'll need to sign up for Appsmith (it's free!). If you already have an account, sign in and click Create New to create a new application. Name the application as Github Star Tracker.

Now, we will start with the output - what do we want to see and where? Appsmith makes it super easy to do so. Let's start with a simple text widget to display number to GitHub stars for the Appsmith repo. Next, let's add a table widget so we know what data we want to see. We will make the application more complex as we progress. We'll name this table starred_users, and it is essential to remember this name, as we will use this to reference queries later on.

Gif One.gif

You can see that Appsmith auto-populates the widget with sample data to show you what the render looks like. Once we set this up, we will dynamically change the content in the widget.

Using the other widgets in the widgets pane, let's create a user profile section to the right of the table. We're using Text widgets for this. Let's start with username, company and location as these are very common in Github.

Image One.png

That's it. We have a view. Now we need to bind data to the widgets.

Displaying User Data in the Table

To display data in our table, we need to bind the widget with a data source. This involves two simple steps, and an optional one for more control on what we'd like to display:

  • Create an API call to Github that returns the list of users who have starred the repository
  • Bind the API to the table Starred_Users
  • Transform the data using Javascript as necessary

Let's start by setting up the GitHub API,

We will use the public Github API endpoint, which doesn't require authentication, through a GET method from appsmith.

Now click on the + icon next to the APIs section on the sidebar and click Create New. Let's call this API Fetch_Starred_Users in the URL request input, the method is GET and we will use the URL constructed from Github's API documentation.

For the public GitHub API, we need to add the header telling them we're an app that is accessing v3 of the API and expecting a JSON response. We'll keep the params empty for now, and revisit it once we extend the application.

Accept : application/vnd.github.v3+json

Now click on run to evaluate the response to make sure this is working fine. Once this is done, this is what your API page will look like.

Image Two.png

Awesome, let's bind the API into our table.

Binding data to our Table

In the table widget, click on the settings icon, and in the table data field, we remove the sample data and instead fill in:

{{ }}
Appsmith uses moustache to process Javascript, and thus in any input, content in between the {{ }} is evaluated as a Javascript. The table widget expects an Array of objects as its input, and automatically displays it.

We can immediately see the table populate. Appsmith interprets changes in real-time and reflects the state, making it much simpler to build the apps.

We now have a table that displays a list of users who have starred our repo. But as you might have noticed, there's a lot of unnecessary information in the response for our viewer. We'll transform this data so we just see the username of the user.

Transform Github Results to Display Login Details

We can use native JS to transform data in Appsmith. In this case, we will use the map function to remove unnecessary data that is returned, and only display users and their logins.

In the same table, we change the earlier moustache content to:

{{ => {
      return { UserName: row.login };

We can see how that instantly changes the display here. We can also extend this and display what you'd like to display relevant in your app.

And that's it! We now have a view that calls an API and displays relevant data to users. But how do we go from here and display user data? We'll do that in the next section.

Going from View to App

Right now, our application doesn't have anything but the placeholders to show basic profile data. We're missing multiple things:

  1. No API to fetch profile details
  2. Connect table click to profile details
  3. Display profile details after API runs
  4. Paginate the API and get the full list of user profiles

Now, let's fix them starting with setting up profile API.

Setting up the Profile API

Github offers a very seamless way to access user profile details through their API. From their API resources:{{"Username of User"}}

The {{Username of User}} is a variable that we need to share with GitHub to respond with the right response. We can do that in Appsmith by using Moustache and passing it as a parameter to the API.

Let's create a new API called Github_User and in the URL we have a GET request with the following parameters. Appsmith offers an intuitive selectedRow method for us to pull relevant data from the view.{{Starred_Users.selectedRow.UserName}}

Our API should look like this after clicking on run.

Image Three.png

Now with the API in place, we need to modify the view to show the data that the API returns. But before we work on the view, we need to make sure that the API is called whenever somebody clicks on a table-row.

Appsmith has an inbuilt property that does just that. In the Table widget settings, update the onRowSelected field to run the Github_User API.

Image Four.png

To update text in the user profile text boxes we'd created before, change the placeholder text from User Name to:{{Starred_Users.selectedRow.UserName}}

Repeat that for the rest of the fields and we'll have something that looks like this:

Image Five.png

Now we're able to click on a row essentially, and we'll immediately see the profile basics of the person who has starred our repo.

The Github API responds with only 100 profiles, and we'll have to paginate the rest and request this data each time. Appsmith lets us do that smoothly.

Paginating Github Response to Pull Profiles

To start paginating, we must enable server-side pagination on our Table. This will help us programmatically call the pages to Github and get more responses.

Image Six.png

With this enabled in the Fetch_Starred_Users API, we'll need to pass the page parameter, as described in the Docs.

In the API screen, we add the page parameter to the request:

page : {{Starred_Users.pageNo}}

The final API page should look like this:

Image Seven.png

Now we go to the app and check if our pagination is working, and that's it! We now have a full-fledged application that pulls data from Github and helps us see who and where the users who have starred our repo are from.

Lastly, let's add an API that fetches the count of Github Stars for the repo, for this let's create a new API and name it as Start_Count. Add the following URL in the input box:

This URL will have the attribute stargazers_count from which we can get the count of the total number of stars on the Github repo. Now let's bind this variable on the text widget on our Page. Below is the screenshot:

Image Eight.png

Wrapping Up

Deploy your application on the cloud and share it with others, and that's it. We're done!

If you are more adventurous, you can extend the app to set parameters on how many users you want per query and have an input form that helps you dynamically check and explore user profiles of starred users on any repository.

We have made a slightly more robust application public here; try it out and let us know what you think. You can also check the live demo of our app here.

If you have any questions or feedback, join our discord, or write to

Cover Photo Credits: Photo by Markus Spiske on Unsplash

Building Our Community while Building in Public: Learnings at Appsmith

Building Our Community while Building in Public: Learnings at Appsmith

Building Our Community while Building in Public: Learnings at Appsmith
Akshay Rangasai
 minutes ↗

User engagement is a catch-all phrase the internet uses for well...engaging with your users. But like all such phrases, it doesn’t mean much without context, especially for an open-source company like ours that builds software for developers.

At Appsmith, we’re evolving from a small project with great support on Discord to a company that is investing heavily in engaging its users. In this post, I’ll walk you through our key learnings over time, with a little bit about what our users had to say at each step of the journey.

  1. Distinguishing great support from engagement
  2. Personalizing interactions with users
  3. Discovery as a core function of engagement initiatives
  4. Using the product to drive engagement
  5. Segmenting users
  6. Seeding content in the initial days
  7. Tracking progress and engagement

Great support is just the first step

We started a Discord channel to brainstorm ideas and learn from our users. Back in January, our Discord was (and still is) active 24x7. We were helping users across time zones all day. Users loved the speed of our support. Support work has remained extremely important for us and @mohanarpit, our co-founder, makes it a point to give shout outs for support work on our internal slack.

CleanShot 2021-07-06 at 17.38.42@2x.png
CleanShot 2021-07-06 at 17.38.57@2x.png

Being available all the time for support was helpful, but we were not generating relevant content. Very rarely were users spending time discussing the product with us. We needed to do more to communicate with users around what we were doing, and had to find ways to show them that we cared about their inputs. While speaking to our users, we also learnt that they engaged with us to request features, report bugs, and plan for the future so they could continue using us. Asking for support was just one of the ways in which they could get their jobs done. Support is what gets users started with the community, but it doesn’t make them stay and get involved.

That’s when we started our newsletter and other content initiatives. In addition to our docs, Appsmith now has a wide variety of videos, tutorials and templates to get users started. We immediately saw an impact and a lot of new users loved us for it, and our non-support channels started getting more active on Discord!

Make it personal and experiment with what works

Almost simultaneously with the content initiatives, we started something we used to call “office hours”. Users could join us on Thursdays and ask questions and receive live support. Our first month was decent, but over time, fewer people joined, and most questions coming up were about future features and timelines. So, on one hand, this felt like a failure because we didn’t get the volume of activity we expected, but on the other hand, our entire team loved interacting with the users. It felt personal and we got the best feedback through these sessions. Some of these sessions also helped users decide whether Appsmith was offering them what they wanted in the near future. There was definitely a great value in having such an initiative.

CleanShot 2021-07-06 at 17.42.21@2x.png

First community call where 3 users showed up

So we furthered the initiative with Community Hours. With Intercom and Discord for near-instant support, we used the Community Hours to speak about our product roadmap, talk about releases and lift the hood around some engineering choices we made.

CleanShot 2021-07-06 at 17.43.50@2x.png

All the features voted for by the community, that we’re building right now (watch)

We had a long list of feature requests and these events helped us prioritize our features to what the community wanted. We also started streaming live demos so our users could see our new features in action while we built complex applications.

This showed us that not every initiative is a success, but if there is value in an initiative, it is worth looking at how we could get the same interactions through a different format. We were so focused on support that it took us time to realize our users were with us in this for the long haul.

Now, we have launched Betasmith to interact with users even more closely. You can join Betasmith here!

CleanShot 2021-07-06 at 17.45.23@2x.png

Discovery is important

It’s easy to ship content, but it is really hard to make it discoverable for people. It is even easier to set up a website or Discord channel, but even harder to get them to work for you.

The trick is to have easy ways to engage with your users and this sometimes means using multiple channels in tandem. We frequently inform all our users about our Discord channel in case they need support. Our intercom chat pops up a couple of times for new users helping them with tips, tutorials and asking them if they need help. Our entire onboarding email is set up to get users to succeed with Appsmith and engage with us meaningfully.

To really drive home engagement, we included an omnibar really early in the lifecycle of the product so people could find what they were looking for easily. Our content efforts were first focused on existing users vs initiatives for real growth. We focused on the problems our users were trying to solve on Appsmith and focused on it than content that was more friendly to new users on SEO. Tying back to our first point, the only reason we believe our content initiatives are successful is that we made them easy to access.


Omnibar to the rescue

Use your product

We want to be there for our users, especially while they’re using the product. To make it as non-intrusive as possible, we use Intercom for gentle nudges to help them, hear from them and figure out how to help them succeed. From our analysis, it is surprisingly effective in getting people the help they need and setting them up for success on Appsmith.

At the same time, it is important not to overuse the product for engagement and let our users use the product the way they want. It is easy to get carried away and use the real estate near the banner, navbar and other empty spaces to push for engagement (This is something we argue over every day), but it is important to understand that users don’t use the product to engage with us. Engagement is a great side effect of a good product.

Not all users are the same

This seems obvious but is hard to put into practice. Not all users want the same features or the level of support or the roadmap. Segmenting users here helps to figure out which channel is more effective to engage with them.

Our users include startup founders (who are super active on Appsmith) as well as CTOs of large companies (who use our product once in a while and don’t personally engage on the platform). We need different strokes for different folks. For example, support requests work great on discord for founders and engineers, but might not be the most optimal channel for CTOs of larger companies.

Discord was great for instant support, but it was a nightmare for users during peak hours. Repeated questions, examples and JavaScript snippets were clogging the pipeline. Before we officially launched, users had already found the website and started asking questions. We quickly realised that our users were seeking a place where they could search for pre-existing queries or have their queries answered without the hassle of Discord. This also signalled a preference for more elaborate answers to questions about the direction of our project.

We’re still in the process of getting our forums to be as active as our community, and I think we will get there fairly soon, simply because of users’ preferences in where and how they want to engage with us.

CleanShot 2021-07-06 at 18.01.47@2x.png

Seed common spaces!

The one thing I believe we definitely did right from the beginning, was seeding our forums and Discord community with content. When our users saw that there was activity, they were happier to post, argue and discuss with us across a variety of channels.

But what really helped us do this easily was that we decided that as contributors to Appsmith, we were essentially the group that set the bar on community interactions and formed the core part of the community. We operated as members of the community first, and used Appsmith to create our own internal apps, and posted questions that came up naturally in that process.

CleanShot 2021-07-06 at 18.03.14@2x.png

From a user on our forums

Track your progress:

While this is not something you do directly for the community, as a project, it is very important to see where you and the community see returns in the efforts. At Appsmith, we use GitHub for issues, discourse forums, Reddit, Discord, email and intercom as channels to engage with users, and it is really complicated to see if our initiatives are working long term, without measuring retention and engagement for the community.

Luckily, we found orbit, a product-focused on community engagement that helps us figure out how users are interacting with various touchpoints in the community and the engagement of our users. We can now keep track of important metrics like messages on Discord and posts on discourse along with the number of returning members, and tie it with product metrics to improve user experience and engagement.

CleanShot 2021-07-06 at 18.03.55@2x.png

Orbit Dashboard for Appsmith

CleanShot 2021-07-06 at 18.04.48@2x.png

Tracking messages on Discord to measure the engagement

Some things to keep in mind:

While these ideas have worked for us at Appsmith, by no means will it work for everybody across the board. Also, one obvious engagement tool I haven’t touched upon in this article is email. Email is how most engagement starts, and there is tonnes of content about using email and making engagement effective online. The other problem with email, is there is a fine line between engagement and spam and thus we use email judiciously with a cap of one email a week and not more. We’re always thinking about how we can cut down the email we send our users and engage with them without spamming their inboxes.

But in the spirit of ticking all the boxes, you can check out our live demo on how we email users who are churning out. As we have scaled, we have also used Appsmith to build a ton of our internal engagement tools, to great effect.

This article provides an overview of the initiatives we’ve undertaken at appsmith to drive user engagement and build a community. We hope some of these initiatives will be useful for your context. Do let us know what you think!