What I Learned Building Software for Indian Defence at Bharat Electronics Limited

Working at Bharat Electronics Limited

In the summer of 2024, I interned at Bharat Electronics Limited (BEL) — one of India's premier defence electronics companies and a Navratna PSU under the Ministry of Defence. Founded in 1954, BEL designs, manufactures, and supplies electronic equipment and systems for the Indian Armed Forces, paramilitary organizations, and government agencies.

My role was focused on frontend development — building production interfaces using React and Ant Design (AntD) for crucial Indian Airforce projects. This wasn't a side project or a proof of concept — it was production software used daily by Airforce personnel.

This experience was unlike anything I'd encountered at startups or in personal projects. The stakes were higher, the processes were stricter, and every line of code carried the weight of institutional responsibility.

The EFIS Project

EFIS is a comprehensive financial management system that replaced decades-old manual processes. Before EFIS, financial records were maintained in physical ledgers. Reconciliation took weeks. Audits required physical access to paper records stored across multiple locations.

The interfaces I built handled:

• ›Data visualization dashboards — Complex charts, tables, and drill-down views using Ant Design components, providing command oversight from division-level to individual record
• ›Role-based access views — Different UI layouts and permissions for different officer ranks, built with AntD's permission and layout components
• ›Reporting interfaces — Interactive reporting UIs that replaced manual paper-based workflows with responsive, filterable, exportable web views
• ›Form-heavy workflows — Multi-step forms with validation, approval chains, and status tracking — all built with AntD's form system

The impact was tangible and measurable: we reduced paperwork by 75% by digitizing manual workflows into web interfaces. These numbers came from BEL's internal assessment, not my own estimates.

Security Is Non-Negotiable

At Bharat Electronics Limited, security isn't a feature you add before launch — it's the foundation everything is built upon. Coming from the startup world where "move fast and break things" is the mantra, this was a fundamental mindset shift.

Air-Gapped Development

Development machines at BEL had no internet access. No npm install from the registry. No Stack Overflow. No GitHub Copilot. Every dependency had to be vetted, approved, and brought in on a secure transfer medium.

This constraint actually made me a better developer. When you can't reach for a library to solve every problem, you learn to write solutions yourself. You understand the code in your project deeply because you can't just Google an error message. The code I wrote at BEL was some of the most thoroughly understood code I've ever produced.

Code Review by Committee

Every code change went through a multi-stage review process. Junior engineers reviewed by senior engineers, then reviewed by the project lead, then reviewed by the security team. A feature that might take one PR in a startup required three rounds of review at BEL.

At first, this felt slow. But after my second review caught a SQL injection vulnerability that I would have missed, I understood. In defence systems, a single vulnerability could compromise classified financial data. The review process isn't bureaucracy — it's a safety net.

Input Validation and Role-Based UI

On the frontend, we enforced strict validation using Ant Design's form system. Every form field was validated client-side before submission, and UI components were conditionally rendered based on the user's role and permissions:

// Role-based UI rendering with Ant Design
import { Form, Input, Select, Button, message } from 'antd';

const ROLE_PERMISSIONS = {
  officer: ['view', 'create', 'approve'],
  clerk: ['view', 'create'],
  viewer: ['view'],
} as const;

function ReportForm({ userRole }: { userRole: keyof typeof ROLE_PERMISSIONS }) {
  const permissions = ROLE_PERMISSIONS[userRole];
  const canCreate = permissions.includes('create');
  const canApprove = permissions.includes('approve');

  const onFinish = (values: FormValues) => {
    // Client-side validation passed — Ant Design handles this
    if (!canCreate) {
      message.error('You do not have permission to submit reports');
      return;
    }
    submitReport(values);
  };

  return (
    <Form onFinish={onFinish} layout="vertical">
      <Form.Item name="title" rules={[{ required: true, min: 3, max: 200 }]}>
        <Input disabled={!canCreate} placeholder="Report title" />
      </Form.Item>
      <Form.Item name="department" rules={[{ required: true }]}>
        <Select disabled={!canCreate} options={departmentOptions} />
      </Form.Item>
      {canApprove && (
        <Form.Item name="approvalStatus">
          <Select options={[{ value: 'approved' }, { value: 'rejected' }]} />
        </Form.Item>
      )}
      <Button type="primary" htmlType="submit" disabled={!canCreate}>Submit</Button>
    </Form>
  );
}

Frontend Activity Tracking

Even on the frontend, we tracked user actions for audit purposes. Every significant UI interaction was logged and sent to the backend:

// Frontend audit trail — tracking user actions on defence UIs
import { useCallback } from 'react';

function useAuditTrail(userId: string) {
  const logAction = useCallback((action: string, details: Record<string, unknown>) => {
    // Send to audit endpoint — every click on sensitive data is tracked
    navigator.sendBeacon('/api/audit', JSON.stringify({
      userId,
      action,
      details,
      timestamp: new Date().toISOString(),
      page: window.location.pathname,
    }));
  }, [userId]);

  return { logAction };
}

// Usage in a dashboard component
function SensitiveReportView({ reportId }: { reportId: string }) {
  const { logAction } = useAuditTrail(currentUser.id);

  useEffect(() => {
    logAction('VIEW_REPORT', { reportId });
  }, [reportId]);

  const handleExport = () => {
    logAction('EXPORT_REPORT', { reportId, format: 'pdf' });
    exportReport(reportId);
  };

  return <Button onClick={handleExport}>Export PDF</Button>;
}

These practices now inform how I approach frontend security at Modelia.ai — where we handle Shopify merchant data — and how I built access controls in EduFly, where student data privacy is legally mandated.

Documentation as a First-Class Citizen

In defence software at BEL, documentation isn't optional or an afterthought. It's a deliverable, reviewed with the same rigor as code. Every component of EFIS had:

• ›Technical Design Documents (TDD) — Written before writing any code. Describes the architecture, data flow, security considerations, and failure modes. These were reviewed and approved before implementation began.
• ›API specifications — Every endpoint documented with request/response examples, authentication requirements, error codes, and rate limits
• ›Database schema documentation — Every table, every column, every relationship documented with rationale for design decisions
• ›Deployment runbooks — Step-by-step procedures for every environment, including rollback procedures
• ›Incident response procedures — What to do when specific failure modes occur, who to contact, what to check first

I now apply a lighter version of this discipline at Modelia.ai and Asynq.ai. We don't write 50-page TDDs for every feature, but we do write architecture decision records (ADRs) for significant choices, and every API endpoint has OpenAPI documentation.

Reliability Engineering

Defence systems must work. Always. There is no "we'll fix it in the next sprint." The reliability patterns I learned at Bharat Electronics Limited have shaped how I think about production systems:

Graceful Degradation

If the API is down, the UI should still be usable. The dashboards I built at BEL could display cached data and show clear status indicators when live data was unavailable:

// Frontend graceful degradation pattern
import { Alert, Spin, Result } from 'antd';
import { useQuery } from '@tanstack/react-query';

function DashboardSummary({ departmentId }: { departmentId: string }) {
  const { data, isLoading, isError, error, dataUpdatedAt } = useQuery({
    queryKey: ['summary', departmentId],
    queryFn: () => fetchSummary(departmentId),
    staleTime: 5 * 60 * 1000, // Consider data fresh for 5 minutes
    retry: 3,
    retryDelay: (attempt) => Math.min(1000 * 2 ** attempt, 30000),
  });

  if (isLoading) return <Spin size="large" />;

  if (isError && !data) {
    return <Result status="warning" title="Data temporarily unavailable" subTitle="Please try again later" />;
  }

  return (
    <div>
      {isError && data && (
        <Alert type="warning" message="Showing cached data — live connection unavailable" showIcon />
      )}
      {dataUpdatedAt && (
        <span className="text-xs text-gray-500">Last updated: {new Date(dataUpdatedAt).toLocaleString()}</span>
      )}
      <SummaryCards data={data} />
    </div>
  );
}

Health Checks and Automated Failover

Every service reports its status every 30 seconds. If three consecutive health checks fail, traffic is automatically routed to the backup instance. This pattern directly influenced how I design health checks at Modelia.ai for our Shopify extension.

Regular Disaster Recovery Drills

At BEL, disaster recovery wasn't theoretical. We regularly tested backup and restore procedures, simulated network partitions, and verified that failover worked as expected. After experiencing this discipline, I now ensure that every production system I build at Modelia.ai has tested backup/restore procedures.

What I Took Away

The discipline I learned at Bharat Electronics Limited (BEL) made me a fundamentally better engineer. Now at Modelia.ai, I apply these principles daily:

• ›Write tests first — Especially for critical business logic. If a financial calculation is wrong, it's not a bug — it's a compliance violation.
• ›Design for failure — Every external dependency will fail eventually. Plan for it.
• ›Document decisions — Future you (or the engineer who inherits your code) will thank present you.
• ›Security by default — Not as an afterthought. Validate all input, audit all actions, never trust the client.
• ›Review rigorously — A slow review that catches a bug is infinitely better than a fast merge that breaks production.

Working on software that directly impacts national defence gives you a perspective that no amount of startup experience can match. I'm grateful to Bharat Electronics Limited for that foundation.

About Bharat Electronics Limited

Bharat Electronics Limited (BEL) is India's leading defence electronics company, established in 1954 in Bangalore. As a Navratna Central Public Sector Enterprise under the Ministry of Defence, BEL designs, manufactures, and supplies state-of-the-art electronic equipment and systems for defence and civilian applications. BEL's products serve the Indian Armed Forces, paramilitary organizations, and other government agencies. With nine production units across India and a workforce of over 10,000 engineers, BEL is at the forefront of India's indigenous defence manufacturing capabilities.

Key Takeaways

• ›Security is a foundation, not a feature — Build it in from the start, not as a last-minute addition
• ›Air-gapped development makes you a better programmer — Constraints breed understanding
• ›Multi-stage code reviews catch real bugs — The overhead pays for itself in reliability
• ›Audit everything — If you can't prove who did what and when, your system isn't production-ready
• ›Documentation is a deliverable — Treat it with the same rigor as code
• ›Design for graceful degradation — Systems should degrade gracefully, not fail catastrophically
• ›Test disaster recovery regularly — An untested backup is not a backup
• ›Defence-grade discipline applies everywhere — The same patterns that protect national security also make commercial software more reliable