Propulsion allocation OS for defense drone makers to ramp new factories without stalling on scarce motors, engines, and release evidence.

1. Investors are now paying for manufacturing scale, not just prototype novelty, which creates budget and urgency for production-control software.
2. A decentralized factory network means line balancing and scarce-component allocation must happen across sites instead of inside one plant.
3. Solid rocket motors and small jet engines have become visible chokepoints, so software that governs their allocation and release can sit on the critical path.
4. Five systems plus a new Navy strike-aircraft program force one company to choose which platform gets constrained propulsion first.
5. Pentagon volume expectations mean missed build decisions quickly become program delays rather than internal ops annoyances.

Catalyst. Mach's new facilities, Forge network, DIU-funded Navy aircraft program, and vertical integration into constrained propulsion show the market has shifted from drone experimentation to multi-site production planning now.

The product sits above ERP, PLM, and supplier portals as the decision layer for constrained drone production. It ingests factory capacity, propulsion lot status, qualification rules, build plans, and program priorities, then tells operations leaders which site should build which units with which scarce components this week. It also generates the release packet for each factory-program combination, so teams know whether the right lot genealogy, work instructions, and evidence are in place before material moves. The first workflow is intentionally narrow: prevent one constrained motor or engine lot from causing schedule slips across a newly opened second or third plant. Over time, the system becomes the operating record for how defense drone companies allocate scarce subcomponents across an expanding network of factories and programs.

What's different. Existing ERP, APS, and PLM tools can record inventory or configuration, but they do not answer the defense-specific question of where the next scarce propulsion lot should go across multiple drone plants and programs. This company would own the constrained-allocation layer that ties component scarcity, site readiness, and release evidence into one weekly operating decision. Defensibility comes from accumulating proprietary data on how real drone factories consume scarce propulsion, where yield or delay risk emerges, and which allocation choices preserve program throughput under defense-grade traceability requirements.

Jobs to be done

flowchart LR
  Buyer[VP Operations] --> Pain[Scarce propulsion stalls multi-site builds]
  Pain --> Product[Propulsion allocation OS]
  Product --> Outcome[Faster drone factory ramp]

Executive takeaways

• Demand has shifted from prototypes to throughput: DIU, Army, AeroVironment, Anduril, and Mach all point to higher-volume, multi-program drone production rather than isolated demos. [1][2][7][14][17][19][20][21][39]
• Propulsion is still the most credible hard constraint. Solid rocket motors remain concentrated enough that RTX wants a third U.S. source, and small jet-engine capacity is still described as fragile. [9][10][11][12]
• The current stack records data but does not obviously own the weekly cross-site allocation decision. Palantir, IFS, PTC, Tulip, Dassault, and ProShop all cover pieces of planning, traceability, and execution, but none market a propulsion-specific release-and-allocation control plane for drone OEMs. [28][29][30][31][32][33]
• Beachhead demand is real but narrow. The best near-term customers are U.S. drone makers opening a second or third site, adding another aircraft family, or facing Blue UAS / NDAA evidence friction while constrained motors or engines gate output. [1][2][3][4][5][6][14][16][21]

Market definition

The addressable beachhead is software for U.S.-aligned defense drone and loitering-munition manufacturers that need to allocate scarce propulsion lots and release evidence across multiple sites, programs, and aircraft families while staying inside Blue UAS, CUI, ITAR, and quality constraints. [1][2][3][7][22][24][26][27]

Customer and buyer

Primary users are operations, manufacturing-program, and propulsion-supply leaders at drone OEMs and autonomous-aircraft startups; economic buyers are COOs, VPs of Operations, or GMs who own ramp milestones, new-site readiness, and program delivery risk. [1][2][14][16][17][19][21]

Buying triggers

• Opening a new or larger factory creates immediate pressure to rebalance constrained components across sites. [1][2][14][15][16]
• Winning or extending government drone contracts turns allocation mistakes into visible schedule risk rather than internal inconvenience. [19][20][21][39]
• Blue UAS and NDAA compliance changes raise the cost of weak provenance, component verification, and release-packet workflows. [3][4][5][6][40]

Willingness to pay

Public pricing is mostly undisclosed, but buyers already purchase custom ERP, PLM, MES, and secure-cloud stacks; given the cost of stalling a defense production line, a narrow control plane that prevents lot-allocation mistakes can plausibly command six-figure annual contracts inside existing digital-manufacturing budgets. [19][20][28][29][30][31][32][33][34][35]

Category dynamics

Growth signal 19.9% CAGR

Validation signals

• Mach is using fresh capital to expand Forge factories and small jet-engine work, which is exactly the kind of customer motion the product targets.
• Anduril is building a hyperscale factory, strengthening the case that distributed defense manufacturing is becoming a real operating model.
• AeroVironment’s facility expansion plus large Switchblade awards show recurring demand for attritable systems rather than isolated pilots.
• Army and DIU solicitations show the government is still pulling for lower-cost, scalable autonomous systems.
• DIU’s Blue UAS refresh increased verified component options and sped software approvals, making evidence orchestration more operationally important.

Regulatory & technical constraints

• Handling CUI requires a deployment and control model that aligns with NIST 800-171 and adjacent defense cybersecurity expectations.
• ITAR registration, access control, and export rules constrain who can see technical data and where collaboration can happen.
• Traceability documentation and aerospace quality expectations mean each recommendation may need auditable evidence behind it.
• Blue UAS / NDAA component-provenance checks can invalidate a plan if upstream source data is weak.
• Secure-cloud acceptance is necessary but insufficient; the product still needs to integrate with the customer’s existing system-of-record stack.

Competition is strategic rather than direct. Broad manufacturing platforms (Palantir Warp Speed, IFS, Dassault DELMIA, PTC Windchill, Tulip, ProShop) already own pieces of traceability, planning, execution, and digital-thread infrastructure, while in-house spreadsheets and custom integrations remain the status quo. The proposed startup only wins if it inserts a clearly narrower decision layer: which scarce propulsion lot should go to which site, family, and release packet this week. [28][29][30][31][32][33]

Why incumbents do not win by default

• Cloud platforms. AWS GovCloud and Azure Government solve hosting, boundary controls, and compliance posture, but they do not decide cross-site propulsion allocation or program-priority tradeoffs.
• ERP and PLM suites. IFS, PTC, and Dassault connect engineering and manufacturing records, yet they are broad systems of record rather than a fast weekly allocator for constrained drone subcomponents.
• MES and traceability tools. Tulip and ProShop make execution and as-built traceability stronger, but they are not positioned as the optimization layer for scarce propulsion across programs and sites.
• Custom internal tooling. Fast-scaling OEMs can build on data platforms like Palantir or spreadsheets, but startups opening new factories often lack the time to harden bespoke workflows before production milestones hit.

Drone Propulsion Ramp OS is a supplier-side control plane for U.S. defense drone OEMs that are opening second and third assembly sites while scarce motors or small jet engines gate output. The urgent pain is not generic factory visibility; it is the weekly decision of which constrained propulsion lot should go to which site, aircraft family, and release packet without idling a line or starving a priority program. The best first customer is a 150-800 person drone manufacturer with one active Pentagon-backed program, a new site coming online inside 12 months, and recurring allocation meetings still run in spreadsheets, ERP exports, and supplier calls. The MVP should land as an overlay on one aircraft family and up to two sites, ingesting lot status, site capacity, program priorities, and release evidence to recommend the next allocation cycle and flag blockers before material moves. Go-to-market, pricing, and implementation all center on one measurable promise: prevent propulsion-driven schedule slips during a live factory ramp without replacing ERP, PLM, or MES. Research supports real demand and a credible six-figure ACV, but the beachhead is narrow, with a modeled $29.0M SAM and $3.6M year-3 SOM, so expansion into adjacent constrained components and additional programs is required rather than optional. The moat, if earned, comes from lot-site-family outcome data, reusable release-packet templates, and deployment patterns that fit CUI, ITAR, and Blue UAS evidence requirements. The biggest disconfirming risks are that propulsion is not the binding weekly bottleneck often enough, a standalone overlay cannot secure budget against incumbent suites, or secure deployment requirements make pilots too slow and services-heavy.

Problem

• Drone OEMs scaling from one plant to a distributed factory network still allocate scarce propulsion through spreadsheets, ERP workarounds, supplier calls, and weekly cross-functional meetings.
• One wrong lot-allocation decision can idle a new line, starve the highest-priority aircraft family, or trigger a release delay because provenance, qualification, or site-readiness evidence is incomplete.
• Incumbent ERP, PLM, and MES tools record inventory and traceability, but they do not own the defense-specific weekly choice of where the next scarce motor or engine lot should go across sites and programs.

Solution

• Build a secure allocation overlay that combines propulsion lot status, site capacity, program priority, and release-readiness evidence into a weekly recommendation for one aircraft family across multiple sites.
• The MVP should show which lot goes to which site, what output is blocked if that decision changes, and whether the required genealogy, work instructions, and approval packet are complete before shipment.
• Initial deployments are deliberately narrow: one active aircraft family, up to two sites, exported or API-fed data from existing systems, and one live ramp milestone where avoided line-idle events can be measured.

Why we win

• The wedge is a decision layer, not another system of record, which makes the product easier to land inside entrenched defense manufacturing stacks.
• Value is tied to a board-level operating event that incumbents do not solve cleanly today: weekly allocation of constrained propulsion under traceability and release constraints.
• Each deployment compounds proprietary data on lot outcomes, site readiness, supplier reliability, and release-packet reuse that generic suites do not naturally aggregate.
• Market timing is favorable because Pentagon demand, new factories, and Blue UAS provenance pressure are pushing buyers from prototype mode into repeatable throughput.

Milestones

flowchart LR
  Wedge[Propulsion allocation wedge] --> MVP[Weekly allocator plus release packet]
  MVP --> Proof[Fewer line stalls and faster site readiness]
  Proof --> Expansion[More sites, families, and constrained components]

Founding team

Experiment roadmap

Risk assessment

What must be true

• At least 3 of the first 10 target OEMs confirm propulsion allocation is a recurring executive pain rather than an occasional exception.
• A first pilot can go live in 6-8 weeks using exported or lightly integrated data without waiting for a full classified deployment.
• The product reduces manual allocation and release-prep cycle time by at least 25% on the first production customer.
• Buyers will fund a standalone overlay from operations or production-readiness budgets at a $250k+ annual price point.
• One production customer expands into a second site, second family, or adjacent constrained component workflow within 12-18 months.

Open diligence questions

• What were the last three propulsion-driven production delays at target OEMs, and what did each cost in schedule or labor?
• Which executive owns the first software budget for this workflow: COO, VP Operations, CIO, or program GM?
• How much of the first allocation workflow can stay in unclassified or sanitized data before enclave deployment becomes mandatory?
• How often is propulsion the real weekly bottleneck versus batteries, electronics, or another constrained part?
• Which incumbent system or integrator is most likely to neutralize the wedge with configuration or bundling?

Model sanity

• Revenue engine. Base-case revenue comes from 12 paid family-site deployments by Q4Y3, with most growth driven by pilot conversions and a small amount of expansion revenue inside lighthouse accounts.
• Must go right. The company must keep early deployments on exported or sanitized data so pilots convert before security review and services drag overwhelm the narrow market.
• Model breaks if. If sales cycles stretch to 6+ months or propulsion stops being the binding bottleneck, downside revenue falls toward $2.2M and cash compresses to roughly $140K.
• Next-round proof. The next round is justified only if Q4Y2 shows at least 4 production deployments, one expansion sale, and a repeatable secure deployment pattern that lowers CAC and implementation risk.

Scenarios

Sensitivity

flowchart LR
  Accounts[Target drone OEM accounts] --> Audits[Paid readiness audits]
  Audits --> Pilots[Paid pilots]
  Pilots --> Deployments[Annual deployments]
  Deployments --> Revenue[Recurring revenue plus onboarding]
  Revenue --> GrossProfit[70% gross profit]
  GrossProfit --> Cash[Cash runway]

Flags: Initial SAM is only about $29M, so the model needs expansion inside existing accounts rather than pure new-logo growth to justify venture returns. · Y3 is still slightly EBITDA negative, which is believable for a secure, implementation-heavy defense workflow but leaves little room for delayed conversions. · Revenue per FTE sits near the low end of software benchmarks because forward deployment and compliance labor remain meaningful through Y3.

• Classified workflow friction. Defense manufacturers may resist adopting a new control layer if it cannot fit secure or partially air-gapped environments. Mitigation: Start with an unclassified planning workflow, support secure on-prem or enclave deployments early, and integrate with existing approved systems instead of replacing them.
• Too narrow a starting category. A wedge built around rocket motors and small jet engines could cap early revenue if only a few programs fit the profile. Mitigation: Design the data model for any constrained subcomponent from day one and expand next into energetics, avionics, and electronics once the first propulsion workflow lands.
• Incumbent stack entrenchment. ERP, PLM, or custom internal tooling may already own parts of factory planning and make buyers skeptical of another dashboard. Mitigation: Sell measurable schedule protection on one aircraft family, integrate into existing systems of record, and prove value through avoided line-idle events rather than broad transformation claims.