What a First Army Order Can Teach a Defence Company
Apollyon’s first Army order began a responsibility to deliver and support equipment. What matters is how that experience strengthens the organisation.
Apollyon Dynamics · 18 October 2026 · 5 min read

Our first Indian Army order was worth ₹2.68 lakh. It came from 15 Guards, early in the life of a company that had begun in a student workshop at BITS Pilani Hyderabad.
Apollyon was incorporated in May 2025. Within two months of incorporation, we had delivered our first production hardware to a forward unit. The order established a relationship whose responsibilities extended beyond the demonstration: equipment had to be delivered, supported and understood by the people who would use it.
That transition remains central to the company we are building. Early programmes create an opportunity to learn how engineering decisions hold up outside the workshop. The lasting value comes from retaining that knowledge and making it available to the next programme.
The workshop is a beginning
Jayant Khatri and Sourya Choudhury began with 3D printers, test equipment and airframes assembled in their hostel rooms. The small team could move quickly between a design decision and a physical build. The people making the decisions were close to the work and could see the consequences directly.
The founders then took the hardware to military demonstrations. Our company history records the early trials in Chandigarh and the procurement that followed.
A delivery changes the relationship between a team and its product. In a workshop, the people operating a machine may also be the people who designed and assembled it. They carry context that a new user cannot be expected to have. Equipment intended for others has to carry more of that context through its documentation, interfaces and support.
The young company has to learn how to transfer that understanding reliably.
Support infrastructure belongs in the story
In late 2025, Apollyon delivered a containerised Mobile Drone Lab to the Army with 15 Guards in Jammu. It brought diagnostic, calibration and mission-planning equipment to a forward base.
The lab is a useful part of our early history because it makes the support side of engineering visible. A deployed system depends on the means to inspect it, maintain it and understand its condition. Those activities need equipment, procedures and people with the right knowledge.
Delivering that infrastructure also broadens what a company has to think about. The aircraft is part of a larger working environment. Transport, maintenance, preparation and communication with users all affect the experience of operating it.
We do not need to assign an unmeasured improvement in availability to the lab to explain its significance. Its purpose shows the scope of responsibility that accompanies equipment: the machine and the means to support it belong in the same engineering conversation.
Experience has to become evidence
Direct contact with users gives a team access to observations it may never encounter in its own workshop. A question about preparation or maintenance can expose an assumption that had become invisible to the designers.
To be useful beyond that conversation, the observation needs context. Which configuration was involved? What conditions were present? What was recorded? What can the team establish, and what still needs investigation?
Our engineering method connects instrumented testing, simulation and verification. Test records help the team compare expected behaviour with observations. Proposed revisions can then be evaluated in a controlled environment before further flight.
The organisational benefit lies in making the reasoning traceable. A later engineer should be able to understand why a decision was taken and what evidence supported it. That allows the company to retain knowledge as its people and programmes grow.
Repetition requires discipline
A young company often depends heavily on a few people who know the history of every build. Their judgement is valuable, but growth requires a way to share it.
Versioned configurations, review records and clear release procedures help turn that judgement into an organisational practice. They establish which version is approved and preserve the basis for introducing a change. Our flight-software governance describes those controls for the packages we author.
This documentation has a practical audience. The next engineer investigating a result needs it. So does the person preparing equipment for use, or supporting a configuration they did not personally develop.
Maintaining that discipline is part of keeping development responsive. Time spent establishing what is actually on a machine is time unavailable for understanding its behaviour. A dependable record gives the team a clearer starting point.
What can carry into another programme
Different vehicles create different engineering responsibilities. A rotorcraft, a fixed-wing aircraft and a surface vessel cannot be treated as interchangeable machines.
Within the Nightshade family, configurations share a common core. Ahuti uses a separate rotorcraft architecture. Piranha has its own marine implementation, while Hemlock is a distinct concept programme. Our architecture documentation makes those boundaries explicit.
The experience that carries across them includes how to organise testing, maintain configuration records and preserve evidence. Engineers also carry judgement developed through earlier work, while facilities and supplier relationships provide a foundation for subsequent programmes.
A new programme still has to establish its own results. Previous experience gives the organisation better tools for doing that work. It does not remove the need to do it.
A result should keep its meaning
In September 2026, the Ahuti sprint testbed reached 498 km/h. We identify it as a sprint-testbed result in our programme record.
The distinction matters because different tests answer different questions. A speed run establishes a result under the conditions of that run. Endurance, reliability and operational acceptance require their own evidence.
Keeping those categories clear helps the engineering team as well as the reader. A programme needs to know which requirements it has demonstrated and which remain open. A milestone becomes more useful when its scope is understood.
This applies equally to commercial progress. A demonstration, an evaluation and a delivery each represent a different step in the relationship with a customer. Recording them accurately makes the path to a mature product easier to follow.
What the first order leaves behind
The first order is a memorable date in a company’s history. Its deeper significance depends on what follows it.
A delivery can leave behind better support knowledge, clearer records and a more experienced team. Repeated programmes can deepen those assets until the company is capable of work it could not have attempted at the beginning.
That is the institutional ambition behind Apollyon. The workshop, the first Army order and the Mobile Drone Lab are early parts of the same progression. Each creates responsibilities that help define the next stage of the organisation.
Our first order gave us equipment to deliver and people to support. The continuing task is to make the knowledge earned through that responsibility durable enough to serve every programme that follows.