Designing With Developers With Abhishek Nayak Of AppSmith

Great digital products don't just happen. They're the result of a strong designer-developer relationship. That is because the two groups bring different but complementary skill sets. By understanding and respecting each other's strengths, the designer and developer can work together to create user-friendly and technically sound products. In this episode, Abhishek Nayak talks about how their company, Appsmith, addresses some of the common issues in the designer-developer relationship and how they have set up both sides for success. Abhishek is the CEO and Co-founder of Appsmith, an open-source low-code tool that helps developers build dashboards and admin panels very quickly.

---

Designing With Developers: The Key To Creating Successful Digital Products With Abhishek Nayak Of Appsmith

Improve The Designer/Developer Relationship, Create A Better Product

Leigh: The designer-developer relationship is very important to any team that's building digital products. It can also be a source of some problems when it comes to making great products. There are communication issues. Both teams have different processes. There can be a lack of understanding of what the other person does. Sometimes there's a lack of understanding of the value that each brings to the design of a product. That's both visual and how a product works.

For my guest, Abhishek Nayak, that relationship is multilayered. He is the Cofounder and CEO of Appsmith, which is a product that is built for developers. It enables them to create custom and easy-to-use apps for internal business users. For their company, the designer-developer relationship has been one of the drivers of the success of their product. I wanted to talk to Abhishek about how they have addressed some of the common issues that come up in the designer-developer relationship and how they have set up both sides for success.

We had a great conversation and it's full of useful information and some good ideas that I hope will spur you to improve your designer-developer relationships in your team and organization. Abhishek also shared with me Appsmith's design system and how they use it. We've made that available for you as a bonus episode on the YouTube channel. It's very visual. You can check that out on the UX Cake YouTube channel where you can also watch the video version of this conversation.

Abhishek Nayak has been a Cofounder and CEO of four startups. That's how he learned the importance of design, research and creating user-first products to develop successful products that your users want and love to use. Appsmith is Abhishek's fourth startup. It started as a small open source project that is used by over 1,000 teams, employs people in 8 countries and has raised over $10 million in capital. It's very interesting. Let's jump into this conversation with Abhishek.

---

Leigh: Abhishek, thank you so much for joining me on the show. 

Abhishek: It's nice to meet you, Leigh. 

Leigh: I'm excited about our conversation because this comes up all the time in design, UX, research and design with developers. Our conversation is going to be a little interesting because we're also going to talk about designing for developers. Let's start with a little bit about your company, Appsmith. All of the designers out there who are working on digital products need to keep developers in mind when they're designing. It's often not even top of mind at all because we're talking about user-first. You talked about being user-first in the creation of your product and your users are also developers. Tell us a little bit about your product and the user of your product. 

Abhishek: Appsmith is an open source project that's used by developers, primarily backend developers, to build all custom internal applications. These are customer support, dashboards, marketing automation tools or operational tools. These are built by developers but used by different users inside a company. They could be in customer support, finance, marketing or wherever else they need a customer. Our primary user is the developer so we focus a lot on getting the developer experience right. 

We also focus on enabling the developer to build well-designed products because Appsmith is used to build different apps. It's easy to create ugly web apps which don't work so well. Our product helps them build well-designed web apps without putting in too much effort. We also think about how we make the design more accessible to somebody who doesn't have the time or patience to understand the fundamental principles of desires. A product needs to act like a designer.

Leigh: You've got two layers there, a developer who's creating the Appsmith interface and then the end user who's not a developer who's using that interface to create an app for maybe a customer service person. 

Abhishek: The developer is using Appsmith to build apps and the end user is simply using it. The end user isn't building apps but they're consuming and using the apps that have been built by the developer.

Leigh: You've got these developers who are not designers building the apps. You talked about how important it was to you to make sure that the design was top of mind. You came to this understanding of how important design was. Do you want to tell us a little bit about that? 

Designers enable engineers to sketch out the solutions that they have in their minds.

Abhishek: In Appsmith, we follow a product guide, which is you have a product manager, designer and an engineer as collaborators on every single feature. We have three founders. Between the 3 of us, 1 of us looks at design, which is me. I then have another Cofounder who looks at the product and another Cofounder who looks at engineering. What this has meant is designers have a real seat at the table. They can initiate projects where they think the UX is lacking or if they think of a cool new idea that they think is important to users. I've worked at companies where, generally, designers give service to products. 

Those products don't tend to be so good because designers have a very different way of looking at the world. They're good at understanding what people need even if they're not expressed verbally. They're good at understanding that, solving for those things and applying creativity so that you do it in a way that feels natural for the user and aesthetically pleasing. I've worked at places where the design was considered like a second-tier citizen in comparison to product or engineering so I've seen the negative effects that it had on the product. 

That's why when we were doing this startup, we had decided that even though none of us are designers, we knew that we had to have one of the founders lead the design and have a head of design reporting to them instead of having the head of design report to the product. That's something that has worked well for Appsmith. That keeps the design front and center. Design can be even more important at Appsmith. I wish we had more designers. I wish people were more design-led but I'm happy with where we are.

Leigh: You mentioned to me what sounded like a pretty high designer-to-developer ratio, which is higher than a lot of places. Tell me what you mean by you wish it was even more design-led. 

Abhishek: The ideal ratio for designers to engineers is probably 1:2 or 1:3. A lot of ideas and solutions can be explored in the design phase. This is through user testing, actual real prototypes and doing a lot of iterations. When you have a lower designer-to-engineer ratio, your iterations are a bit slower because you're always relying on an engineer to iterate on Real Code, which is always a lot slower. If you have a better designer-to-engineer ratio, you can run better iterations. Therefore, you can be short about what's going out into production because you've tested it and tried all those ideas that you had in your mind about the solution. 

It increases the accuracy. It might feel like overkill but in my experience, it's not because I see a lot of companies push out an MVP, not having thought through the design. The MVP might take you 1 month to build but then you spend the next 6 months learning that the customers don't like what's out there, trying to make small micro iterations on top of it, only to realize at the end of the 6 months that, "We should have started this from scratch. We should have gotten it right at the very start." 

There's always this idea that you should shoot first and aim later. When you're doing that with designers, where they are doing the prototyping and you're rapidly testing it with users, the likelihood of you making mistakes when you go into production is a lot lower. Design tools are so flexible. You can get almost every single interaction that you want and test every single thing that you want without code. That's why I believe the designer-to-engineer ratio, I would wish it was 1:2 but it's incredibly hard to hire good designers, as you probably know. There are a lot more engineers in the world.

Leigh: That's interesting. That's the opposite of so many places where they put so much focus on hiring developers. You're right. It is hard to find good designers. I want to dig a little bit into the relationship between the designer and the developer during that early phase. In my experience, part of the problem designers have in working with developers is that when you're in the design phase, the developers aren't there. They aren't available because they're busy working on something else. Tell me a little bit about how it's working with you. 

Designer Developer Relationship: Appsmith follows a product triad. There is a product manager, a designer, and an engineer as collaborators on every feature.

Abhishek: That's a real problem. When we have new engineers join the team, they've not worked with designers this closely. The relationship has been a waterfall approach where designers prepare the files. They do a hand-off and then the engineers get involved. At Appsmith, designers and engineers are involved at the start of a project. 

Our designers conduct workshops with our engineers and the PM. It could be figuring out the problem statements because designers and PMs work together on figuring out the scope of the feature itself and the co-writing of PRD. Designers also enable engineers to sketch out the solutions that they have in their minds. Engineers are bright. They have ideas for how problems could be solved. They might not be thinking very carefully about what problem they're solving but they are sharp about how you solve a particular problem because they've done it so many times before. 

They get frustrated with designers when they see the final files if they've not been involved at the start because the designers have not taken into account the ideas that the developers have in their minds. Here at Appsmith, we encourage developers and designers to both sketch and wireframe ideas very early on so that the designers have a mental dump of every single idea that everybody has. When you sketch it out, the ideas have become a lot more tangible. You don't have something that happens where an engineer comes back to a designer and says, "I have a component which works slightly differently. Why don't we use that?" 

The designer was never aware of it that such a component existed and it might even be a better solution, versus if you get the engineer to sketch it out, you can have a real dialogue about it about why the solution is better than the other. The most important thing that it does is it gets the engineer involved early on. Even though the designer might be figuring out the exact details of a solution, the engineer knows that their ideas and thoughts have been considered at the start. Therefore, when it's a discussion of the final hand-off, it's a lot easier because the engineer knows where the ideas originated from and why this particular solution has been chosen over anything else. 

Leigh: Having an engineer in the initial or even concept workshop or a design sprint and having the actual developers involved in that, in my experience, has also been fantastic. Tell me about any resistance to that that might come up or maybe initially came up when you started doing this. 

Abhishek: I often see this resistance from engineering leaders sometimes because they might be mentioning that engineers are on the actual output of code and not based on the quality of the ideas or execution. I've often seen engineering managers often try to ensure that engineers are always working, coding and building something or the other. That's the resistance that I've faced. I've not faced this resistance from engineers because engineers love to talk about ideas. 

They also considered this to be work, which is figuring out what to build and how to build it. I face some resistance from engineering managers. That's where we have a conversation about how getting it right is more important than spending all your time coding because that's not necessarily going to get it right. You don't want to spend 2 months building something only to realize you need to dedicate 3 or 4 more months after that to undo or improve it. Why not just do all of those discussions very early on? 

Engineers have to be a part of the PRD writing process and the designing process. Even if they might not be contributing every single day with ideas, they should be aware of what's going on and see the entire journey. If they do that, the building process is a lot faster. The engineers often have a good idea of how to create extendable features because they know that if you've done X, you probably might try Y in the future. Therefore, we should prep for it. We should have points of extension in the product. If they're only involved in the end, they get to see the well-formed idea and product. 

When designers are prototyping and rapidly testing with users, the likelihood of making mistakes when going into production is much lower.

They can't envision the future. That partnership is important. I wouldn't say it's easy to do because a lot of engineers have not worked this way but once you try it out, you'll love it. The design is way too important to be left to designers. It means it's so critical for a company's success that every single person needs to understand the fundamentals of design. You don't need to understand everything about UX or these tech experts. The fundamentals are necessary for everybody doing the design. 

Leigh: I want to get to that because I love what you told me Appsmith is doing as far as setting a baseline of understanding the fundamentals of UX. Before we get there, you were talking about the need for bringing the developers into these workshops and so forth and the resistance from engineering leaders. Part of that also is the process. Let's say you have an agile process, sprints, stories and everything lined up to work for measuring velocity like what you were talking about. You're talking about taking a few hours of this developer's time possibly half a day or more in a week. What change to the process did you have to set up to make that even possible? 

Abhishek: The process is something we are still figuring out because, in the early days when we were a smaller team, the process was non-existing. Everybody was part of a lot of these discussions. As we are beginning to measure velocity, we are trying to figure out a good way of measuring accuracy and the success of our work. That's more important than measuring the input. 

Some of these inputs cannot be measured like somebody spending two hours learning a new concept so that they could think of a new solution. It's tough to measure that because you have no idea if it's all going to be useful. If there's no space for that, you're simply not going to be able to create good solutions. That's the problem. I would love to move faster but at the same time, I understand that some of this work requires so many iterations that it needs to take its time in some cases. 

There's a question of how we move faster but improve quality. I don't have a great answer here. I'm still figuring it out. What I know is with some of the greatest movies were sometimes over budget and took way longer but they were memorable movies. While movies might be under the budget that was produced at the exact time that they had planned for, they might be unmemorable and worthless to the world. 

The question is, "Is it a good idea to take slightly longer because you're going to produce higher quality work? Should you use deadlines and timelines?" It's so easy to measure deadlines. You gravitate towards deadlines and use data as a measure of somebody's output or productivity. I wish there were a different way of measuring accuracy and quality of work but I haven't found a good answer yet. 

Leigh: I love that analogy of the films. It brings to mind the need for prioritization of impact. There are some things that you need to get out. The impact might not be huge so maybe it doesn't need to go over budget. That's not going to be your big blockbuster but it's important and needs to get done. Whereas there could be some other larger features that are going to impact the user flow. That takes more time. It also brings to mind the design systems, design ops and research ops as a company grows and scales, which Appsmith is in the process of scaling up. You have ten designers, which is more than enough for having a design system. Maybe you could tell us a little bit about how your design systems work between the designers and the developers. 

Abhishek: The first topic with the design system that our designers started using and our first version of the product, even most of the product, was built without a clear design system. We only started introducing a very clear design system after our first launch went well. We then realized, "Let's work harder on getting the design system out." What I didn't think we did a great job of was ensuring that the tokens used by designers and developers needed to be the same. We didn't make them the same. Looking in hindsight, that was a rookie mistake. Essentially, that meant our developers use different tokens in code versus what designers use.

Designer Developer Relationship: Every engineer is aware of the design process and gives the due value and time that is required to do the design process.

Leigh: Can you explain the tokens a little bit more? 

Abhishek: What I mean by tokens are colors, font and font styles. What it's called in code is different from what it's called in our design system that lives in Figma. In code, it might be called Grey Ghost. While in design, it's called Greytan. With that, the first version of the design system implementation wasn't so successful. We are in the process of revamping that. We have design system engineers and designers working together to create a great design system that lives in Figma but also lives in code. Both of them are the same in terms of tokens. Previously, we didn't have design system-focused engineers but now we have two design system-focused engineers who work with one designer and only work on the design system. 

They started working on it not so long ago so we've not seen the results of it yet but the initial results are promising. Every front-end engineer in the company is excited that they can reuse components very easily and that they don't have to think of the tokens themselves. They can rely on the designers. The designers and the design system engineers agreed on a common language and how to translate the design to the components. They have frequent discussions around it. It's going smoothly. 

Leigh: With the agreement on all the naming and components, did that happen together with a designer and a developer or with multiple designers and multiple developers?

Abhishek: It happened with engineers and designers together. I wouldn't say we figured everything out yet but we've figured out quite a few things around the language and communication, a bit like naming, the states of the component, all of those things in collaboration with engineers. 

Leigh: I want to get back quickly to what you mentioned before. Developers all have this baseline fundamental understanding of UX. Tell me a little bit more about how you do that at Appsmith. 

Abhishek: Every year, we've done a design course for our developers, as well as our QA engineers. Not everybody has completed it. Half of the company has completed the course. The course goes over basic UX fundamentals so that you understand what a designer means when they say user testing, affordance and things like that, where the common language designers use is accessible and understandable by engineers. 

The other thing it does is show engineers how some things they might have assumed to be simple need a little more thought. You might need to do user testing in places where you might not have expected. You also understand why simply going and copying somebody else's interface is a terrible idea and should start with the problem statement first. There's a design course, which has been done by half of our company. 

For a company's success, everyone needs to understand what design is. You don't need to understand everything about UX or aesthetics, but getting the fundamentals is necessary for everybody to understand.

We've done one course like this every year. The course is titled UX Design for Non-Designers. Anybody who's interested in learning more about it participates in the design and learns about that. That has had a good impact because every engineer is aware of the design process. Every engineer gives you the value and time that is required to do the design process. They understand what's going on when we are taking a little bit longer to do user testing. That was important for us and has helped us quite a bit. 

Leigh: What's the motivation for non-designers, developers, in particular, through the course? 

Abhishek: The motivation is that for you to be a great engineer, you need to build a great product. The only way you can build a great product is if you understand what designing a product mean. If you're an architect, you need to understand the materials you're dealing with as a civil engineer. As a civil engineer, you need to understand a little bit of architecture. Otherwise, you're a bricklayer. You're not necessarily understanding how things are built. 

It does make sense for people who are working closely with each other but have different rules to understand the fundamental principles and thoughts behind why they do certain things. It makes life for everybody a lot easier. At Appsmith, the motivation is that our engineers want to succeed and for us to succeed, our product has to be well-designed. For a product to be well-designed, they also have to play a role in design. It can't be just designers doing it. 

Leigh: One of the biggest issues that come up between design and development often is communication. It sounds like part of how you're addressing it are a couple of ways, which is bringing developers in early and then also giving developers an understanding of UX. What else happens? I'm sure that it's not 100% perfect at Appsmith. What are some of the issues that come up regularly? 

Abhishek: The common issue sometimes that comes up is, "Let's do a quick and dirty solution for some things." For some things, it's okay to have quick and dirty solutions but in other areas, it costs us heavily because you do something quick and dirty, then you have to maintain it for a while because customers start using it. You can't ever go back and undo it because somebody is using it. Especially in the enterprise, people rebel when a workflow they used changes. You have a tech deck but there's also a design deck. Design deck is probably one of the biggest reasons why you have new startups who come in doing the same thing that a legacy player is doing but everything is a little bit faster and nicer. 

I'm sure the team behind the legacy product also understands that their product is not well-designed but they are trapped by their users and success. In Appsmith's case, our growth is happening very rapidly. We might fall prey to that same thing if we do things quickly and dirty and do too many solutions without thinking it through. When you're an engineer, you know you can build anything. 

You're often thinking, "How do I get started on building this out? This is a bug. This is a lot of feature requests. I have an idea for it. Why don't I go in and execute it? Why do I need to spend even a few hours discussing it with a designer or product person to figure this out?" That's something we run into where we have the design and tech deck, which is difficult to undo. That's something that comes up. 

Designer Developer Relationship: Every design file that designers share is on a public channel where engineers are present. Every time engineers share their work or deploy a preview of something they're working on is on a public channel where designers are present.

The second thing that comes up especially shows up in our visual design where once the developers have gotten deep into the execution of the product or feature, they might not be sharing their work early enough with the designer to do design QA. They only reveal the pre-launch version of the feature to the designers. Designers do not have enough time to do design QA but because the engineer is nearly done with the feature, they want to push it out and release it. It gets released with a lot of UI bugs, which would have been caught a lot earlier if there was design QA. These are top-of-mind things for me that I've been thinking about. 

Leigh: What are your thoughts about mitigating both of those problems?

Abhishek: For the first one, you need closer collaboration between designers and developers. The designer-to-developer ratio isn't as good as it needs to be. Developers often feel, "I can't ping the designer because he's working on a different project. She doesn't have time to work on this so let me go and take a decision." If the ratio were better, that would happen less often.

The second thing is designers need to understand their development workflow a lot better. In Appsmith's case, every time a developer checks in code, a deploy preview is created. If designers knew where to look for it and kept looking at it repeatedly, they could give feedback a lot more often. They shouldn't wait for developers to come and talk to them. 

Leigh: The second issue is design QA, which is such an important issue. It's funny because it raises its head over and over again. Everybody understands and you try to build it into the process but this or that person doesn't get it or understand. I'm curious to know your ideas for mitigating that problem where a design QA doesn't start early enough. It's part of what you talked about before where there's this regular communication between the designer and developer, that's going to help the design QA as well. 

For a developer, it's having more of a presence from the designer regularly. I've seen two pizza teams, which is what they would call it at Amazon in some other places, where you have a designer who's co-locating with developers or if they're remote, then they're online together every day. When there's more of that presence, the developer remembers. You're breaking down the barriers. It's easier to say, "I don't want to make this assumption. I was going to do this. What do you think?" Tell me a little bit about what you're thinking about doing to mitigate the design QA issue. 

Abhishek: In a remote environment, it's tougher to have these hallway conversations and water cooler conversations where they keep running into each other. That's difficult. You also don't want to overburden people with a standing meeting every few days when it's not necessary. I don't have a great answer there but one of the things that we've done as a process is every design file that's shared by designers is always on a public channel where engineers are present. Every time engineer shares their work or a deploy preview of something that they're working on, it's always on a public channel where designers are present. 

It's not happening on DMs because when you do things on DMs, you forget to include people and share knowledge and decisions with others. That's something that we've done as a process. We've also exposed the design process and the exact steps that our designers are going to follow in a project. That's defined, exposed and available to engineers. Similarly, the engineering plan is visible to designers so they're aware of when they should expect the deployment preview of some work. Those are some of the things that we are doing.

People have the right intentions but might not have the systems or the right understanding of why they should do things.

It's a fundamental issue that leaders need to solve and practice every single day to succeed. That's the only way to embed this into the culture. It needs to start with the engineering managers, the senior product designers and the founders. All of us need to be doing this day in and day out. We codify this by describing what we are doing and why we are doing it. That's the bit that I'm trying. I believe people have the right intentions but people might not have the systems or the right understanding of why we should be doing it. If they understand why they should be doing something, it's a lot easier to practice it. That's the way Appsmith has done.

Leigh: We've covered a lot about how designers and developers work together. What else did you want to talk about regarding designing for developers? 

Abhishek: One of the interesting things about building the developer experience has been how you as a designer understand the developer's work because you're not a developer. It feels like a highly technical thing to do. There are a few things that we've been trying to do here at Appsmith. Number one is our designers do customer support where they're talking to developers and trying to unblock them, even if they're not the developer customer. 

Designers are part of our support roster. They do support for one week every few months. That's something that we've tried. The other thing is to get engineers to sketch out their ideas. As a part of it, engineers share screenshots of the products that they use or videos of them using a certain product or doing something. This exposes our designers to their workflow and their understanding. 

Something that I've been doing is I watch a lot of YouTube videos of coding interviews where existing developers are doing these mock and practice interviews. There are a lot of them on YouTube. I love looking at that because, in that hour-long interview, you're going to see your developer solve a real problem and build something out. During this period, you're going to see them change Windows, Google for something, go back to certain Windows and describe how they're thinking through the system design and the coding process. 

That's something that I've been doing to keep myself updated on what the developer experience is like. There's something I've been recommending to a few designers in our team but I've been practicing it to see if it does help me understand the developer a little bit better. If it does, then maybe in a month or so, I'm going to try talking to our other designers and tell them, "This is a great way." You could be having lunch and watching somebody go through something. It's interesting to do and see that. 

Leigh: Specifically, this is for designers who are designing a product that's going to be used by developers. It sounds like you also do quite a bit of user testing. Tell us a little bit about that and how you incorporate testing developers. 

Abhishek: In some cases, we do user research at the start of the project to discover problems and identify what ideas our users have. In other cases, user testing happens once we figure out the early prototypes and solutions. It depends on how much context we have for the problem. In our case, a lot of our user tests, especially if it's user research, which takes a lot of time, we give out a $50 Amazon gift card. In some cases, we've even shipped out swag to people who have dedicated time to us so that users don't feel like we are constantly pinging them for free research but they're not getting anything in there done. We have a user research budget that we spend on user testing. 

Designer Developer Relationship: At AppSmith, the designers do customer support, where they talk to developers and try to unblock them, even if they're not the developer customers.

We also use Dovetail to collect and store some of our sales recordings, user testimonials, as well as user research content. That's a tool that we all began to use. It's been helpful because you can go back and find ideas or interviews from months ago instead of keeping them in Google Drive or in a folder somewhere, where it's difficult to find the exact point you need to do. I like the fact that there's a tool like Dovetail that we can rely on.

Leigh: For folks who are not familiar, Dovetail is a product that is a database for your user research. It's searchable and you can tag it. It's highly functional and has a lot of features. One quick question I have is when you're working with developers and this is true for product people and also for designers, it's easy to fall into that mindset where you think, "I'm the user. I would do it this way. That's the way it should be designed because that's how I would do or use it." 

It can be detrimental to designing a product when you rely on that, "This is how I would do it." You have to remember that you are not the user. You're way too close to know that. Since these are developers who are creating a product for other developers, I'm curious if you run into that with the developers saying, "I'm the user," or anything coming with that perspective. 

Abhishek: Being the user, one of the things that are an advantage is if you are the user and are building something that you would want, that's more advantageous than not but it can be quite damaging because you might have only a user-deficient solution for a similar problem in the past. You've not explored all the best solutions for that. It is a user-deficient solution and that's the one that you believe is the right thing to do. That's where it's important for non-users to be part of that. That's where designers do a great job of asking the right questions and trying to understand the fundamental motivations behind why somebody like that solution and what's the reason for it. 

That's where designers have to do a lot more work and extract those insights. Also, be aware of the fact that what people see is not necessarily how people behave. In my experience, they've been different. You might see something but you might behave differently. That's where designers have gone through the cycle of doing user research the wrong way and then suffering because of that. They then realized, "I need to do it differently. I need to rely on the users to understand the motivation of the problems and the problem statements." Pay attention to the solutions that they've suggested but only as indications for what the solution could be but not go on and execute it. 

In our case, we've certainly made that mistake many times because my cofounders are engineers. I also used to code a little bit better a long time ago. We've certainly made the mistake of doing deficient executions of ideas, which we had borrowed from another product that we've used. In some cases, the test worked out fine but in a lot of cases, we have to undo it. In the last few years, we've had to undo a lot of those decisions. It doesn't feel like we will run out of those mistakes. That's the truth. We keep doing them over and over again but at the same time, overall, most of us are becoming a little bit bored with this pitfall and we're trying to address it. 

Leigh: Thank you so much. As we wrap up, is there anything else that we didn't cover and that we missed? 

Abhishek: We had a great conversation and we delved deep into a lot of things that I'm passionate about and thought about every day. 

Leigh: For readers who want to learn more about you or your company Appsmith, where can they do that? 

Abhishek: They can find me on Twitter. If you search for Abhishek Nayak, you should be able to find my Twitter handle. The website is Appsmith.com. 

Leigh: I enjoyed our conversation. Thank you so much.

Abhishek: Thanks, Leigh. This was an interesting chat. I hope more people believe in design and understand the importance of applying it every day. 

 Important Links

• Appsmith

• UX Cake – YouTube

• Figma

• Dovetail

• Abhishek Nayak – Twitter

• https://www.Linkedin.com/in/AbhishekNayak/

• https://GitHub.com/AppsmithOrg/Appsmith

About Abhishek Nayak

As a co-founder and CEO of four startups, one of which was funded by Sequoia Capital, Abhishek Nayak is well-versed in the art of starting and scaling a business. But during a stint as an entrepreneur-in-residence at Accel, he discovered how much time engineers spend building internal applications. So he and two co-founders created Appsmith to put customizable app tools directly into developers’ hands. The once-small open-source project is now used by over 1,000 teams, employs people in eight countries, and has raised over $10 million in capital.