2006 – 2013: The Foundation

The journey of an enterprise rarely begins with an established playbook, institutional backing or ready-made infrastructure.

In 2006, after completing my Bachelor of Computer Applications (BCA) at the Institute of Management and Rural Development Administration (IMRDA), Sangli, under Bharati Vidyapeeth (Deemed to be University), Pune (recounted in Chapter 01: Before 2006: The Beginning), I took my first formal step into entrepreneurship and established Cavalry Archer Software in Satara.

I was coming from years of learning, teaching and experimenting with technology. Now I had to turn that knowledge into something that people and organisations could actually use.

There was no large team, no outside capital and no established commercial network.

What I had was technical knowledge, curiosity, the willingness to work and the responsibility to figure things out.

I was entering business with technical capability, but very little understanding of what it actually meant to build and operate a business.

Why Cavalry Archer?

The name Cavalry Archer came from the real-time strategy game Age of Empires.

I was drawn to the characteristics of the cavalry archer. It could move quickly, operate from a distance and adapt to changing situations.

Those qualities resonated with how I wanted to approach my work at the time: mobility, reach, adaptability, and precision.

The name became the identity of my first software venture.

Building Software in 2006

Software development in 2006 was very different from the environment developers work in today.

Development resources were more limited, internet connectivity was slower and technical information was spread across books, documentation, forums and individual experimentation. Cloud platforms were only beginning to emerge and were not part of the practical development environment for the projects I was working on.

My technical work involved technologies such as C++, Visual Basic 6, ASP.NET, PHP, JavaScript, HTML, SQL Server, MySQL and XML.

For web development, I worked with the LAMP stack, including Linux, Apache, MySQL and PHP.

Development and production environments often required careful attention. Code developed on Windows machines could behave differently when deployed on Linux servers. File names were case-sensitive, permissions had to be configured correctly and files often had to be transferred manually using FTP.

At the time, these were simply part of the job.

The Physical Workspace at Satara Headquarters (2006)

Operating an independent software development firm from Satara required establishing a dedicated professional environment. Every desk, partition and cable was set up with precision to handle complex engineering workflows.

Building for Real Businesses

One of the early institutional projects was a web portal for Appasaheb Birnale College of Pharmacy, Sangli.

The work involved more than creating web pages. It required database integration, structured information, user sessions and application-level functionality.

We also developed software for a pharmaceutical company.

The technical work was completed, but I did not know something that seems obvious to me today. I did not understand that software could be treated as a product that could be packaged, licensed and resold to other organisations.

I knew how to build the software. I did not yet understand how to build the business around the software.

That difference became an important lesson:

“Technical capability and commercial capability are not the same thing.”

Building an Online Examination System

Another important part of this period was the development of an online examination system.

The system involved question randomization, session handling, examination state management and automated evaluation.

Building such a system required thinking beyond individual pages or pieces of code. The complete flow had to work reliably from the user’s first interaction through to the final result.

At the time, I was learning these concepts by building them in real projects. There was no separation between learning and execution.

The project itself became the classroom.

From Technician to Self-Employed Professional

Starting Cavalry Archer Software changed the nature of my work.

Until then, much of my identity was connected to technology itself: learning it, teaching it, and solving technical problems.

Now, every technical decision had a business consequence.

I had to find work, understand what a client needed, estimate the effort involved, deliver the project and take responsibility when something did not go as planned.

I was still a technician at heart, but I was gradually becoming a self-employed professional. And that transition happened through real work rather than formal business education.

Learning to Communicate Internationally

International work brought another challenge. My English communication was not strong at that stage.

I could understand the technical work and I could communicate what I wanted to say, but writing professional messages to international clients was difficult for me.

My college friends supported me during that period. I would write the message I wanted to communicate and send it to them. They would help me convert it into clearer English, and I would then use that communication with clients.

It may seem like a small thing today. For me, it was an important part of learning how to work internationally.

I did not allow a weakness in communication to stop me from taking opportunities. I found a way to work around it while gradually improving myself.

Working Across Countries

Through freelancing and software projects, I began working with people and organisations outside India.

I worked remotely with Media Lab Pro, Inc., a US-based company, where I worked as a Development Manager. The company’s owner, Matthew Hammond, supported me during that period.

I also worked remotely with Peace of Code. I had the opportunity to work with Viliiam Duris from Slovakia and with Jeremy from Australia. Nestor Mata was also among the people who supported me during this period.

These relationships gave me exposure to different countries, working styles, expectations and ways of doing business.

For someone working from Satara, this was a significant shift. The work was no longer limited by geography.

Working Across Time Zones

International work also changed the rhythm of my days.

During this period, I worked across the time zones of more than twelve countries. There were phases when I would return home at dawn, have dinner in the early morning, sleep around 5 or 6 a.m. and return to office work again by around 10:30 a.m.

There were also periods when I worked continuously for 72 to 78 hours.

Those years taught me a great deal about execution, delivery pressure, discipline and international expectations. They also taught me something that became important later:

“Working harder can help you deliver more, but it does not automatically create a better business.”

Learning to Handle Clients and Teams

As the work grew, I was no longer only responsible for writing software.

I was handling clients, understanding requirements, coordinating projects and working with a team.

Team management brought a completely different set of challenges. People worked differently. Communication was not always perfect. Things did not always happen according to plan.

I had to learn how to explain work, assign responsibilities, follow up, solve problems and take responsibility when something went wrong.

There were decisions I handled well. There were also decisions I would handle differently today. That was part of the education.

The Reality of Development

There were long hours of debugging.

Sometimes a problem was hidden somewhere inside a large file, and the only way forward was to go through the code line by line.

Working with PHP, databases, servers and different environments required patience and attention to detail. Internet connectivity was also a practical limitation, so uploading files, accessing servers and managing deployments could take considerable time.

When something went wrong, I had to understand what was happening, trace the issue and work out the solution myself.

That experience built a habit that stayed with me:

“Understand the problem first, then build the solution.”

Learning Business Through Mistakes

The technical side of the work was only one part of the journey. I was also learning business for the first time. And I made mistakes.

Quite possibly, I made almost every kind of mistake that someone can make while learning the basics of business. Some decisions were technical. Some were related to clients. Some involved people and teams. Others came from not yet understanding the market or the commercial side of what I was building.

The pharmaceutical software was one example. We had built something useful, but I did not understand how to turn that software into a repeatable product or commercial opportunity.

At the time, I saw the problem mainly as a software problem. I was gradually learning to see it as a business problem as well. That distinction stayed with me.

Building Business Discipline

Cavalry Archer Software gradually taught me that software development and business operations could not be treated as separate worlds.

I had to prepare proposals, understand requirements, define scope, discuss timelines and communicate with clients. I also had to learn about domains, DNS, nameservers, hosting, FTP and server management.

There were also the less visible responsibilities of running a formal business, such as documentation, registrations, banking, letterheads, stamps and day-to-day administration.

None of these things were particularly glamorous. But they were part of learning what it meant to run a business.

Closing One Chapter

Cavalry Archer Software continued from 2006 to 2013.

Those seven years changed the way I looked at work. I started this period primarily as a technician who knew how to build software. Over time, I became a self-employed professional responsible for clients, projects, delivery and a team. I also began to understand the broader realities of business, including relationships, communication, money, operations and the consequences of decisions.

The journey was not perfect. There were long working hours, difficult projects, wrong decisions and plenty of mistakes. But there was also learning, international exposure, technical growth and the gradual development of business judgment.

In 2013, I made the decision to close Cavalry Archer Software. Closing the business did not erase what those seven years had created. The technology would change. The business identities would change. The direction would evolve. But the experience remained.