Chaitanya Jawale wanted better software. He started with how people build it.

Chaitanya Jawale once wrote about going to DVD parlors to rent films that had already been out for two or three years. By 2020, he could summon a movie on a device and stop it whenever he pleased. Plenty of people would have celebrated the convenience and pressed play. Jawale turned his attention to the machinery behind the screen: the servers, the changing demand, the delay that makes an evening’s entertainment stare back at you in a little spinning circle.

He called himself a “developer at heart.” It is a useful introduction to a founder whose subject was often the work that customers never see. In his account of streaming, personal recollection led directly to questions about scaling, network conditions, and service interruptions. The viewer wanted a film. CJ wanted to understand how the film arrived, and what might prevent it from arriving at all.

Before the CEO’s desk, there was “Sir Java”

Born in Jalgaon, Maharashtra, on June 12, 1985, Jawale studied computer science at North Maharashtra University. His growing command of Java earned him the nickname “Sir Java” among fellow professionals. The title was unofficial, as the more memorable titles generally are. He would later be known simply as CJ.

His professional profile records engineering work at Altizon Systems and Clogeny, followed by a technical project management role at Seagate in 2015. At Clogeny, his responsibilities stretched across engineering delivery, deployment architecture, customer proposals, and technical exploration. At Seagate, they included a logging and monitoring team for a cloud storage project, coordinating development and integration. These were jobs concerned with getting several moving parts to behave together.

In 2015, he founded Opcito with a small circle of friends and led it as CEO until November 15, 2022, when he died. His ambition was to change how businesses developed and released software. That placed the company in a particular kind of work: improving the process by which an idea becomes something a customer can actually use.

An orchestra needs more than instruments

In April 2017, Jawale opened an essay on Kubernetes with an orchestral comparison. Containers, the packages used to run software, needed coordination. Kubernetes supplied it. His interest soon moved beyond the pleasure of the analogy to the less forgiving questions of operating a system at scale.

He described Opcito’s work setting up clusters with logging, monitoring, and recovery provisions. He also pointed to a gap between getting Kubernetes started and running it across larger deployments. A successful demonstration was only the beginning of the obligation. The same article appeared in the Cloud Native Computing Foundation’s KubeWeekly selection, placing his explanation in the wider conversation around the technology.

Later that year, his Docker essay considered containers alongside virtual machines. The vocabulary was technical; the underlying decision was familiar to anyone who has had to choose equipment for a job. What does the application need? What should its environment provide? The point of choosing a technology was to make deployment work, rather than to acquire an impressive new noun for a presentation.

Security gets a seat at the table

His July 2017 writing on DevSecOps put security into the development conversation early. He argued for involving the people responsible for it throughout the software lifecycle, with checks built into delivery. His recommendations included examining container images, auditing environments, and incorporating automated security testing.

There was an organizational argument inside the technical one. A security report handed over late leaves other teams to absorb the consequences. Bringing the disciplines together changes when a problem can be noticed and who can act on it. His DevSecOps diagram was later included in Sonatype’s collection of reference architectures, credited to Jawale and Opcito.

In March 2018, he returned to the subject through workplace practices. Training, feedback, policy revisions, and frequent checks mattered alongside tools. He wanted teams to look for underlying causes rather than repeatedly patching visible symptoms. Read beside the earlier essay, it shows a founder returning to an idea and asking what an organization would have to do differently to make it stick.

The unglamorous art of keeping a promise

Software sold as a service carries a continuing promise. The purchase is followed by another day on which the application must work. In his March 2018 SaaS essay, Jawale followed that promise into provisioning, access, monitoring, configuration, and routine operations. Signing up a customer was a small part of the responsibility.

He discussed how Opcito had integrated delivery tools, monitoring, and security checks for SaaS customers. The essay’s attention was on the dependencies beneath the interface: the logs that need collecting, the thresholds that need setting, and the processes that connect service operations to business goals. Here was the CEO writing about the work required after the sales conversation had ended.

His DevOps assessment article offered another practical starting point: examine the organization before prescribing its improvements. An assessment could identify capability gaps, guide hiring, and help management decide where investment belonged. This was an argument for finding out how a team actually worked. Purchasing a tool is admirably quick. Understanding the organization that will use it takes rather longer.

His June 2018 discussion of Microsoft Azure widened the field again. He considered Microsoft’s changing relationship with open source and the integrations available to development teams. The essay weighed ecosystem familiarity and tooling options. His attention moved across vendors, but kept returning to the same question of how people could build, deploy, and manage their applications.

Write it down so it can be built again

By February 2019, Jawale was writing about Infrastructure as Code: describing infrastructure in forms that could be managed programmatically. He distinguished the idea from merely repeating a set of manual steps. The attraction was a more deliberate way to manage the environment on which an application depended.

A follow-up in April considered practices and tools. He discussed Terraform, provider choice, and the complications introduced by moving parts in an infrastructure system. The recurring concern was repeatability. If an environment works, a team needs a dependable way to reproduce it. If it changes, somebody needs to understand what changed. Memory makes a charming companion and a rather unreliable configuration system.

In October 2020, he examined the security problems that could accompany this approach. Access controls, configuration drift, untracked resources, and exposed credentials all received attention. Automation did not dissolve responsibility. It gave teams another place to exercise it, and another set of details they had to inspect.

His May 2021 essay on Configuration as Code was similarly measured. He described benefits for consistency, review, and recovery, while acknowledging maintenance burdens and difficulties across complex environments. He recommended controlled adoption and iteration. That willingness to discuss drawbacks is part of what makes the writing useful as a portrait: enthusiasm came with implementation questions attached.

Build it. Release it. Keep it working.

Three responsibilities that recur throughout CJ’s writing.

A day reserved for getting better

On November 16, 2019, Opcito hosted a Global Day of Coderetreat at its Pune development center, with Nelkinda helping organize it. The program concentrated on the fundamentals of software development and design. Participants worked with clean code, Conway’s Game of Life, SOLID principles, and different approaches to programming.

Jawale’s comments about the event emphasized reassessing working methods and improving coding technique. Co-founder Abhijit Kharat opened the bootcamp. A company that sold engineering services had made room to practice engineering. There is something pleasingly sensible about that: musicians rehearse, athletes train, and software developers can also benefit from time spent improving the craft itself.

The event puts a date and an activity beside the larger ambition. Better software required better ways of working, and people needed opportunities to develop them. It was a modest, concrete expression of an idea that also ran through his technical essays.

Reliability, and the people behind it

In May 2022, Jawale wrote about AIOps and site reliability engineering. He considered how machine learning could help teams process operational information, detect trouble, and respond more efficiently. He presented these capabilities as assistance for reliability engineers, whose work would continue.

The balance between change and dependable service remained central. New capabilities meant little to the user if the application failed at the moment it was needed. Across these essays, a portrait emerges through his choice of problems: coordination, repeatability, early checks, recovery, and the everyday discipline of keeping software available.

In August 2025, Opcito’s tenth foundation day began with a tribute to its late founder. The celebration also recognized employees, included customer and former employee videos, and continued with food, music, and dancing. The business he helped begin had reached a milestone with people still doing the work together.

CJ’s writing leaves a particularly practical way to remember him. Look beyond the interface. Ask how the system will be operated. Give the team time to learn. Consider the failure before the customer encounters it. The film should play when someone presses the button. Behind that ordinary expectation sits a profession, and it was a profession he took seriously.