Case study · Aerospace and defence · In production use
The AeroOps wordmark

AeroOps Drone inventory and project management

A drone R and D team was tracking 3000+ parts on spreadsheets. Nobody could say what was in stock or who had it.

Built while leading the Deep Tech AI team at Abhyuday Bharat Group. I ran the discovery, wrote the spec, prioritised the cuts, and shipped it in four weeks with AI as the engineering team. This page is the decision log.

RolePM and builder, end to end
Users15+ R and D engineers
Discovery to deploy4 weeks
Open the live demo → Demo build, sample data.
Production runs on the company's own server.
The real problem was never inventory. It was workflow.
Scroll
3000+ parts tracked75 percent less time on inventory100 percent adoption in 2 weeksZero inventory errors since launch4 weeks discovery to deploy 3000+ parts tracked75 percent less time on inventory100 percent adoption in 2 weeksZero inventory errors since launch4 weeks discovery to deploy
01 · The problem

Not an inventory problem. A workflow one.

Fifteen engineers were building drones across ten plus concurrent projects, and the entire parts operation ran on manual spreadsheets. There was no real time stock visibility, no way to answer who has what or where it was used, and no audit trail when a part went missing. Parts got misallocated, projects slipped waiting on components that were sitting on someone else's bench.

"We waste 6 hours every week just figuring out what parts we have and who's using them. It's killing our productivity."Senior R and D engineer, discovery interview

The constraints were real: it had to run locally for security, and it had to be simple enough for engineers who had no interest in learning a tool. So the goal was never to digitise a spreadsheet. It was to make the team's actual workflow visible.

0lost every week, per engineer, just locating parts and chasing who had them
0reduction in time spent on inventory management after AeroOps went live
02 · How it was scoped

Four weeks, and most of it was not coding.

A generic off the shelf tool was available and would have been faster to buy. I ran the discovery instead, because the team's workflow was the requirement, and no vendor knows a drone R and D bench. Frameworks kept the process honest, not decorative.

Week 1 CIRCLES

Comprehend, then identify.

Interviews with engineers, project managers and inventory coordinators produced three personas with distinct jobs to be done, and one root cause behind every symptom: manual tracking.

Week 1 to 2 MoSCoW

Cut before building.

Four Must Haves, three Should Haves, three Could Haves, and an explicit Won't Have list that killed supplier integrations, a mobile app, and complex reporting before a line was written.

Week 2 to 4 AI assisted

Build at prompt speed.

Lovable and Supabase under my direction, roughly 70 percent faster than traditional development, which moved my effort from writing code to deciding what the code should do.

Post launch HEART

Measure what adoption means.

Happiness, engagement, adoption, retention and task success, so success was defined before launch instead of argued after it. Full adoption landed within two weeks.

03 · What shipped

Parts and projects in one screen. No context switching.

aeroops · dashboard
The AeroOps dashboard with stock counts, inventory table, and a live activity feed

One dashboard answers the daily questions.

Active projects, available stock, low stock alerts and issued parts across the top. Searchable inventory by category on the left, and a live activity feed on the right so the audit trail is not a report you request, it is the screen you already look at.

Demo build, sample data
aeroops · inventory editor
The inventory editor showing every part across its six lifecycle states

Read only by default. Edit mode is a choice.

Every part carries its full lifecycle across six columns, so a quantity is never a single ambiguous number. Editing is behind an explicit toggle, because in a shared inventory the expensive mistake is the accidental one.

Demo build, sample data
The decision that made it stick

Inventory and projects, deliberately not two tools.

Every off the shelf option treats stock and project management as separate products, which is exactly how the team lost track in the first place: a part issued in one system, a build tracked in another, and nobody able to answer which project consumed what. AeroOps unified them, so assigning a part to a project, to a person, and to a build stage is one action in one place. That is also why adoption reached the whole team in two weeks: nobody had to change how they worked, only where they recorded it.

100% team adoption in 2 weeksZero inventory errors since launchComplete audit trail, exportable
04 · The calls

Five decisions, each with the road not taken.

Every tradeoff went through one filter: does this serve this team's specific workflow? If not, it was cut. Here is what got chosen, what got rejected, and the tradeoff each call accepted.

01

Local hosting, not SaaS.

Rejected: a cloud hosted deployment

Defence adjacent work carries security requirements that a shared cloud does not satisfy comfortably, and the team wanted the system to keep working without internet. Production runs on the company's own server. The public demo exists so the work can be shown without exposing anything real.

02

Six states, not one quantity.

Rejected: a single inventory table with a count

Available, Issued, Rejected, Maintenance, Damaged, and Ordered but not received. The simpler model would have shipped days earlier and then lied constantly, because a part in maintenance is not available and a part on order is not missing. The schema had to match the bench.

03

Workflow specific, not feature rich.

Rejected: a generic tool with everything switched on

The team knew exactly what they needed, so custom beat generic. Task based navigation with a small number of named actions, and the fewest clicks to finish a real job, because a tool that needs training in an R and D lab does not get used twice.

04

QA lives inside receiving.

Rejected: accepting stock on arrival and sorting quality later

Parts arrive, get checked, and are accepted or rejected before they can ever be issued. Putting the quality gate in the intake flow is what makes Rejected a first class state rather than a note someone forgot to write down.

05

AI assisted delivery, product led direction.

Rejected: writing it all by hand, or buying a licence

Lovable plus Supabase compressed build time by roughly 70 percent, which bought back the weeks that went into discovery and prioritisation. The leverage was not the speed of the code. It was spending that saved time on the right problem.

05 · Deliberately not built

The Won't Have list was written first.

Prioritisation is only real when something gets refused in writing. These were named out of scope before development started, not quietly dropped later.

Supplier integrations

Attractive, and a dependency on other companies' systems for a v1 that needed to ship inside four weeks.

A mobile app

Desktop first, because the work happens at a bench with a laptop open. A phone app would have been a second product, not a feature.

Complex reporting

The dashboard counts and the exportable activity log answer what the team actually asks. Everything beyond that was decoration with a maintenance cost.

QR scanning and predictive restocking

Both genuinely good ideas, both parked as Could Have. They optimise a workflow that first had to exist.

The roadmap holds those, plus an analytics view once there is enough history to mean something. Each waits for evidence, not enthusiasm.

06 · How it was built

AI wrote the code. The judgment was mine.

The method

Discovery earned the four weeks.

Three personas, one root cause, a MoSCoW split, and a decision table pairing every choice with its rejected alternative. The build was fast because the thinking was done first.

The build

React and Postgres, nothing exotic.

A React frontend via Lovable on Supabase Postgres, with a demo deployment on Vercel and production on the company's local server. Boring infrastructure, so the interesting part could be the workflow.

The outcome

Adoption, then trust.

Full team adoption inside two weeks, zero inventory errors since implementation, and an estimated $15K a year recovered from time that used to disappear into spreadsheets.

07 · The numbers
0components tracked across multiple concurrent drone programs
0less time spent on inventory management, the headline outcome
0team adoption within two weeks of launch, no mandate required
0estimated annual saving from time that used to vanish into spreadsheets
0inventory states, because parts move through a lifecycle rather than a count
0from first discovery interview to a deployed, adopted system

"The team did not need better spreadsheets. They needed their workflow to be visible. Everything else was implementation."

The closing lesson · AeroOps
Have an operations problem like this? Talk to me →
Next case study

Neha: The Voice Agent

A bilingual voice AI that calls approved credit card customers who stalled before activation. Seven hostile personas attacked her; the polite ones turned out to be the real threat.

Read it →