Endpoint ft. Kushagra Gour: A Builder’s Philosophy on Craft and Empathy

An Indie Builder with over 15 years of professional frontend experience, Kushagra Gour is the creator of the beloved CSS code-golfing game CSSBattle and more. He embodies the spirit of a creative problem-solver, with a deep passion for building things that people love to use, and also channels that passion into educating the next generation with his tech news channel and own Frontend Bootcamp.

We spoke with Kushagra to get his perspective on the art of building great software

A Q&A with Kushagra Gour

Q. As a front-end engineer who’s built tools developers love, how do you balance engineering elegance with real-world product needs?

I don’t think it’s really a problem to balance those things because I don’t think they are counterparts. Real-world product needs are what you always want to have — you should always have them. That’s not only possible when your product is required by hundreds or thousands of people (or developers in this case), but even if you want such a product and you think you would be using it once it is built, you are a customer, right? You have at least one customer — which is you — and therefore it’s a real-world product requirement. That should always be there.

And then if you talk about engineering elegance — it’s something that is your characteristic. If you strive to have good engineering, then you would do that for any product. It doesn’t matter if it’s a real-world product or just your MVP that you’re going to try out in the market or, for that matter, anything that you’re building.

It’s your characteristic — if you want to build something good, you do that for every product.

Q. How do you maintain development velocity when dealing with API dependencies across dozens of teams?

API dependency is a real problem to solve when you’re building a new product because it’s not always that you will have APIs ready while you’re building the product.

Especially if you talk about front-end development, which I deal with, you are often in situations where the APIs are not ready and you’re dependent on a backend team or an infra/DevOps team for a certain APIs.

That’s always there, but then there are a lot of ways one can adopt to not get blocked and still move forward. One way is mocking APIs. You can have dummy APIs that you can use temporarily for your frontend while building it and move ahead without getting blocked.

And if you talk about different levels at which you can mock: 

• If you don’t know the keys that are going to come in the response, you can just have completely random keys determined by you that you think should be there and just create a dummy JSON mock and use that.
• If you know the keys beforehand (maybe you already worked on some documentation with other teams), you can have the actual keys in your dummy response — a more realistic setup. 
• Next, you can have the actual response, but not coming from the real API server — maybe from a service worker, a dummy server running on your own local machine, or any third-party service (like Requestly). So in this case, it’s a little better than the previous two levels — you have the actual response coming in, just not from the real backend. Essentially, you’re building the same thing you would have in the end — just with a different base API URL.

Q. How do you see AI transforming the way we test and validate front-end code?

AI has drastically transformed the way we do stuff — not just coding but almost everything on computers.

Testing and validating front-end code, I see it similar to the way we were writing content before. We used to have tools like Grammarly that validated our writing for spelling mistakes, grammar, etc. But now, with AI, people don’t just check their content — they generate it with AI – partially or completely.

Just like you have assurance for AI-generated content that it would be well-structured, with no spelling or grammatical mistakes — similarly, the front-end code generated by AI can be expected to have no syntax errors. You won’t find those petty missing semicolons or wrong equality operators — just like you won’t have spelling mistakes in AI-written content.

And then we can go one step ahead and have tests generated by AI itself before even writing the code and implementing the functionality. You can write a PRD describing all the functionality from the user’s perspective and give that PRD to AI to write tests for you. Then, when you actually implement the functionality (or get AI to do it), those tests can serve as validation for the generated code.

Q. As someone who loves to build tools from scratch, how do you decide when it’s better for a team to adopt an existing open-source tool versus building an in-house solution?

Like most things it depends on a lot of factors and one needs to evaluate on a case by case basis what is best. To start with, you’ll need to check if your team does have bandwidth to build something or not. If not, it is clear you need to adopt an existing tool. Sometimes, your team might have bandwidth but not the skillset. If you want to build it in the best quality, you’ll need to have domain knowledge, knowledge about performance, accessibility and more, so that in-house solution works best for your end-users. If you lack any of these skills, the in-house solution won’t be at par with the third party solutions and then it doesn’t make sense to use that. In some cases, the thing you want to build might not matter much in the product, maybe it’s just a small piece of logic. In that case, you could choose to write it yourself.

Remember, with any third party open-source tool you’ll almost always face a block someday wherein you have a  requirement and the tool doesn’t fulfill it. Good thing with open-source is that you can build the feature you need or patch the bug you face and open a pull request to the main project. But even then, the fact is that having a self-built tool gives you more flexibility and control for the future. But of course, you need to maintain it too. So depending on the tool criticality and size, choose wisely.

One interesting pattern that again surfaced recently is from the shadCn project – where you don’t use the third-party tool, but copy and bring it in your project. And then you can modify it as per requirement and maintain it as your own code. I like this way!

Q. What’s one recent change or trend in the tech space you’re most excited about?

Oh, this one is simple — I don’t think anyone would have a different answer today. For me, it’s definitely AI, which is the most exciting trend of recent years.

Personally, I began with building games — that’s been my passion ever since I started learning programming. I interned at a game company too. So my interest has always been working with code plus the visual design aspect — making it fun, gamified, and interactive.

Professionally, I got into front-end development because it was very close to gaming — it excited me. It wasn’t just writing code that doesn’t show up; it also had the UI aspect where what you program shows up visually, and you can animate things, build experiences, not just logic.

Later, I transitioned into product — building my own products and helping product teams in companies I worked at. That came from wanting to build experiences and make them perfect for end users.

With AI, what’s changed is that I can now do a lot of other things I wasn’t good at — using AI to finally build products in a very complete way. For example, I’m not too good at pixel design or illustration, but I like building products end-to-end. Earlier, I was dependent on hiring a designer or finding free/paid illustrations online. Now, with AI, I can generate illustrations exactly as I imagine — and in great quality.

Similarly, for areas like content or marketing, AI helps me do them much better. So now I can continue building my products end-to-end, but in much higher quality — creating better experiences for end users.

That’s why AI excites me even more about product development — I can build faster, better, and more complete products.

Q. What’s the most underrated skill for developers today, in your view?

I always say to all my Bootcamp students, focus on communication – it’s the most underrated but important skill for anyone working in a team. Communication is not just speaking and writing clearly, but it is also about writing your mails and chat messages clearly. Knowing how often to communicate. And when it comes to developers specifically, communication also includes the code comments, documentation pieces you write. Your commit messages, Pull request descriptions and tech specifications. Anything you write clearly around your code not only helps the developer but also the teams around the developer, current and future ones.

If you talk about current times, I would say the ability to use AI wisely is an underrated skill. Particularly if you are just starting or started recently. You need to be aware about how much AI to use. Because if you rely on AI for everything, you might become a victim of brain rot where AI does everything and you don’t understand anything. It might look fine in the beginning, but slowly the effects start to show up. Of course, you as a developer won’t grow. The features that you build with AI will be less maintainable because no one understands what was done, why it was written like so and other decisions around that code.

So I advise only using AI for doing things that you yourself can do, but just don’t want to do. Even if you get AI to create something you don’t understand, make sure you go through it and put in the effort to completely understand its working. Don’t let AI drive you, rather you should steer it.

Another important thing is Customer empathy. Don’t just pick user stories and build the features. Understand what the feature means for your end-users. How would they be affected? This will make you build features with more care, make them more performant, more accessible. You won’t stop at just deploying your feature. But empathy will make you dive into analytics to actually see how many customers are using the feature you built and if they are facing any issues or not. It will not only make you build world class products but grow you as an overall product person!

(Responses may have been edited for clarity.)

What was your biggest takeaway from Kushagra’s insights? Share your thoughts and join the conversation on LinkedIn!

Join us in celebrating Kushagra Gour and the incredible work of all the developers, builders, and product leaders who are pushing the boundaries of technology. Stay tuned as we continue to spotlight more leaders in our Endpoint series.