Ep. #104, Internal Tools with Nikhil Nandagopal of Appsmith

Brian Douglas: Welcome to another installment of JAMstack Radio. On the line we've got Nikhil Nandagopal.

Nikhil Nandagopal: Hi, Brian. How are you doing?

Brian: I'm doing fantastic, to be honest. I've got a full cup of tea down and hopefully I'll get caffeinated in a couple hours. I've been doing this thing of waiting to drink coffee until later in the morning, and you're actually calling from Bangalore so you've probably had coffee. If you drink coffee, you've probably had quite a few cups at this point because it's your evening at this point, which shout out to remote life.

Nikhil: We actually drink more tea over here. But yeah, I've had a couple of cups of tea. Yeah.

Brian: Culturally, that kind of makes sense too as well. But we're not here to talk about caffeinated drinks and stuff like that, we're here to talk about your project which is Appsmith, so why don't you start us off with a brief introduction of what you do with Appsmith and how you got here?

Nikhil: Awesome. Thanks so much, Brian. It's really great to be here. So hey, I'm Nikhil, I'm the founder and chief product officer at Appsmith and Appsmith is an open source project that makes it really easier for developers to build internal tools. Now, I myself have been an engineer at eCommerce giants and food delivery startups and I've seen these internal tools devolve and eventually break down at scale, and that's where I really thought that, "Hey, this is a real need to make the experience of building these internal tools much, much easier for developers." And that's why I'm here to just share my experiences with you all. I'm really excited to be here, Brian.

Brian: Awesome, yeah. And I've definitely been in a place where I was in a 10 person startup and then a 3,000 person company, so I've seen the gambit on both ends. But also I've built internal tools to scratch my own team's itch, or also just to support multiple members across organizations. So I feel this pain all the time, and still at my day job at GitHub, I still use internal tools that were built by some engineer at the company so this is a very valuable space to be in because I think what happens is...

It's funny, because I bring up this story all the time and maybe this resonates with you and your customer base, but at my first startup in San Francisco we had to solve a problem, I think around end payments, and no one really had the answer. We needed to maintain internal dashboards on how things were coming through and how we could get insights, and Stripe had been around but we weren't using Stripe.

So my engineering manager, which was the CTO at the time, asked everybody on the team like, "Who do we know in San Francisco that has solved this problem already and can we get them on a call to chat through this?" It's something that I don't think a lot of people think about a lot, where you can just actually learn from solved situations of problems. I imagine with Appsmith you probably have some out of the box solutions or your first step to building internal tools, so I'm curious what are examples of internal tools that Appsmith might create?

Nikhil: Yeah, that's a great point and I think there are a lot of out of the box examples.

One of the most famous would probably be Django Admin because you can get an out of the box, admin paneled in quickly. But the bigger problem that we are seeing today is the way data is fragmented because of all the different SaaS solutions out there.

Let's take a typical use case of customer success, you get support that gets on ZenDesk, right? So that data is on ZenDesk now.

Your actual user information on who this user is inside your own database, it could be inside Mongo or PostgreSQL and your actual payment information is sitting on Stripe. Now, a customer support agent that needs to tackle an issue related to an order needs to look at three different places to get this information, and to potentially even refund your order or cancel a delivery, would need to actually go and interact with two different tools to do that.

Now, that's quite cumbersome, especially when you're a growing startup that's trying to scale your operations and do all this really, really quickly. That's where internal tooling comes in, where you need a customer UI that talks to all these different data sources and can enable your operations team to perform these workflow so that they can just see what support ticket came in, click on your name, Brian, see that, "Hey, Brian has been with us for the last couple of months. This is his order today."

And see that, "Hey, the order has not actually reached Brian and he needs to cancel it so then we can just cancel his order amount and go ahead and refund it back to source." Right? So doing all these complex workflows, as well as looking at your internal data, it requires you to have these custom dashboards because all of your data is fragmented, as well as your processes are custom to every single organization. That's why building internal tools is such a pain today and that's why we think Appsmith makes it much easier for developers.

Brian: Yeah. And I'd think as a developer, you'd know how to interact with your own codebase, your own database. You're in the best position to do that, and sometimes these off the shelf solutions can... For example, Salesforce. It's like, "Pick a very large solution." That might not make sense for a young, scrappy startup or a startup that doesn't have true customers, but maybe more of like community. So it becomes interesting, how do you interact with that? Building custom solutions, especially as you're a growing startup, makes a lot of sense so customer success makes a lot of sense too.

Nikhil: Yeah. Absolutely. We see the same repetitive use case whether it's in customer success or marketing, or whether it's in HR. You do end up needing this custom workflow or custom tool because all of your data is so unique, and it's really hard for a SaaS solution that comes out of the box to give you that unique insight or that unique view into your data, or create that unique workflow that you need.

A simple example of this is that inside one of the food delivery companies that I worked, whenever you refunded an order, you also had to deduct the loyalty points that the entire startup was giving you for every purchase, right? That's a really unique use case because it's really custom to your business.

Because we were working with, let's say, healthy food, we also had to deduct the number of calories that were credited to your user profile. So because all of these use cases are really niche and unique to your business, all these tools are also niche and unique. Like you said, as a developer your first call to arms is, "Hey, let's maybe put together a bootstrap project. Let's maybe spin up React, let's add a team on top of it and try to build something customer." The problem with that is it takes a lot of energy to maintain that project, especially when it's not a core part of the business.

Now, as a frontend engineer inside one of these companies, you're probably more willing to spend your time on the consumer facing aspects of the company and not as much on the internal tooling because the internal tooling doesn't really get much product bandwidth, not much design bandwidth, and it's largely you and a couple of business owners trying to figure out what kind of process would work right for you at that point in time.

So a lot of engineers don't even want to own these internal tools and develop them and maintain them, and that's why it's so important to just make it easier. But at the other end of it it's really, really important for the operations to scale and really important for the business to grow, so there is this entire friction around internal tooling itself.

Brian: Yeah. Yeah, that's excellent. It's a great space to be in as well, because obviously every developer listening right now probably has a tool that they've thrown together and custom built, or are basically working with that tech that someone else built for them. So being able to have these common interfaces, which I imagine Appsmith, you're building these common interfaces for folks to work with to build tools. Can you explain, if I'm a developer, I'm going to reach for Appsmith, what am I reaching for? What are the benefits of leveraging your toolset?

Nikhil: Right. So I think the first part of the problem is just talking to your data right, because your data is so fragmented. It's really difficult to have an API that talks to all these different databases and different data sources, so Appsmith gives you the building blocks so you can quickly integrate the data. But the next part of the problem is dealing with HTML, CSS. Now, I don't know about you, Brian, but most developers I know really dislike HTML, CSS because it can be quite boring and repetitive.

That makes for a really poor coding experience because a lot of the time you're just fighting with these different frameworks than focusing on the core business logic of the tool. So what Appsmith does is it gives you these building blocks out of the box, such as UI widgets around tables, charts, lists, fonts, because that's really the bedrock of most internal tools. Internal tools are largely just these three or four widgets laid out really well.

It then allows you to quickly configure these widgets using drag and drop, so we have a visual interface where you can easily position them, align them, change their properties without needing to understand a complex syntax around HTML or what kind of CSS properties do I need to apply to make this look good. Then the real beauty of it is it also allows you to write JavaScript to wire up all of the data from your backend right to the UI that you recently created, and deploy it all in a single click.

So Appsmith abstracts away all the boilerplate from your development process and leaves you with all the fun parts, which is configuring your widgets, writing the business logic, adding validation to all of your applications and things like that. So that's why Appsmith makes it so much faster to build these internal tools.

Brian: Excellent. The reason I brought you on here to talk about Appsmith, but also I wanted to actually have a broader conversation of how to get employee buy in for evangelizing internal tooling because it's something that definitely the company I work for, the companies I've worked for before, definitely you get to the point where it's providing enough value that you don't need to pay attention to it, or maybe there's been a workaround. So how would an engineer get buy in? Or how would an engineering leader get buy in for internal tools?

Nikhil: That's a good question, Brian.

One of the things I always say is that internal tool building is easy, but the adoption is really, really hard. One of the mistakes I see that companies generally make is that they try to build the tool first and then evangelize and try to get it adopted inside the company. Unfortunately, that's just not how software adoption works.

If you look at even how software is built, we build the software along with our users, we keep evolving it and iterating it until we get a really big user base, and it's the same for internal tooling as well.

The most important thing in the early stages of internal tooling is to just figure out the key stakeholders who are really facing the problem with the process and to identify what is the real problem they are facing with the current process and how can you improve it? Almost every internal process actually starts on some sort of spreadsheet, whether it's a Google Sheet or an Excel sheet, simply because that's the MVP of a process.

You just have your data inside a spreadsheet and every day you're either having some kind of analysis on it, or you're taking some kind of updates and creating some kind of reports, or updating some values based on what happened today. Now, identifying those gaps in the sheets and creating tools on top of it, that's where you'll be able to create buy in from your early stakeholders.

A good example at Appsmith was that we were trying to build a customer support dashboard and I built a first version of it, but honestly nobody ended up using it right, and that's when I went to the actual customer support person and I said, "Hey, what are you doing for support today? What are the problems you have?" And identified that one of the core problems they were facing was that all of the support requests were coming on different channels.

We have a community on Discord, we have people raising GitHub issues, we have people writing to us on email, we have people talking to us on Intercom. All of this data is so fragmented that they just wanted a simple dashboard to be able to see all of these support requests, so it just started with a simple problem like that, and starting with a simple dashboard that got some of the support agents to actually buy in and say, "Hey, let's start using this, this is so much easier."

The next step to that problem ended up becoming that once they had this information, they immediately started saying, "Hey, I wish I could see how many people have asked for this feature before." Or, "I wish I could see how many people have reported this issue before." And then they themselves began to own that tool and iterate on it and improve it, and we saw that soon the product team also started getting involved in the process.

So beginning to create that virtuous cycle of feedback and features is really, really important, and that only happens when you can identify who are the first users who are going to be your key evangelists and they're going to evangelize this product only because you've solved a core problem for them.

That's how we always think about any internal tool today at Appsmith, just figuring out what's that simple internal process that we can solve for somebody, build a tool around it and then see how we can scale that tool and process to a more number of people inside the organization. To me, I think that's the best way to gain internal tool adoption.

Brian: Yeah, that is excellent and I loved your response too as well, because just identifying things like a spreadsheet, the first internal tool that people start with. I've got tons of spreadsheets, and I get tons of spreadsheets shared with me and tons of Google Docs with random inputs of data that people are collecting. Basically, it's an opportunity for scale, you don't know you need to scale this until it gets to the point where now you're shipping a spreadsheet every week or every month and people are dependent on the spreadsheet, but the only person who can manually input the spreadsheet is one, lonely, maybe marketer or product manager or even developer. That's some really good insight and I'm hopeful that folks will take a lot from that as well.

Nikhil: Thank you, Brian.

Brian: I'm curious, so I looked on the website and saw that Appsmith is open source. Is that correct?

Nikhil: Yeah, absolutely. Appsmith is open source. We built it right from scratch thinking that this has to be a platform that developers can quickly adopt, and one of the reasons we did that is, me as a developer, I don't really have a credit card that I could use to buy software inside an organization. But at the same time, I could always quickly adopt any open source software into my tech stack and that got us thinking that why isn't there something that enables developers to build their applications faster and makes it really easy for them to adopt?

All the solutions that we have seen out there were really top down. They were largely sold to managers and CXOs that could afford to pay for them, but because of that they weren't really developer friendly. They were really business user or manager friendly, but they weren't really easy for developers to really get in.

The coding experience was quite, quite poor in them. Because of that, we decided to build Appsmith as an all in one solution for developers to adopt and be able to deploy on their local machine to be able to easily audit, and more importantly to be also easily extend because a platform like this has be extremely extensible. It's almost like a framework because you don't want to get locked into one particular platform that can eventually maybe have some limitation in it.

Instead with Appsmith, it's really easy to just fork the repo, see that, "Hey, there's something missing,"maybe there's a widget that you need, you can then go ahead and contribute back to it. So that's why we went open source, a large part of it. But the other angle of it is also that we really believe that software is really a team sport, developing software.

As much as we really like to hack things on our own, really great software only comes from teams and over here we've built Appsmith around the entire community, and that's what we really love about the open source angle. It's that we have such a great community of developers that are not only contributors in terms of code, but also in terms of product feedback, ideas, entire decisions around the product and that really helps us improve.

Being open source and collaborative, that's why we also incorporate a little bit of that inside the product. So today, you can even sync your Appsmith applications to any Git repo so you can still perform code reviews and version control and go through your entire SDLC the exact same way. That's also another really cool thing that we've now done with the product.

Brian: Ooh, yeah. I 100% agree with the open source notion in the community, because if you have a common model across communities and companies and developers, it makes it easier for getting started. So I'm curious, you had mention Django in the past, is this written in a specific language or framework? What are folks, when they open up the repo, what do they expect to see?

Nikhil: Yeah, so Appsmith it's apart. Basically the backend is written in Java while the frontend is written in React, and we use Mongo Db and Reddis as our data source. So we have a backend, we have a frontend, but the best part is that developers can really easily get started because it's all packaged under one Docker container. You can literally just stick a Docker image, let's say Docker, up and you can get up and running in less than a minute.

Brian: Okay. That's beautiful too, as well, because yeah, wrapping this in Docker makes it less concerning about what language or framework this is being leveraged. You just have now connectors at this point that you can interact with. So I imagine I can leverage the image, and then if I happen to be writing in a different language I can leverage those connectors to get the job done?

Nikhil: Yeah, absolutely.

Brian: Excellent. Yeah, so I'm curious more about this community around Appsmith, so what is the makeup of the community? Are these large companies, small startups? Who are the folks that are reaching for Appsmith today?

Nikhil: We actually have a very varied makeup, Brian. It initially started out with a lot of indie hackers and small startups, but today we have everything from 1,000+ member companies to a huge set of indie hackers as well. We're also seeing a lot of agencies actually begin to adopt Appsmith because consulting agencies have also seen that their development times can actually reduce, their turnaround times are much, much faster and their software is a lot more stable with Appsmith so we're also seeing a lot of push and adoption from consulting agencies.

In terms of developer makeup, I'd say our primary developer persona would be a backend engineer because backend engineers really dislike working on the UI bit and that's what Appsmith really does well for you. But at the same time, we're also seeing a lot of frontend and full stack developers begin to adopt it because they realized that even front end and full stack engineers see that they want to dedicate a lot of their time towards the consumer facing applications, they want to dedicate less amount of time towards the internal applications that they see as operational overheads today.

Brian: Yeah, that's true. If you're working in a smaller company and you're just trying to raise your next round or acquire your next customer, the focus on internal tooling, the polish is not needed, simply. If you're looking to impress your employees, you're impressing the wrong customer. You want to impress external facing folks who are going to pay money, so right there I agree with you. Most of my internal tools or most of my stuff I build for myself tend to not look as pretty, even though I can make it be decent looking.

Nikhil: And you know unfortunately that's actually a part of the problem today, which is that because these tools don't really get any UX bandwidth or any kind of product bandwidth, these tools look actually atrocious and what happens at scale... I'll tell you this really interesting story at the food delivery startup, it was that we started out creating an offer configuration tool that would allow you to configure marketing offers for different user segments.

Initially it began as a simply Python script that the developers would run and create these offers, but over time we had to create an interface so the marketing team could also begin doing this because it was taking too much of the developer's bandwidth. Now, what unfortunately happened was that over large periods of time and many iterations on the tool as the business grew, as the processes changed, the tool had to adapt along with that and unfortunately, because there was no one paying attention to the UI-UX of the tool, the tool became so complicated that we were seeing a high number of incorrect offers being configured.

This means that incorrect users were getting offers that they shouldn't have been getting, and lots of users who should've been getting offers were not getting offers. That means a huge potential revenue impact for the company, right? That's a massive problem for internal tools and UX, and it's something that people don't recognize as a problem, unfortunately, until it becomes really, really severe.

That's one of our focuses at Appsmith, to just make it really easy for any layman to make a really, really good UI and UX for your application out of the box without understanding HTML, CSS, without being a great designer at heart. You should just quickly be able to get your application up and running, but it should also service the needs of an end user so that they don't feel punished using the tool because a lot of these users are using these tools for like eight, ten hours a day. They can't be using a tool that's really clunky, has poor performance, has a very bad UX. That just doesn't help them achieve their end goal very well.

Brian: Yeah, very true. This is exciting, and I love learning about these tools because these are an opportunity to improve developer happiness, experience. But also shorten the developer lifecycle, so if I don't have to pull off an entire engineering team or an engineer to go work on some tool that maybe a lot of the team's going to work on but not a lot of people put a lot of head space into figuring out UI-UX interactions. That's going to provide more bandwidth productivity to ship features that are really moving the numbers. So yeah, appreciate you coming on and sharing about Appsmith. I hope that folks who are interested in checking it out definitely do. I'd be curious, is there a place that folks can check it out today if there are any demos or example repos?

Nikhil: Yeah, absolutely. Appsmith is open source so we live on GitHub. You should just absolutely check out Appsmith on GitHub, we have great project that continues to grow with the loving community. The project comes with a great documentation, a simple contributor guide, lots of examples and templates on how you can get started quickly and the applications you can do with Appsmith. So I'd just ask everyone to check out our repo, star it and begin building your applications.

Brian: Cool, yeah. And they've been asked too as well, monetization, are you providing a hosted version? How is Appsmith making money through this open source repo?

Nikhil: Yeah. So we actually do have a cloud hosted version, but that's also free. What we are launching now is a commercial edition that is more valuable to slightly larger companies. Our entire goal with Appsmith has always been to build something that was going to work really well for individual developers and smaller teams, that's going to help you build your internal tooling, maintain your internal tools, integrate with Dev SDLC and also have a premium enterprise version for larger teams that needs additional features such as SSO, audit logging, role based access controls, things around teaming and branding. So those set of features are what we monetize on and that's what we're actually working on this year, and we have in fact already begun working with a couple of early users on our enterprise edition.

Brian: Okay, excellent. Well, yeah, that's exciting and looking forward to hearing about the launch. I'll definitely be watching from the sidelines, and if folks are looking to me for recommendations I'll definitely be sharing Appsmith, for sure. But I do want to transition us to picks, so I appreciate the conversation, Appsmith and internal tools and getting buy in from the rest of the team to build these tools. But I want to actually share these picks that I've been working with for the past couple weeks.

Jam Picks, they're things that we jam with. Could be music, could be food related, technology picks I think are also popular, which I've got two today. My first pick that I want to mention is Post Hog, Post Hog is a service for metrics and analytics tracking. If you think of Mix Panel or Applitude. I was specifically looking for a tool because I have an open source project, but I want to start doing some metrics and tracking for signups and conversions. It's something that I haven't really thought about for my project, but I get a lot of people to look at the project, I don't get a lot of people to sign up.

The project itself is Open Sauce, in case people were wondering, if you want to see this in action. We're choosing Post Hog just to basically start tracking to see, you discover Open Sauce, you went to the signup page, you might've clicked a button, you might've rolled off. So I instantly need to know how many people are not clicking the sign up button and then I want to entice folks to get unstuck or entice them to click signup.

So Post Hog, it's also open source, it was also a YC backed company as well in the last couple years I believe, and they have a hosted version but also the beauty of this is you can self host it. You provide all your metrics into a PostgreSQL database and you can start getting insights, which honestly as I say it out loud, I imagine you could probably connect this to Appsmith and this would be a really good and insightful dashboard to add to that.

Nikhil: Yeah, absolutely. Appsmith integrates with pretty much any piece of software that has Rest APIs.

Brian: Excellent, yeah. Maybe I'll become an open source or a free user of Appsmith pretty soon, pretty shortly. I'm definitely going to check it out. The other thing I want to mention is I've been doing a lot of clean up on the Open Sauce project. I've been working on this for a very long time, like the past six years, probably when I first mentioned it on the podcast. I've brought on a new consistent maintainer, and he actually remarked to me and had shared publicly on Twitter that he's really appreciated creating new features inside of open source and it mainly comes down to my approach to design first components.

At the time of creating Open Sauce, I was learning about design systems. Actually we had a design system podcast, early, early Open Sauce episodes, like in the first 10 to 15. What I'm getting at is that I learned how to use design systems and how to build them, and I did that at my last job, and I also did this in open source. So now anybody who contributes to the project, it's very clear how to make a contribution and what sort of components against.

Again, very similar to this. I didn't actually mean for this to be so serendipitous to Appsmith, these two picks. But in the same vein, you want to have existing components, existing ideas that you can pick from as opposed to building from scratch. So again, everybody use Appsmith and you'll have a lot of the design architecture and connectors done for you.

Nikhil: Awesome. Is this where I talk about my picks?

Brian: Oh yeah, please. If you have any picks, yeah, please share.

Nikhil: So I think on the tech side this is an odd pick. One of the challenges I generally face is that when there's a bug reported in Sentry or a crash report on Sentry, it's generally really hard to reproduce that and a lot of times they go unnoticed because you just don't have a way to figure out how does this actually occur.

One of the things we did initially was try to integrate Sentry with Smartlook so that we could get the recordings of, hey, what did the user really do when they encountered this problem? But it didn't really work too well, it was quite hard to find the right recording and things like that. But there's this new software called Zipy. It's really cool, you can easily integrate it and what it essentially does is it gives you the same error reports as Sentry, but at the same time it also gives you the video recordings of that actual error.

So along with you seeing that, hey, this is network error or this is a console error or whatever type of error it is, you can also go to what exactly the user did and reproduce how they did it, along with see what happened in the console while they were doing that. I thought that was really great, that's super nifty to just bug bust a lot of things. That's one of my favorite recent discoveries.

Brian: Awesome. Yeah, I'll have to check it out. I've heard of it in passing, but never really checked on the website or the project itself.

Nikhil: Yeah, it's a pretty new project on Product Hunt and I know the founders, and I think it's really, really nifty, the thing that they have done. Yeah, we are also trying to use it at Appsmith.

Brian: Excellent, yeah. Product Hunt, so Product Hunt is something I've been really frequenting way more as of recent because somebody's productivity tooling, it's a roomful of indie hackers mostly. There are some startups and larger companies that Product Hunt posts and stuff like that, but I love the thumbing through and finding out what is the Product Hunt of the day or the Product Of The Day on Product Hunt. So yeah, I must've seen it on there as well. But did you have any other picks?

Nikhil: Yeah, so the other pick is actually a non tech pick. I'm a recently turned vegetarian and as you can imagine, after having lived most of my life eating meat, it's been quite hard to convert. But I recently discovered Beyond Meat in India. I know it's been there in the US for a while, but Beyond Meat is now available in India and it kind of blew me away, the product. I mean, right down from not only the taste, but what really surprised me was even the smell and the texture reminded me of meat and I was really surprised by how far we've come in the food technology space. I was really, really impressed by that, so I think Beyond Meat is a fantastic product. Because of it I'm now flipping burgers on the weekend and really, really better off for it.

Brian: All right. Well, congrats on the transition to vegetarian as well. It's something that I try out every now and then throughout the year, and I always end up crawling back to eating barbecue which is my passion at the moment. So thanks for the tips, Nikhil, and thanks to you so much for talking to Appsmith and sharing examples, and hope folks will reach out with all the questions and join the open source community.

Nikhil: Thank you so much for having me, Brian, it was great speaking to you.

Brian: Yeah. And listeners, keep spreading the jam.