How Odoo Scales UAV Production Without Losing Control of a 254-Item BOM

What challenges did we face before implementing?

The company was working with a set of disparate tools, each of which contained only a fragment of accurate information. Commercial proposals were created using a Word template, and quote numbers were assigned manually. Contracts were tracked in a spreadsheet; contacts were stored in HubSpot, which was underutilized. 

Accounting and invoice payments were handled in QuickBooks Online, while payroll data was manually exported from a separate payroll service. A previous attempt to implement a free MRP tool was abandoned, not because of any shortcomings in the solution itself, but because it was introduced too early: it became available before the company was ready for it.

The most critical component database — the one the engineers relied on — resided within the printed circuit board design software. Anything that fell outside the engineering workflow had to be recreated manually.

"I’d like Odoo to be where we look for our information,@ said a company representative. 

The statement clearly articulated the project’s true objective. The priority was to create a unified operating system that the team could fully trust and use as a foundation for independently developing processes in the future.

What approach did we take?

First, we implemented a standard Odoo build guided by one principle:

• Off-the-shelf functionality, where it already existed;
• Odoo Studio, where a field or form just needed customizing;
• Custom development, only where the standard model truly couldn't map the process.

For a startup, this is a cost question, not a preference: custom code is paid for twice, once to build it and again with every update.

The second decision was to build with the client, then transfer day-to-day ownership. We turned requirements into configured workflows for sales, procurement, production, inventory, R&D cost tracking, and shop-floor manufacturing, while the team trained hands-on, practiced between sessions, and learned the system on real products and orders.

Our role covered requirements modeling, system configuration, data structure design, implementation management, and two pieces of custom development: a purchase order print template with the company's terms, and the build plate consolidation rule. Once scope was agreed, the company took over day-to-day operation and kept building its own Odoo expertise.

What was deferred to a later phase?

Not everything that deserved attention could be implemented right away. With a small team and limited time, the client prioritized the operational processes needed to fulfill customer orders, so financial accounting, bill payment, and reporting stayed in QuickBooks Online for now.

We prepared and documented the groundwork for a future Odoo rollout including U.S. localization, a chart of accounts built from the QuickBooks export, and an inventory valuation model, so accounting can move over smoothly later.

Payroll stayed with the existing provider, who also handles U.S. tax filing, and the Quality module was postponed until the core processes were ready to be formalized.

Learn more about Odoo's digital ecosystem for the Aspen Institute Kyiv's programs, events, and community

How did the Odoo implementation take place?

The implementation took place in phases according to the project roadmap. Let’s take a closer look at each phase.

Product Data Model and Multi-Level Bill of Materials (BOM) Structure

We built a comprehensive model of core product data and restructured the drone’s bill of materials into a full-fledged hierarchy in Odoo:

1. Product Categories. We distinguished between raw materials, purchased components, in-house manufactured parts, assemblies, and finished products, each with its own units of measure and cost calculation method.
2. Part Number. We renamed the “Reference” field to “Part Number” and intentionally left it under manual control, since the company already had a proven numbering system in place.
3. Attribute fields for electronics. Using Odoo Studio we added fields needed by electrical engineers to work with components, visible only in the categories to which they apply.
4. Multi-level BOM. The drone’s bill of materials was restructured into a true hierarchy: finished product, assemblies, nested subassemblies, and components;
5. Data entry — engineers entered mechanical part data themselves; data for electronics and printed circuit boards was prepared separately for import.
6. Engineering Change Control. Changes are made either by direct editing with a record in the chat log or through a formal change request with a complete version history in cases where the reason for the change is of fundamental importance.

Why it matters: A bill of materials (BOM) with 254 line items is not an inventory management issue, but a data discipline issue. As soon as the organization starts operating within a unified system with a single part number for each item, all subsequent calculations (what to purchase, what to manufacture, and what the unit cost is) become calculable rather than a matter of debate. For a company where engineers make weekly design changes, it is precisely the version history that allows these figures to be trusted even six months later.

Demand-driven production and procurement

The next stage of implementation involved production and BOM. The key challenge here was to ensure that the system could automatically calculate what needed to be manufactured or procured and when, rather than relying on manual calculations based on a 254-line BOM.

• Confirming a sales order expands the entire BOM tree and automatically generates the right document per item: a production order for items to be manufactured, a request for quotation (RFQ) for items to be purchased, and nothing for items already in stock. Drones are built to order, while spare parts such as battery packs are stocked under reorder rules with minimum and maximum levels.
• Procurement follows the company's actual supplier workflow. RFQ, purchase order with the company's terms on a printed template, goods receipt, and a supplier invoice whose discount column appears only when a discount applies. Production orders for the same part from different sales orders can be merged into one, with lead time recalculated proportionally.
• Subcontracting follows Odoo's standard flow. Components are sent out and finished parts return via a purchase order. Portal access lets the subcontractor view relevant documents and job status without an internal user account.
• One exception required custom development. Because several structural parts are 3D-printed together on one build plate, the plate is the real unit of production, not the part. An automation rule consolidates printed-part demand into plate orders, raising the quantity on an existing plate or creating a new one, while keeping the link to the originating order..

Why it matters: The company manufactures high-end products in small batches, and this is exactly the kind of situation where excess inventory can cripple a startup’s cash flow. Made-to-order production based on the entire bill of materials means that components are sourced because a customer has ordered a drone, not because someone predicted quarterly volumes. Combining duplicate orders and consolidating purchases are particularly important at this scale, where a few saved orders for parts translate into real money.

Consolidating printed parts onto shared build plates is where 3D printing either pays for itself or quietly bleeds money. Doing that grouping by hand every morning is exactly the task a small operations team has no capacity for — and exactly the task that gets skipped. Automating it means plates fill up on their own, without anyone losing the link between a printed part and the customer order behind it.

Execution and tracking on the production floor

The next step was to bring the actual production flow into the system without distorting how the shop floor really operates.

Work centers were modeled on the actual production layout: support removal, harness production, board assembly, and final assembly. Operators log into the “Production Floor” app on a shared tablet via personal PINs on their employee profiles, not individual internal user accounts. Work order duration is tracked against planned vs. actual, so the plan reflects reality rather than the reverse.

Separating machine time from operator time sounds like a technicality, but it isn't. The 3D printer's work center carries a zero hourly cost, while the brief operator step carries a real rate, so a printed part's cost reflects labor consumed, not continuous machine runtime.

Tracking was applied where it pays off, not everywhere it was possible. Serial numbers on the finished drone, battery pack, and controller; batch tracking where batches are enough; no serialization where handling costs at the bench would outweigh the benefit. Finished goods are posted from the production order, with the operator logging the event directly on the shop floor.

Why it matters: If machine time is equated with the cost of labor, this subtly inflates the cost of each printed part and every quote based on it. Distinguishing between these two metrics gives the company a pricing advantage that it can justify to the customer.

Serial numbers pay off not in the warehouse, but in the field. When a battery or controller fails, the company can track the specific device it was installed in and the batch from which it originated. Limiting serialization to only those components that are actually sold and serviced prevents this practice from becoming a hidden tax on assembly line labor.

R&D costs separated from product cost

Each new drone model runs as a separate Odoo project, with its own phases, tasks, and cost account. Components consumed by development are written off through a dedicated R&D location and charged to the project's cost account, giving visibility at both the project and financial-statement level. Whether these costs are capitalized or expensed is left to the company's accounting policy. Purchase orders can be linked to a project at creation or later.

We set and documented one rule: cost is recorded once, either via purchase or inventory transfer, never both. All project expenses appear in a single list with quantity, line amount, and total project cost.

Why it matters: For a startup engaged in equipment development, research and development is typically one of the largest expense categories. When combined with the cost of goods manufactured, this distortion affects both metrics. The product margin appears worse, while R&D appears cheaper than it actually is. Separating these two aspects at the time components are consumed gives the company a clear operational view of R&D costs, without the need to manually reconstruct this information from accounting records.

Product costing based on actual events

Product cost is no longer a separate entry in a spreadsheet. The costs of components and their processing are recorded directly in production orders and in the Cost Analysis report, so the team can see at any time exactly what each subassembly or finished drone consumes, based on procurement and production data already stored in the system. Where serialization or batch tracking is used, the underlying records create an audit trail from the finished device back to the specific, traceable components from which it was assembled.

Why it matters: A cost estimate is only as reliable as the costs on which it is based. When the cost of components is determined by actual purchases and the cost of assembly is based on actual production operations, a company can determine the unit price without guesswork and see exactly which design change made the drone more expensive to manufacture. This advantage remains regardless of whether the company maintains its general ledger in Odoo, so it made little sense to implement it before the accounting issue had been fully resolved.

We also recommend to read Scaling production with Odoo and comprehensive accounting in a single system. Brave technics case study

What results have we achieved? 

The company now runs on a unified operational platform that carries every customer order through quoting, production, procurement, and the workshop floor, all the way to the actual cost of the finished unit and its traceability record. The bill of materials, once a separate artifact, is now the structure the system uses to drive demand and production.

The solution was implemented for 5 Odoo users across 7 operational areas — CRM, Sales, Purchasing, Inventory, Manufacturing, Shop Floor, and R&D cost tracking — with a 254-line multi-level bill of materials and one custom automation. The implementation stayed close to Odoo's standard functionality, with the scope matched to the startup's actual capacity at this stage. 

Key Results

The project delivered five operational capabilities for Angel's next stage of growth:

1. A single source of reliable information about product details and structure.
2. Demand generated automatically from customer orders, without manual planning.
3. Production costs that hold up under scrutiny.
4. R&D expenses allocated to a separate line item.
5. Traceability applied exactly where it pays off.

Angel now runs and extends the system independently, turning to Self-ERP for consultation only when additional expertise is needed.

Read more Odoo Experience 2026 Recap: What's New in Odoo 20

Conclusion

When our client received its first customer order, the company found itself in a rare situation: the engineering team was already speaking the language of ready-to-use data, but the operations team was not. 

Instead of trying to tackle everything at once, we chose a different path: to build an operational backbone that the team could manage on its own. A 254-line bill of materials, which had been scattered across separate spreadsheets, was transformed into a single structure, and production, procurement, and cost of goods sold became parts of a single whole.

Today, the manufacturer no longer needs an outside team just to keep the system running. It manages it independently, guided by its requirements, while Self-ERP remains on hand only as much as necessary.