Appsmith

Check out our open-source Feature Flagging system – Flagsmith on Github! I’d appreciate your feedback ❤️

Ben: I'm super excited to talk with Nikhil Nandagopal of Appsmith, a fellow "Smith"-er. I feel a little bit of brotherhood there. Nikhil, it's great to be on. Thanks for your time.

Nikhil: Thanks a lot, Ben. It's fantastic to be here. I'm pumped to talk about Appsmith and open-source with you.

Before we get into a little bit about your background and how it came to be, do you want to give people an overview of what Appsmith is, why people use it, and what's interesting about it?

Appsmith is an open-source project that helps developers build internal tools. People use it to build all kinds of custom internal software inside their companies primarily because they have data that are fragmented across different silos. They have data in their ticketing or support solution, database, and payments gateway. They need a tool that can talk to all of these different data sources.

You can think of it like Zapier with custom UI because Zapier helps you send data from one data source to another. What if you need the human in the middle that has to look at this data that needs to analyze this data, take action, and create workflows based on this data? That's when Appsmith comes in. You can build a custom UI by dragging and dropping components. You can connect them to over twenty different data sources. You can write custom queries and business logic.

The best part is that you can write JavaScript pretty much anywhere on the platform. When you are creating these custom workflows and custom business applications, you can write JavaScript enough to enforce validation rules and create workflows or any logic that you like. Appsmith is an all-in-one app-building solution for internal tools. You can even deploy your applications with the click of a button.

Looking at your background, am I right in saying this is the first commercial open-source organization or business that you have been involved in?

That would be fair. This is my first popular open-source project.

Do you want to talk a little bit about the origins of the idea? Was this a niche you had in other organizations? Talk about the first commit that went into it.

I have been a software engineer for years and have personally faced this problem. The first time I saw this problem was at this eCommerce giant called Flipkart in India, where I was tasked with building this logistics application for delivery executives to fulfill orders on the ground. While I was excited to begin it, I quickly realized that these applications didn't get a lot of design bandwidth.

There's no real product bandwidth. It was more or less just me, a couple of developers, and business folk deciding the features and the UI-UX and trading the application on the fly. Unfortunately, one of the problems with that is that in the long-term, this application isn't maintained very well. It doesn't involve a good direction. Eventually, you see that it ends up getting scrapped.

These are internal applications that have been used.

These are internal applications that the delivery executives inside the company are using for their operations. One of the other challenges with the internal tools for that is they want to be very exciting from a technical perspective because they were largely simplistic in UI simply because you have control over the users who are using them. You don't have to have the best UI-UX. That wasn't a priority for these applications, which means they just want a big technical challenge.

They were also largely wired up to a bunch of simplistic credit workflows, which means that there wasn't a lot of complicated business logic going into it either. As an engineer, I never empathized with the need for internal tools. I couldn't see how important they were. I didn't like working on them. Fast forward a couple of years, I was working for this healthtech giant called Cure.fit in India. Over there, I led Product and Engineering for this healthy food delivery vertical called Eat.fit. Over there, we scaled Eat.fit from about 50 meals a day to 50,000 meals a day.

I’ve got to see the other side of internal tools. As you are scaling so rapidly, internal tools are super important because when we started, we had all these little scripts that we would write to update the database. We would have scripts to create offers, look at audit statuses, and refund orders but that quickly became very error-prone, and it also consumed a lot of our developers' time. We wanted to offload these to the business team.

We went ahead and built all these various internal tools like tools for product cataloging, inventory management, and delivery tracking. As we built all these tools, I, unfortunately, saw the same story play out where these tools didn't have a larger vision. They quickly became very complex. Nobody wanted to own them and work on them in the long run. I could empathize with these engineers who didn't because I was one of those engineers a couple of years ago.

I remember there was this one a-ha moment where I was sitting with someone from the business team and helping them configure an offer for sale that was going live. The reason I had to sit with them and configure this offer was that the offer configuration tool had become so complex in itself that the business teams were scared of configuring the wrong offer, which could potentially lead to a very large revenue loss.

By looking at the screen, you would tell that this was a complicated upfront that hadn't been well-thought-through. It didn't start that week. It failed to do what it was. That was the a-ha moment for me. We started this entire journey of building tools that the business team could use self-service but here I am, years into the building and maintaining these tools back, helping the business team to configure them. That got me thinking, "There has to be a better solution to this." That's why we decided to build Appsmith.

That's interesting because they sound like two somewhat different problems. Did you see a ready-made solution in your head that solves these two different use cases? Were there other products out there in the market at the time that influenced you? It seems like one of those products or projects where you can go ahead and carry on building forever, and you end up with this massive ball of string that doesn't know what it's for. You have to be very rigorous around the product design and what you do and do not do. It's more about what you don't do than what you do in some ways. How did you come up with that?

You would be surprised but each of these startups that I have been talking about all had their internal tooling framework. That would arguably be no different from what Appsmith is. Cure.fit had an open-source framework called react-crux. It was a simple JSON configuration that would allow you to render a tool on your screen where you would be able to specify logic between the different components to quickly spin up an internal tool.

We have been heavily inspired by these tools that were already internally made. We saw that some of these tools were not efficient enough because everything in JSON is very difficult. It’s because you are working only with JSON, the amount of configuration you can do is very limited. We thought, "What if we do an entire programming language into this framework and allow you to render things on the fly?" We also looked at various other frameworks and things like Django Admin, which gave you things out of the box.

That's where a lot of our data modeling especially comes from. We also saw that we wanted something highly customizable because our key insight here was that these tools are extremely customed even to similar businesses. You can have two food delivery businesses focusing on similar sectors, and both their offer configuration tools look wildly different simply because both these products are trying to differentiate in their own way.

Talk about the first commit. Did you go, "I'm going to leave my work and start a new business. It's going to be open-source." At what point did you open an idea and start coding?

Honestly, we spend a lot of time thinking about the problem and researching how big a problem this was for other teams because from our perspective, we had seen about two companies build these tools. We wondered whether it was an edge case. As soon as we continue to research the market, we realize that admin panels, internal tools, custom software, and all these were synonyms for the same internal tools that were being built. We realized that the market was extremely huge. We spent a lot of time focusing, "Is this a problem that's big enough for us to solve? Is it worth solving?"

That was step one for us. Once we realized, "This is what we are solving," we took the leap of faith because, at that point, we had wanted to build a developer tool that was going to be loved by millions of developers. That was our core focus. We wanted to build something great for the engineering community. We took the leap of faith. My Co-founder, Arpit, and I got together one weekend. We started coding it out rather than designing the architecture on Appsmith and watching the frame be like, "How should the entire product look?" That's how it all began.

When you said, "We," who else was involved in the project at that point?

It was me and my Co-founder, Arpit. Arpit is our CTO while I head product here. We worked together at the healthtech startup. We both saw the same problems with the same tools. We got together talking and said, "This is a problem that we are going to have to solve." Arpit also has a close friend called Abhishek, who is our third Cofounder and CEO at Appsmith. We brainstormed the idea with him. He loved the idea.

His a-ha moment was at the airport, and he saw somebody log into this old desktop Bliss internal tool. He saw them struggling with it. It was so slow to load. The laptop would keep hanging. The tool looks very outdated and not modern. That was his a-ha moment like, "We have to replace all of these tools out there. This is huge." That's when we brought him onboard, and then the three of us hit the road running.

It's interesting as well. Maybe we can talk about this a bit later. I would imagine their security holes were miles wider than some of those old platforms. The people are accessing remotely on some old framework that isn't security patching this up. You mentioned engineers as your target user rather than products or business analyst folks. Was that a conscious thing to target software engineers?

Yes, absolutely. This started because Arpit and I faced this problem ourselves. At the core, we are engineers. We truly wanted to solve a problem that we understood very deeply and are extremely passionate about. In this internal tool space, the one thing that we realized is that custom software is hard to build. It requires a deep understanding of your core data structures in your databases, APIs, and how businesses start because it's generally programmed to be efficient and optimal.

That understanding is hard to translate for somebody who doesn't have technical proficiency. That's why we always focused on engineers. In the future, we do expect that more technical product managers and analysts will come into our fold and try to use our product. There's no doubt about it. What we saw early on was that there was a core need for engineers simply because they were the ones who we saw were facing the brunt of the problem because that's what they were tasked with. They didn't want to do the work. These specific skillsets were needed to achieve the end outcome for internal tools.

What was your initial MVP at the time? Was it connecting to a secret database and providing some views to queries?

Our MVP was maybe five widgets, if I remember correctly. At the table, we had a form, an input, a date picker, and a button. We had a Generic REST connector, which allowed you to talk to any API on the internet. We had a simple sequel integration where you could write sequel queries and fetch data. It's that along with a simple binding platform that would allow you to connect the data to the views.

We didn’t have full-fledged jobs for the part-time, whereas now, you can write complex business logic and entire lines of code. You can even create usable JavaScript functions and set apps but back then, we had a simple binding layer where you could connect the data to the views, trigger different queries from your views, and things like that. That was the MVP.

Was that when you hit push to GitHub? What stage in the life of the project did that happen?

We spent about a year building out the project. We started sometime in June or August of 2019. We later deployed to GitHub in August of 2020, if I remember correctly. The trigger moment for us was that we were seeing genuine usage in the platform. We could see that people were able to build simple CRUD applications out of it. We weren't too worried that we would be fending off too many requests for different features. We do that at the core.

The background was a little bit stable and ready for an open beta of sorts. That's when we decided it was time to hit deploy in the project. Also, another great event that was happening around the time was Hacktoberfest, happening in October 2020. While going into open beta in August 2020, gave us a little time to prep for October 2020. That's when we saw a lot of contributors come in. We saw a lot of usage on the platform. It was a great initiative push.

You've got a hosted SaaS version as well as supporting people running your open-source product. Did those come together? Did one come before the other?

We always have both. The cloud-hosted version runs the same open-source self-hosted version in Appsmith. There's no difference between the two. The only difference is that we manage and guarantee uptime on a cloud version but it's up to you to manage the self-hosted version. Otherwise, these two products are always been the same.

In terms of the marketing of the initial release to GitHub, how did that work?

One of the things that we did early on was we talked about Appsmith and why we built it on a lot of public forums. We talked about it on Reddit and Hacker News. We talked about the ethos with which we built Appsmith, why we made it open-source, and how we were trying to solve this core problem that developers needed a new tool stack for their internal tools. There was no good open-source product out there that was there to replace this tool stack, unfortunately. That's how the conversation started. We eventually led into Hacktoberfest, where we talked about getting contributions for widgets, data sources, and integrations.

Eventually, the thing that kicked it off was that I remember this one user went on Twitter and complained about our performance at that point. We had a bit of a performance problem with the platform. At this point, we were in a bit of a dilemma as to what do we do about it. In sticking to our ethos, the first thing is to be highly transparent. We went online and acknowledged, "We agree with what you are saying. There is clearly a performance problem." The second thing we did after acknowledging it was we said, "We are going to take some serious action about this."

We created an entire bug bounty program around this person saying, "People who come in during Hacktoberfest that raise issues around Appsmith, our performance, and bugs, we are going to reward you with something. We are also going to go and close all of these issues that you report on our platform." That kicked things off because people connected with us and saw that we were genuine about the things we were saying. They saw that we were solving the problems that they were talking about. It gave us a deeper connection with the community.

For products like yours, being able to run it internally and not providing database access to a SaaS product is an absolute bullseye. Into it hits the sweet spot of an open-source project in so many different areas. Are there larger commercial competitors that are only running a SaaS business? There's Flagsmith, for example. With our SaaS product, we wouldn't ever imagine giving database access to an external third party. We wouldn't even consider it. In terms of the telemetry, is that something that you did out of the gate as well? I would imagine that's one of those projects where there are a huge amount of people deploying it that you never hear about.

Over here, one of the key insights with Appsmith was that because this is going to be touching your internal data, we wanted it to be a self-hosting-first experience, whereas everyone else was doing more of a cloud hosting experience first. You could even try it out on your laptop. It was always behind a paywall. They did possibly have a self-hosting experience but unfortunately, it was in their highest enterprise tier. They didn't have a very great self-hosting experience because you would have to run a script and download binaries. It was complicated. You don't have to share a lot of data.

With Appsmith, we only wanted mind-blowing self-hosting-first experiences. We made it easy right from the get-go. Along with that came that telemetry had to be opt-in because this was open-source, and it's touching such critical data. We ensured that users only shared data with us if they genuinely wanted to improve the product. Even with the telemetrics that they shared with us, we ensured that it's completely anonymized in nature so that we never collect any personal identity information. These are some of the things we have done to make the self-hosting experience easy.

Early on, I remember we even had a script deployment method but we heard from the community, "This isn't as great. We would truly love it if we could have a simple Docker method to bring Appsmith up." We undertook a massive project to rewrite everything and put everything into a single Docker container that could come up quickly.

We saw a lot of love for that and a lot of users appreciate the fact that we had done this. We can now see that the deployments go a lot smoother simply because of that. We are constantly investing in making our entire self-hosting-first experience much better for users while at the same time protecting their data privacy.

You weren't a Docker-first deployment when you first released. Is that right?

We were but we were running multiple Docker containers. The problem with running multiple Docker containers is that you miss out on a lot of things if you want to automatically install SSL certificates or do certain configurations that have to communicate across these containers. All of that becomes hard. We had a simple install script that could download these different Docker containers, configure them for you, and install the SSL certificate to all of these things underneath Docker.

People felt that it wasn't transparent enough for them. They wanted an even more transparent method and simpler method that they could quickly bring up the project. That's why we have invested in Docker. We call it a big container internally that has all the other containers combined into it. We bring that one container up together.

We had a similar thing. We had different repositories for our front-end and backend up until not that long ago. They were distinct. We wanted to combine them primarily because we wanted one GitHub project. We were splitting our community. Our style is now issues amongst front-end and API. Also, we had a front-end Docker image and an API Docker image.

We went through a similar process. We have done a lot of work making that image as small and as simple as it can be. It's interesting how these sorts of communities tend towards wanting something simple, especially on Kubernetes getting the network connections between the front-end, the API, and the SSL certificates. You end up generating a bunch more work for yourselves.

That's interesting that you had a similar experience. In terms of your GitHub projects, how did you go about learning to manage a community that's growing at the rate that yours was? For those readers who aren't aware, you are at 12,500 stars, and you've got 1,600 outstanding issues and 108 pull requests. They are fairly scary numbers. Was that hard learning how to manage that?

Honestly, it was very overwhelming to start with because we were bombarded with issues. To clarify, when I say issues, they are not necessarily problems with the product. Our issues can be categorized into various star buckets. One bucket is feature requests. This itself takes up a huge chunk of Appsmith's issue bandwidth. People want to improve the platform. They want big changes to it. The other category is the bugs and issues that you are facing on the platform. The third category, interestingly enough, is our internal issue tracking and task management.

This is something that a lot of open-source projects don't do. They have a separate task management system like Jira or ClickUp, where they do their actual project management. We went the other route and built everything right into the data because we wanted to be extremely transparent with the community about what's going on with the project and how we are thinking what are the features, plug into what we are working on, and not working on, and get good feedback on every single data we ship.

That's why we have so many different issues inside our project. Over here, we took inspiration from a lot of other projects out there. We looked at different ones like Hasura. We saw their label management style and realized that labels are the one key way in which you can manage all of your issues and pull requests. We combined label management with an actual internal Appsmith app that allows you to configure labels dynamically. You can say, "If this label is assigned to this issue, then you should also add these other 2 labels and assign these 3 people to this issue."

We were able to write interesting rules with our Appsmith app internally. We built a new internal rule for ourselves. That helped us manage the issue load pretty well. One of the key things with issue management is being transparent about the issue and what type of issue it is. Is it a bug, feature request or task? What's the priority on this issue? Is it a critical issue, which means, "It's going to happen, and I promise you it's going to happen now?"

Is it a high issue, which means, "I'm going to look into it fairly soon?" Is it a low issue, which means, "Honestly, I don't think they are going to look into this anytime in the future. I'm going to be transparent with you about it and tell you that as well until we get it prioritized?" A lot of times, we even tell people, "We don't see too many people asking for this yet, but if you see a couple more, I promise to mock this up." We are going to pick it up at that point. It's about being transparent, saying no a lot, unfortunately, and working with the community to pave the roadmap.

Can you talk a little bit about the code structure? Your product lends itself well to components and plugins. That aspect makes it sometimes a little bit easier to deal with things like pull requests because they are decoupled from the main engine or something. Was that something that you have changed over time? What does that look like now?

We have tried to make Appsmith as external contributor friendly as possible. Where we see external contributions coming from is, 1) In terms of adding new data sources, 2) In terms of adding new widgets and, 3) In terms of improving the platform and fixing bugs and small UX issues. What we have done is we have created a plugin architecture on the entire platform. We have isolated all of our plugins for data sources into a separate ecosystem, where you can create a template plugin using a CLI package that we have.

You simply run the CLI package and enter what plugin you want to create and the details of the plugin. Automatically, the template files for that plugin get created for you. You need to write the code to fill up how this plugin works with its drivers and fix the data in the database and things like that. We are doing similar things on the widget front as well. We are trying to isolate the widgets into a separate package because one of the challenges with widgets is that they have to be consistent across the board.

We are creating a widget design system that can exist as a package on its own and be updated outside of the Appsmith ecosystem. We are making sure that these building blocks are very modular and plug-and-play. Hopefully, in the future, we would also be able to accept a lot of community widgets and data sources that may not have the same level of quality and verification that we are able to give to our internally built data sources and widgets. We will expand the number of widgets and data sources that we have, making Appsmith a much more widget platform.

In terms of contributing to that, is it difficult that you would say no to people? How did you go about managing that? I imagine you would get a deluge of pull requests for all sorts of things with varying quality and say no to people when they are making contributions to your code. Is that one of the hardest parts of the process?

It's not for us because we have always been very clear about our contributor guidelines right from the get-go. Having strict contributed guidelines that we can enforce has helped the community rally around the idea of Appsmith and what are good contributions and what are not so valuable contributions. One of the things we tell people is, "Please, first look for a GitHub issue and ensure that any contribution you want has an associated GitHub issue even before it." That way, we get people to discuss great solutions and problems beforehand.

As part of the discussion, we are able to come to fruitful outcomes as to what does a great solution look like? Is this what happened to the platform? As long as they are able to have those conversations upfront before somebody has made a huge commitment in terms of their time to build a piece of code that they want to contribute to that platform, people are generally amicable to working on different issues and thinking other problems the way that you want to phrase them as long as they understand the longer-term vision of the product.

On your pricing page, you are starting to show an Enterprise Edition. Your cloud version and your self-hosted Community Edition feature parity. It seems to me like the obvious market to go after is the larger enterprise folk who want a bunch of authentications, IDPs, more way success, and all that stuff. Have you put a lot of thought into figuring out which of those features make it in? Are you going to have an enterprise version? Are those features all going to be open? We have found that path is very difficult to know where to tread in that regard.

We have a fairly good idea of what features we want to monetize on versus which we want to continue to keep in our Community Edition. One of the ways to think about it is, "Who cares about this feature?" When you think about our Community Edition, it's geared towards individual hackers, small-sized startups, and maybe even a couple of mid-sized companies. These companies that are slightly larger miss a lot of core features and things like SSL, active directory, and Okta at Zero. They miss those features, whereas so far, Google is still in our Community Edition. They want more granular role-based access controls.

We have seen that simplistic role-based access controls make sense for small teams, whereas if you are running an organization of 100 to 500 people, you need a lot more granular custom rules and access controls to be able to say things like, "You need a lot more audit logs to ensure that you are able to understand who has made, what changes to the applications. You need version control and backup and restore to ensure that you never lose your work and that your team is able to collaborate over the software." That's how we always thought about it. “Who cares about this feature? Is it a small team, an individual developer or a larger organization?”

That's how we have always structured the features internally. One of the core reasons why we have gone with this open core model over another model such as services and support is that we have seen that when you are trying to sell services and support, you are no longer trying to make the product better because your entire incentive to monetize is tied to how hard is this product for your users to use. Whereas our goal with Appsmith has always been to make the product so easy that it can replace every single developer in the tech stack. That's the direction you want to keep going. With this one, you keep making products easier for tech teams to write.

What tools are you using to manage your community? Is everything on GitHub? Do you have other platforms that you are using to discuss the projects and talk about things?

Our Discord community is one of the most active. A lot of real-time support and quick support happens on our Discord. We also have a Discord forum where we have longer threads about issues that people are trying to search for or recording problems that people have seen. They are looking for answers of, "How do I do X on Appsmith?" We use a forum like Discord for that.

We have all of our issue management on GitHub. These are largely the tools that we use but we do build a lot of internal tools on Appsmith that connect all three of these to make it easy for our team to work across these platforms. Managing all of this content from these three platforms, intercom, plus email is hard. We have internal tools to help us do this.

That's an interesting question. The problem with Discord is it's hard to search for an answer to a solution by going through a bunch of threads. When do you push people towards the Discord forum as opposed to the Discord chat server?

Every engineer at Appsmith is also part of our Discord community, helping people out with their problems. One of the things that we as engineers hear is we beat ourselves. Trial is at the core of what we do. Whenever we see an issue that has shown up a second time or a simple question that we know has an answer somewhere, we make sure that we updated our documentation and that there is something on Discord related to this issue. We begin to link people to these different forums and documentation so that they can find the answers themselves. It's more of guiding people to repetitive issues versus being able to analyze, "This is a new issue that has never been seen before. We need to triage it before we can direct people to the answer.”

In terms of your licensing, you are Apache2-licensed. Was that something that you spent a lot of time considering?

Yes. Early on, when we were trying to open-source this, we had a couple of directions we could have gone. We could have gone with something GNU-based to ensure that no competitors could use the code. The reason we built Appsmith was so that we could get into as many developer hands as possible. That means being as permissive as possible because we know that a lot of organizations have regulations against using MIT, even GNU can have licenses.

That was one of the core reasons why we went to the extremely permissive license. Having a more restrictive license makes sense for some products that are trying to build something that has a lot of IP in it. For application stuff specifically, the real defensibility is in the application's UI-UX end product vision that you are trying to build because that's what's constantly evolving and changing. As your community grows with you, your product is changing, and your vision is getting closer.

That's what you are trying to achieve with the community. That is extremely hard to replicate. You can fork the code and make changes to it but it's going to be very hard to package that off as a new product because it's going to be hard for you to maintain it in the long run, get new updates from us, and have a long-term vision as to, “Why did they build it this way and why are we taking these decisions over those decisions.” All of that is hard to replicate.

It sounds like the JavaScript runtime was a fairly major advance in functionality. Have you got things coming down the pipe that you are excited about?

For our Community Edition, one of the core things that we are focusing on in 2022 is improving our performance a lot more. We want to make Appsmith work well in the browser and make it extremely fast, memory-efficient, and performant. That's going to be one of the huge focuses for 2022. We are also going to focus on a lot more customizable thing.

We are going to focus on allowing you to add your CSS, react components, and JavaScript libraries and also be able to reuse these packages across the board. You need to be able to authorize these and use them across applications. Appsmith works well for a lot of cloud applications but unfortunately, you do tend to have to repeat yourself a bit.

We want to eliminate that and make it a lot more maintainable in the long run. For our Enterprise Edition, we are kicked about getting back to product-market fit. We are going to be launching back in another two quarters. That's going to have a lot of exciting features that a lot of companies have offered us for a long time. It's one of those things that you have to say no to for years. It has been hard but it was worth it because we managed to build something that the community loves. Now that we know that we have a little bit of early love in the community, we want to go ahead and get some love from some of these larger companies as well.

In terms of the security aspects, can you talk a little bit about that? By its nature, the application is very sensitive. I expect there are a lot of questions that you must get around, especially around the SaaS products, "How secure is it? How do I make sure that it's only you accessing our data stores and things like that?" Was that something that you were baked in from the start? Has that been something that has evolved over time?

It's baked in from the start. Access controls are something that we built to write on day one because we wanted to get it right. That also goes hand-in-hand with our self-hosting experience because we believe that self-hosting is one of the most secure ways for a lot of companies. Some of the key initiatives we have taken to ensure that Appsmith remains secure is our backend proxies all API and data costs through it. This ensures that the browser or front-end never has access to what queries are running. It prevents a bad actor from running sequel queries from the front-end.

The other thing that we do is make sure that the backend never stores any data. All data is simply proxied to the backend and is never stored on any of Appsmith servers, whether you are self-hosting or are on a cloud version, it doesn't matter. We never store any data. The third thing we do is ensure that any sensitive credentials are always encrypted on the Appsmith platform. We ensure that this encryption is only accessible on the instance that contains this information.

That way, we can protect it against anybody getting access to the data but still not be able to decrypt any information and access it. There are a ton of security measures that we have put in place on a cloud instance specifically. We are undergoing SOC 2 compliance with a lot of penetration testing to ensure that we are secure from the inside out. One of the best things about Appsmith is that you need to take and put it behind your VPC firewall. You can always be sure that you can control security. That's why people love us. It's easy to be sure that it's extremely secure from day one.

I'm curious to know. Do the integrations that maybe your SaaS customers, the people tend to point your platform towards REST and GraphQL APIs as opposed to directly connecting to databases? Is there a whole spread of how people are using it?

It's a whole spread. It depends on where the company is in its life cycle. What we have seen is that typically mid-sized companies have a lot of backend APIs already created. They prefer to consume these back in APIs because they come with authentication baked in. They already have the business logic for certain workflows created. It's easy to reuse those, whereas companies earlier in their life cycles that don't have these APIs up prefer to go ahead and query the databases out of the box.

Sometimes when you are trying to replace an existing workflow, which is typically on Google Sheets, then people prefer to use that Google sheet integration because that makes it a lot easier to migrate the data. They don't need to create a new data store. They can use Google Sheets as their existing data store but they can build a nice custom UI layer on top of it. These are some of the things that influenced people and how they want to interact with their data.

You described it as API but with intelligence or humans as part of that process, which is something that I hadn't conceptually thought about. The way I saw it was, "Our platforms run on Django. We use the Django Admin interface a little bit to do stuff but we have written our CRUD screens because we don't want people being able to go ahead and delete a bunch of stuff by mistake." In my head it was very much like, "Instead of having to write CRUD screens by hand, it does that." It's interesting that you talked about it conceptually as an intelligence API connector. Has the positioning of the product been a challenge in that regard?

Appsmith can be used for a broad variety of use cases. A lot of people even tried to build external-facing applications on it here. We get requests from forums for customer portals and even eCommerce websites but the platform isn't yet geared for that. At its core, one of the things we tried to do with Appsmith is to reimagine software development. We are trying to change the entire internal tool stack, which means that we are trying to replace your typical way of creating backends and building front-ends, VM deployment applications, and pretty much all of it.

The positioning is a little hard but the thing that we were able to latch on to early on was this core need to build internal tools that developers were tired of building. Latching on to that problem was easy. Once people were able to connect with that problem, they immediately got it, "This solves my problem because it's not out of the box where I can't customize it but at the same time, it gives me all of the UI elements very well-packaged. It also gives me the logic and freedom I need to construct these the way that I want." It has satisfied that core need. People were able to connect with the product early on. That's how we will be able to communicate it to people.

Have you come up with any interesting tricks in terms of dealing with those security problems of how to access the database without opening up access to IP addresses? That sounds like a difficult problem to try and solve.

One good thing was that we didn't have to solve it too much early on simply because people would self-host Appsmith within their DPC. They needed to white list the Appsmith for instance, on their database. That was a pretty straightforward solution. We have been getting more requests for custom authentication certificates that people want to upload onto Appsmith so that it can do a handshake with the external database and then securely communicate.

One of the great things about the Appsmith community because it's so engineering-focused, is that a lot of times, we get the problem as well as the solution directly with the problem. We are hardly ever guessing, "How should we solve this problem? Is there some nifty trick out there?" Generally, the engineer has specked out the issue so well that we know, "This is a great solution." Not only have you told us that you have a problem. It's like, "This is exactly what I want you to do."

You must know more about OAuth, workflows, and summon integration than you probably ever wanted to know.

We know a lot more about software development after building Appsmith because it's such a broad product. Appsmith is a REST client with pgAdmin, a UI builder, a JavaScript framework, and our deployment platform all bundled into one. You end up covering so many aspects of development that you have to broaden your horizons in all of these different areas. We have learned a lot about all of these different topics.

It's a pretty audacious thing to build. You had a clear idea in your head when you started about how much code you were going to have to write.

When our Arpit and I started, we had this bold idea that we were going to have a good MVP in six months. Six months in, we were looking at each other shocked at how complex the product was to build. It took us six more months to get to the level where we were happy with the product. That's a testament in itself. It surprises me how complex what we were building was.

To be honest, it does still continue to surprise us every now and then when a user comes up to the feature request and says, "I would like this feature to work in this way on this particular machine or with this particular data source. I would like it to work for these types of users as well." It surprises me, "That's another use case that we never thought about before." It's always an ever-evolving challenge.

If you want to connect to GitHub, do you write bespoke connectors for these things? Do you point to their APIs and ingest whatever open API schemas they have? When do you decide to put a GitHub logo on the plugins thing rather than say, "Go and point at an API. You figure out?"

Early on, we decided that for anything that has a REST API, we were going to tell users to use our REST API client. Anything that needed an SDK such as the 5S SDK or the Java SDK for SQL, we would make custom connectors out of those. To facilitate the REST APIs, we also created a powerful cURL importer. You can go to any documentation out there, copy its cURL, and paste it inside Appsmith, and it will automatically run that API. That's the beauty of Appsmith. You can copy cURLs and bring them into your system super quickly. That helps us work with different platforms like Postman, Hoppscotch, Insomnia, all other documentation clients out there, and pretty much everything. It's easy to bring APIs into the system.

What we have also realized in working with these different SaaS providers is that their documentation is quite confusing. It can be very daunting to work with because you have to read up a lot of content to understand how it works. At the same time, because APIs are possible, we wondered, "Could we create a meta platform that could label different fields inside an API so that users could intelligently configure them?" They are also working on an interesting feature that allows developers to contribute API integrations without having to write a single line of code. You can just copy a cURL command, annotate it with different pieces of text, and create an integration on the fly.

It's interesting because Flagsmith has a full API but we need to do a bunch of more work on the documentation for it. It's amazing how you open the browser inspector, do whatever you want to do in the browser, find the request, and grab the cURL for that request because the API can't lie. There can't be a mismatch between the documentation and the API because there is no documentation. Nikhil, it has been fascinating talking to you.

It's funny because a couple of years ago, we were trying to figure out, "Do we start writing our few little CRUD screens? Do we use a tool like this?" We went down the write-it-ourselves route but I'm going to give it another look and see how we get on because we were a target use case for you too. I'm bought over by how you have pushed this. It's great to see. I look forward to seeing how you roll out the enterprise product because that seems like a massive opportunity.

Thank you so much, Ben. It was great being here on the show and talking to you about all of this. I'm excited about the future of Appsmith as well. It has been a real pleasure talking to you.

I might hit you up in a year or so. I would love to get your thoughts on selling platforms like this into the enterprise because that's a big sweet spot for commercial open-source companies. People quite often don't like to talk about it. It's one of the few things that open-source companies are still a little bit guarded about. Good luck. Congratulations. Well done.

Thank you so much, Ben. I would love to chat again.

Take care.