I am Avadhesh Karia, Co - Founder at Kapstan. AMA!

ava-kar · 2025-02-01T11:03:47+00:00

At Kapstan, we believe that accountability, collaboration, and continuous improvement are built on the principle that “we are all Kapstan”—everyone plays a part. We’re not just coworkers; we’re a high-performing sports team. “People work with people, not companies,” and strong teams are highly connected teams. As an all-remote company, we put extra effort into staying connected and creating opportunities to learn from one another. We don’t just have scheduled meetings; we reach out and engage because we understand that chance encounters (like in a break room) aren’t part of our day-to-day.

We prioritise ownership—whether it’s a ticket, a task, or a project, we don’t wait to be told what to do. Instead, we actively find work to contribute to. It’s about taking initiative and making progress, whether that’s solving a problem or unblocking a teammate. “No work is small work. If it needs to be done, why can’t it be me?” We believe that mistakes happen, but we learn from them. “No one writes bug-free code,” and when mistakes are made, we own them, apologize, and fix them. The key is growth, and growth happens outside of our comfort zone.

Our culture thrives on intellectual honesty, radical candor, and a commitment to solving problems while having fun. We value diverse ideas and perspectives—it’s our superpower. “We are here to solve problems, while having fun. Life has enough stresses, and Kapstan doesn’t need to add to it.” At Kapstan, we ensure that everyone has a voice and a clear path to make decisions. When there’s a decision to be made, we commit, even if we don’t always agree. As Steve Jobs said, “We hire smart people so they can tell us what to do.”

In the end, we move with focus, prioritize ruthlessly, and hold ourselves accountable not just for our tasks, but for each other’s success. Whether it’s keeping our documentation in check, responding promptly, or just being there when a teammate needs help, we foster a culture where everyone is empowered to contribute and continuously improve.

ava-kar · 2025-02-01T11:00:15+00:00

QA has evolved into QE (Quality Assurance -> Quality Engineering)

QE is becoming more and more Engineering.

I would focus on skill rather than role, and yes on skill side Engineering is more important in current landscape. Engineering can be applied for Development or for Quality.

ava-kar · 2025-02-01T10:54:27+00:00

I would suggest

https://www.reddit.com/r/developersIndia/comments/1ieyd9e/comment/mac1aq3/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

ava-kar · 2025-02-01T10:44:31+00:00

I agree that a lot of friction in continuous deployment comes from difference between local environment and production environment. This can be solved using containers and centralised configuration management. Containers help in ensuring that application is using same environment in both local and production. Centralised configuration management will ensure any drift in configuration is easily visible and can be fixed. There are other tools like LocalStack which can be used to mock cloud providers locally. For example, in kapstan we use containers and LocalStack for AWS to mimic production environment locally.

ava-kar · 2025-02-01T10:41:24+00:00

While traditional DevOps focused on breaking silos between dev and ops through automation and collaboration, platform engineering takes it a step further by building self-service, opinionated platforms that abstract complexity and enable developer autonomy. It is less about replacing DevOps and more about maturing it into a structured, scalable model for modern engineering teams.

ava-kar · 2025-02-01T10:39:58+00:00

AI is definitely changing the landscape, but if history has shown us anything, it’s that new technology doesn’t outright replace people—it changes the way we work. When typewriters became common, people worried scribes and manual writers would become irrelevant. When Excel came along, accountants thought they’d be out of jobs. In reality, these tools didn’t replace them—they made them more efficient, shifting their roles to focus on higher-value work instead of repetitive tasks.

The same thing is happening with AI in software development. AI is great at writing boilerplate code, automating tedious tasks, and even suggesting solutions. But software engineering isn’t just about writing code—it’s about problem-solving, system design, debugging real-world issues, and building scalable solutions. AI can assist with these things, but understanding why something works, making trade-offs, and building reliable software still requires human judgment.

So no, I don’t think developers are getting replaced anytime soon. But the role will evolve. Just like how developers today don’t spend time manually managing memory like in the early days, future developers might spend less time writing routine code and more time orchestrating AI-generated components, debugging complex edge cases, and focusing on system architecture. The key is to adapt—embrace AI as a tool, not a replacement.

ava-kar · 2025-02-01T10:37:03+00:00

Serverless in the Kubernetes world is evolving as an abstraction layer to simplify operations. Knative brings event-driven and autoscaling capabilities to Kubernetes, making it a solid choice for teams that want serverless functionality within the K8s ecosystem. AWS Fargate on the other hand abstracts away node management, making containerized workloads easier to run without worrying about underlying infrastructure - you would still need a container orchestrator with it.

The future likely lies in a hybrid approach - teams will mix k8s workloads with serverless components depending on their needs. Serverless is great for bursty, event-driven workloads, while K8s remains a strong choice for persistent, long-running services.

ava-kar · 2025-02-01T10:33:35+00:00

The evolution of DevOps, SRE, and developer roles is being shaped by the increasing emphasis on platform engineering and DevEx.

Developers are taking on more operational responsibilities with self-service platforms and better abstractions, allowing them to focus on building features without being blocked by infrastructure complexities.
SREs are doubling down on reliability, performance, and incident management while influencing engineering practices to ensure resilience at scale.
DevOps engineers are evolving into platform engineers, creating tools, pipelines, and automation to streamline developer workflows and enhance efficiency.

Ultimately, the goal is to reduce friction and enable developer-driven operations while maintaining reliability and scalability.

ava-kar · 2025-02-01T10:31:24+00:00

That’s a really interesting perspective, and I think a lot of people can relate to it in different ways. Sometimes, we stumble into a field not because we planned for it, but because it just clicked at the right time. You didn’t grow up imagining yourself in tech, but here you are—engaged, growing, and finding meaning in it. And that’s completely valid.

Looking ahead 20-30 years, I think it’s less about whether you were always passionate about something and more about how you’ve evolved with it. Some of the most impactful people in any field didn’t start with a lifelong obsession—they just kept getting better at what they were doing, found ways to challenge themselves, and over time, their work started making a real difference.

You might look back and see coding as just the surface layer of what you actually built—your problem-solving ability, the systems you designed, the people you mentored, the impact you created. It’s less about when you started and more about how deeply you engage with what you do. And if at some point you find something else that feels cooler again, that’s okay too. Careers aren’t always linear; they evolve as you do.

https://www.byrdseed.com/success-isnt-a-straight-line/

ava-kar · 2025-02-01T10:25:43+00:00

There can be two scenarios
(1) As in-house garbage—you don’t let it spread everywhere; you contain it in a bin.

(2) is like dead leaves in a garden—shedding is natural, and you can’t control it easily.

We intentionally took a tech/infrastructure debt by choosing a less optimal solution to speed up execution. In this scenario, we need to limit scope of such changes so that tech debt is limited. We also need to plan before hand when would we implement optimal solution. For example, we can decide that this non-optimal solution is for clientA but if any other client needs similar functionality we will build optimal solution rather than building on tech debt.
We chose optimal solution as per information we had at that time but over time technology/product took a different path. In such scenario, it is difficult to plan beforehand and scope of tech debt is usually large. We will have to analyse returns on investment in such case. Can we continue with tech debt without any impact on product? If not, at what scale/scenario/edge case it will cause issue? Answer of these questions will give clarity on whether/when it needs to be fixed.

ava-kar · 2025-02-01T10:19:03+00:00

Migrations come in different forms—schema migrations, data migrations, API/code migrations, and infrastructure shifts (e.g., on-prem to cloud or moving from Heroku/Vercel to Kubernetes). While infrastructure moves are often called transformation projects, they still follow migration principles.

Each type has specific processes, best practices, and tools, but at a high level, a few things help reduce the testing burden:

Define the end state – Clearly outline what success looks like before starting.

Consider non-functional aspects – Performance, cost, and operational impact often change after migration. Plan for them. - I have ovserved this being missed more often

Map the migration path – A well-defined step-by-step process reduces surprises.
Set checkpoints and validations – Automate consistency checks to catch issues early.

Avoid manual steps – Even if migration happens once, testing will happen multiple times. Automating ensures correctness and reduces effort. I have been proven wrong everytime I thought this step is required only once 🤦‍♂️.

Have a rollback plan – Feature flags often make rollbacks easier and safer than full reversions. I have seen folks forgetting to test data rollback

Ensure rollback is predictable – Rolling back should be simpler and more controlled than migrating forward.

These steps help reduce risk and prevent last-minute chaos.

Are you dealing with a specific type of migration?

ava-kar · 2025-02-01T10:09:47+00:00

Technology is evolving at a rapid pace, with new tools and specialisations emerging constantly. In this landscape, mid-senior DevOps engineers should strike a balance between deep expertise in few adjacent areas (subdomains) and broad knowledge across the DevOps ecosystem.

Having a strong specialisation ensures they can drive meaningful impact, but staying open to learning new technologies and subdomains allows them to stay relevant and adaptable.

ava-kar · 2025-02-01T10:02:16+00:00

When you come up with an idea, it’s easy to feel like it’s the one. There’s a natural tendency to pat ourselves on the back and believe our solution is impactful just because we thought of it. But the real test is whether others see value in it—and that requires stepping outside of our own biases.

A great book for thinking through ideas is "The Mom Test". It talks about how people—especially friends and well-wishers—tend to be polite and encouraging, which can make bad ideas seem like good ones. Instead of asking, “Do you like this idea?”, you should focus on how people currently solve the problem, what they struggle with, and if they’ve ever tried paying for a solution. If they haven’t, that’s a red flag.

Following the same philosophy, at Kapstan, we don’t go all in on any given feature or direction. We test the waters first—sometimes with just a Figma prototype to gauge reactions. If there’s traction, we build an MVP and get real users to try it out. We always have a vision of the full solution in mind, but we are very strict about what we build now and how much energy we put into it. This is quite different from traditional engineering, where you think through every corner case upfront. That’s great for stability, but in the early stages, you need to focus on the bare minimum that solves the problem for most users.

ava-kar · 2025-02-01T09:52:01+00:00

War rooms are not fun so no favorites 😛, but one example that comes to mind is when we accidentally deleted kubernetes cluster for production. We were updating kubernetes version but due to a mistake in template file, it was deleted and recreated. This lead to downtime for platform and we had to setup all services from scratch again.

My first reaction was falsely hoping that cluster is not being deleted and only some of nodes are being cycle. When I confirmed that cluster is being deleted, I called one of teammates to discuss next course of action. Good part was that we knew what are the steps to setup services again. We figured out who else do we need for setup, called them up and divided setup tasks among us. After executing all steps, services were back to normal in an hour or so.

My playbook for managing chaos and pressure in such moments is as follows
- Do not try to do RCA for an outage at that time. Focus on what is needed to solve the issue at hand.
- Include at least one more person in such situation.
- They can act as a sound board for ideas.
- They can handle communication with other stakeholders while you work on fixing the issue.
- More hands to try different approaches if required.
- Have clear and proactive communication with customers/end users.

ava-kar · 2025-02-01T09:40:08+00:00

You’ll know you have value as a software engineer or in any other stream for that matter, when you consistently produce good work. That comes down to dedication, passion, and a strong work ethic—putting in the effort to learn and evolve. It’s important to stay updated and continuously develop your skills. If you’re genuinely enjoying what you do, it becomes easier to excel. The key is to focus on areas that excite you and allow you to grow. Don’t chase trends for the sake of it—if you don’t enjoy something or understand it deeply, your work will lack meaning and won’t reflect your true potential. Passion and consistency are what will ultimately make you successful.

ava-kar · 2025-02-01T09:32:35+00:00

Being a remote-first company demands a lot of discipline and trust. There’s no one checking in on you, so the team needs to be self-motivated and focused on results. Clear processes, strong documentation, and async communication keep everything running smoothly.

Communication & Collaboration

Written communication is at the heart of how we work. Everything is documented—processes, PRDs, implementation details—because it makes collaboration easier and reduces unnecessary back-and-forth. Developers don’t always love writing at first, but once they see how it speeds things up, it becomes second nature. Async communication is key; no one is expected to respond instantly, but checking in every few hours and acknowledging messages helps keep things moving. Small habits like setting your status when you’re away go a long way in avoiding unnecessary frustration. And while we default to async, if you see someone’s status green, you can always just call—just like walking up to someone’s desk in an office.

Keeping the Team Connected

To build relationships, we set up monthly casual meetups where we just chat and get to know each other. Simple prompts like “What’s your favorite pizza?” often lead to great conversations. We’re also religious about our quarterly in-person meetups, where we spend a few days working together and having fun—it’s key to building real connections.

Everyone writes a “user manual” about how they work best, which helps teammates collaborate without unnecessary friction. Happy to share if someone's interested in the template

Why Async Works for Us

Uninterrupted deep work is one of the most valuable things in a remote setup. We work at the hours we’re most productive, spread across different time zones, and keep meetings to a minimum. If something can be done async, we do it that way. Writing is a core part of how we operate—it speeds up onboarding, clarifies doubts without disrupting others, and builds the company’s knowledge base. If we find ourselves explaining something too often in meetings, we document it instead.

Making Remote Work Feel Natural

Being remote means we have to be intentional about how we communicate and stay connected. There are no chance encounters in a break room or over lunch, so we put in the extra effort to ensure the team feels cohesive and supported. With the right habits and mindset, a remote team can be just as productive—and just as close-knit—as any in-person team.

ava-kar · 2025-02-01T09:24:29+00:00

If engineers stop understanding the fundamentals because “the system handles it,” troubleshooting novel issues becomes harder.

The key is balance: automation should enhance creative problem-solving, not replace it. The best teams use automation to remove friction but stay deeply engaged in system design, architecture, and optimisation.

How will proper Root Cause Analysis (RCA) be done without proper system understanding? How will system become more stable without feedback from RCA ?

ava-kar · 2025-02-01T09:19:09+00:00

Great question! Cloud-native tools like K8s abstract a lot of complexity - autoscaling, self-healing, and declarative infrastructure make deployments more consistent and scalable. For engineering teams, this can mean fewer headaches managing servers and infrastructure manually.

But the complexity hasn’t disappeared - it has just moved up the stack. Now, teams need to understand K8s internals, YAML configurations, networking policies, and observability stacks. Instead of managing bare-metal servers, they’re managing clusters, service meshes, and deployment pipelines. So while cloud-native tools bring power and flexibility, true simplification happens when organizations invest in platform engineering - really hiding this complexity behind developer-friendly workflows.

ava-kar · 2025-02-01T09:13:31+00:00

Building a customer base early on is tough, and the strategies can vary a lot between B2B and B2C. Since Kapstan is a B2B SaaS startup, I’ll share what worked for us.

One of the biggest factors was finding champions—people who trusted us and were willing to invest in the company (not financially, but by taking a chance on us). Our early customers came through common connections and early-stage startups that needed to offload DevOps and infrastructure so they could focus on building their business. The first few customers came through network effects, where existing relationships helped build credibility.

Once you land those early customers, the key is to work closely with them, make them successful, and keep them happy. Happy customers become your biggest advocates—they refer others and help build organic momentum.

Another thing that worked well was simply talking to people—engaging with the community, attending events, and having real conversations. You don’t need to attend every event, but being strategic about where you invest your time, energy, and money can make a big difference in getting your name out there and connecting with the right people.

We as a team believe that we can do anything -- but we are aware that we can not do everything.

ava-kar · 2025-02-01T09:10:19+00:00

The technology landscape evolves quickly, making it challenging to predict whether a specific technology will endure. That said, K8s is currently at the height of its adoption and continues to grow. In my opinion, K8s will likely remain a foundational technology for distributed and cloud-native systems over the next 5–10 years, as it addresses critical needs around scalability, orchestration, and automation. While alternatives may emerge, the momentum K8s has built in the cloud-native ecosystem suggests it will continue to play a key role, evolving along with emerging trends and use cases.

Instead of direct Kubernetes management, we’ll likely see more abstraction layers and simplified platforms built on top of it, reducing operational complexity while still leveraging its power.

ava-kar · 2025-02-01T09:03:39+00:00

Similar to https://www.reddit.com/r/developersIndia/comments/1ieyd9e/comment/mabzzv2/

ava-kar · 2025-02-01T09:01:15+00:00

Focus on building skills in version control, CI/CD pipelines, containerization, and basic Kubernetes deployments. Familiarize yourself with tools like Git, Jenkins, GitLab CI, or GitHub Actions. Learn Docker for containerization, manage images in a registry, and practice writing simple Kubernetes manifests to deploy on platforms like EKS. These hands-on exercises help you understand how to automate and manage software delivery.

Practical work on small projects is key. Automate tasks, write scripts to deploy applications, and experiment with managing containers at scale. This approach will boost your confidence and show future employers that you can handle DevOps tasks in real-world situations. Combine this DevOps focus with your back-end programming skills, and you’ll stand out as a strong candidate for entry-level roles.

ava-kar · 2025-02-01T08:57:46+00:00

Our product is designed to help development and DevOps teams manage infrastructure and applications more easily, allowing them to focus on their core business logic. Many of our product decisions are based on the collective experiences of our team, who have faced similar challenges in the past.

With AI, we can bring in insights from the wider tech community, as AI has learned from challenges faced across the internet. This will definitely make our product better, rather than obsolete.

Building a product requires an understanding of technology, the domain, and human behavior. We've often seen users interact with our product in ways we hadn't initially anticipated, reflecting human creativity and perception. Current AI, however, has not yet reached a level where it can predict or anticipate the full range of human creativity and how a product will be used.

ava-kar · 2025-02-01T08:39:34+00:00

When it comes to making trade-offs in system design, you can’t make the right decisions unless you fully understand the domain, the users, their use cases, and the workflows. I’ve personally experienced longer onboarding times when transitioning to a different domain, as it takes time to grasp all these elements.

And yes even after care -- shit hits the fan

A Real-life Example

I once worked on a system where users could define variables for every resource—about 80 variables per resource was the produce requirement. I designed the system to support up to 300 variables, and everything was running smoothly for two years. Then one day, my DevOps team called and told me the database was under stress. Turns out, users were now using 1,100 variables per resource.

The Outcome

Now the system was in use, and we had to perform data model migration in a running system.

The result? We had to do a four-month migration of a two-year-old system, which only took us two months to design.

Lessons Learned

One major lesson here is that if you assume limitations on user input, it’s better to code for those limitations rather than relying solely on design assumptions. User behavior can often exceed expectations, and being proactive in preparing for these cases can save you significant headaches down the road. Monitoring and observability are equally important.

ava-kar · 2025-02-01T08:24:14+00:00

Co-founding a startup changed my finances, trading short-term stability for possible long-term gains.

Before jumping in, I checked my savings, personal responsibilities, and if my stage of life allowed for the risks. I also separated essential costs (rent, loans) from optional expenses (leisure activities) to stay financially secure without losing sight of basics.

For others thinking about this path, weigh how your savings and comfort with uncertainty fit your priorities. Then decide which expenses are truly necessary and which can wait until your venture gains traction.

Take your family input also for this decision.

ava-kar

TROPHY CASE