Every team shipping embedded telematics software – whether it powers a fleet tracker, a dashcam, or an OEM-grade hardware product – faces the same decision early in the roadmap: do we build our own OBD stack, or do we license a proven one?
It is a fair question, and the honest answer is not always “license.” Some companies are right to build. Most are not, and sometimes they realise this somewhere between month nine and month eighteen of trying.
This article is for the CTOs, embedded engineering leads, and product managers who are looking at this decision right now. It walks through what building an OBD stack actually involves, what realistic time and cost figures look like, when building genuinely makes sense, and why most teams end up licensing.
The Decision Looks Simpler Than It Is
On the surface, the choice looks like a standard build-vs-buy trade-off. You have a capable embedded team. The OBD II (On-Board Diagnostics II) standard is publicly documented. There are open-source projects on GitHub. Surely a few sharp engineers can put together what you need.
That framing is where most teams go wrong. The mistake is treating OBD software as a protocol implementation problem when it is actually a vehicle coverage problem wearing a protocol implementation costume.
Implementing the OBD II protocols themselves – ISO 15765-4 over CAN (Controller Area Network), the older KWP2000 and J1850 variants, ISO 14229 UDS (Unified Diagnostic Services) for diagnostic services, the SAE J1979 PID (Parameter Identifier) definitions – is bounded, well-documented work. A strong embedded team can do it. The specifications exist. The transport layers are knowable.
What is not bounded is everything outside the standard. And that is where the actual product value lives.
What “Building from Scratch” Really Means
When a team commits to building their own OBD stack, here is what is on the work list, whether they realise it on day one or not:
Core Protocol Implementation
The foundational layer – physical and data-link handling, transport protocols, session management, standard PID requests, DTC (Diagnostic Trouble Code) reading, fault code clearing, mode handling across OBD II modes 01 through 0A, and UDS service support for modern vehicles using OBDonUDS (J1979-2). This is the most predictable part of the project. Call it twelve to fifteen engineer-months for a competent embedded team.
Manufacturer-Specific Handling
This is where the work begins in earnest. The OBD II and OBDonUDS standards define a common interface, but every manufacturer implements it with quirks. Some, especially older vehicles, do not stick to the standard with regard to timing. Newer vehicles can have gateway modules that influence responses. Some return data in unusual formats. Some return different units than the specification. Being able to communicate with a 2020 Ford Explorer correctly does not always get you to a 2011 Toyota Rav4, which does not get you to a 1998 Volkswagen Jetta. The only way to be sure you can communicate with all cars is to test all cars, or as many as possible, and that adds another layer to the challenge.
Realistic figure: roughly six months to one year of testing time for initial broad vehicle validation, then ongoing maintenance as new model years ship.
Test Infrastructure
You cannot validate an OBD stack with unit tests alone. You need real vehicles. Test infrastructure for OBD development typically includes a fleet of test vehicles, CAN simulators for parameters you cannot easily reproduce on real cars, automated regression testing across supported models, and a way to reproduce field issues that customers report.
Realistic figure: $150K to $500K+ in capital and ongoing costs, depending on how serious the coverage program is, plus a dedicated test engineering headcount.
Maintenance Forever
The car industry ships new vehicles every year. Existing models change. Electric vehicle architectures evolve. UDS-based diagnostics replace older OBD II implementations. The stack you built in 2026 will need ongoing investment in 2027, 2028, and every year after that, or your product’s vehicle coverage will degrade over time.
Realistic figure: at least one to two dedicated engineers permanently allocated to OBD stack maintenance once you have real production coverage. This is the cost most teams underestimate by an order of magnitude.
Realistic Total Numbers
Pulling those threads together, here is what building an OBD stack actually costs a serious telematics or fleet hardware company, end to end:
Time to meaningful coverage: 18 to 24 months. Meaningful means broad enough vehicle support that you can credibly sell to customers operating mixed fleets across multiple regions. Faster timelines are possible if you scope coverage narrowly, but narrow coverage is exactly the problem you were trying to solve.
Initial engineering investment: 12 to 28 engineer months of effort accumulated across the team, depending on coverage breadth. At typical embedded engineer costs of $100K to $200K per year in North America or Europe, that is $100K to $500K of engineering before you ship anything competitive.
Test infrastructure: $150K to $500K+ in vehicles, hardware, lab equipment, and tooling.
Ongoing maintenance: 1 to 2 permanent engineers, indefinitely. Plus, continued vehicle acquisition and testing investment as new models ship. Call it $150K to $500K per year, forever.
Opportunity cost: This is the line item most product leaders miss. Every embedded engineer working on OBD coverage is an engineer not working on your differentiated product – your device design, your edge analytics, your cloud platform, your customer experience. For a company whose actual product is a dashcam or a fleet management platform, this is the most expensive part of building.
When Building Genuinely Makes Sense
There are real cases where building is the right call. Honesty matters here, because no one wants to read a post that pretends licensing is always right.
Building makes sense when:
- OBD coverage is your product. If you are a diagnostic tool company, a vehicle data API company, or an automotive R&D firm whose deliverable is the data layer itself, building is your core competence by definition.
- You need very narrow coverage, permanently. If your product only ever needs to support three specific vehicle models from one manufacturer – say, a fleet that exclusively operates one OEM’s trucks – you can scope a build down to something tractable.
- You have specific intellectual property requirements that make licensed code unworkable, such as government or defence applications with source-control mandates that no commercial license satisfies.
- You have an existing internal team with deep vehicle data expertise that is underutilised and that you need to keep busy on something strategically defensible.
If none of those apply to your situation, building is almost certainly the wrong answer.
Why Most Teams End Up Licensing
The pattern we see across the 76+ companies in 20 countries that come to OBD Experts for OBD II source code licensing is remarkably consistent:
The team starts by prototyping internally. They get a few standard CAN calls working in a few weeks. They feel good about progress. Then a customer asks for support on a vehicle they have not tested, maybe it’s not OBD II CAN. Then another customer asks about a brand new vehicle, but their team can’t get comms at all. Then a third customer insists they need odometer readings for an important client with a fleet of pre 2010 delivery vans. Then the team realises they have committed to a coverage roadmap that has no end.
Somewhere between month nine and month eighteen, the conversation inside the company shifts. The engineering team starts asking whether OBD coverage is really what they should be spending their time on. The product team starts noticing that the roadmap items their customers actually pay for keep getting pushed because the OBD work is consuming the bandwidth. The CTO does the math on permanent maintenance headcount and reaches a clear conclusion. At that point, OBD II source code licensing stops looking like a shortcut and starts looking like the only sensible path forward.
That is the moment most teams license.
One global telematics hardware manufacturer made the same switch – and went from initial setup to working implementation in three weeks. Read the case study.
What OBD II Source Code Licensing Actually Includes
For teams evaluating what they would receive when licensing rather than building, here is what a professional OBD software stack typically includes:
- Full protocol implementation across ISO 15765-4 (CAN), KWP2000, J1850 VPW and PWM, and ISO 14229 UDS, with support for OBDonUDS (J1979-2) and J1979-3 for modern and electric vehicles.
- Comprehensive PID and DTC handling across all OBD II and OBDonUDS modes.
- Tested vehicle coverage across 60+ manufacturers, validated against real vehicles rather than inferred from specifications.
- Portable C implementation designed to run on a wide range of embedded targets, that can move with your company from product to product as your offerings evolve.
- Documentation, integration support, and ongoing updates as new vehicles ship and existing models evolve.
This is what the OBD Software Stack from OBD Experts provides. For teams that also need access to non-standard parameters – true odometer, gear, seatbelt status, door positions, and similar – Odomatic sits on top of the stack and adds that enrichment layer.
The Real Comparison
The honest framing is not “build or license.” It is “what business are we actually in, and where do we want our engineers spending their time?”
A telematics hardware company’s real product is the device, the data platform, and the customer experience. A dashcam company’s real product is the camera system, the AI processing, and the evidence workflows. A fleet management platform’s real product is the application layer customers log into every day. In every case, the embedded telematics software beneath the product is infrastructure – necessary, but not differentiating.
The companies that ship fastest, scale broadest, and maintain the cleanest engineering focus are the ones that recognise this distinction early and turn to OBD II source code licensing from a specialist. The same pattern played out a generation ago with Bluetooth stacks, TCP/IP implementations, and cryptographic libraries. Almost no one builds those from scratch anymore, for the same reason: the cost of doing so far exceeds the value of doing it yourself.
OBD software is on the same curve. The teams adopting it that way are the ones that will ship their actual product on time.
FAQ
A team can implement standard OBD II for a handful of vehicles in roughly nine to twelve months. Reaching the level of vehicle coverage that customers actually demand – broad support across 60+ manufacturers – is an 18 to 24 month effort minimum, with permanent maintenance investment after that.
Licensing is a one-time integration fee plus ongoing support, scaled to deployment volume. Building, when accounted for honestly, runs into millions of dollars across engineering effort, test infrastructure, and permanent maintenance headcount. The exact comparison depends on coverage requirements and deployment scale, but for most companies the licensing path is significantly less expensive on any reasonable time horizon.
Yes, and some teams do exactly this. They license the OBD Software Stack for the foundational protocol work and build their own logic on top. Other teams license both the stack and Odomatic for the non-standard parameter access. The right mix depends on what you are trying to differentiate on.
Licensed source code gives you the implementation, which means you can integrate it into your product, optimize it for your hardware, and extend it where you need to. The trade-off is that you do not maintain the underlying vehicle coverage program, which is exactly the trade-off most teams want to make.
Professional OBD stacks are designed to be portable across a wide range of embedded targets. The OBD Experts implementation runs on a variety of microcontrollers. Integration support is part of the licensing engagement, so hardware-specific questions get answered upfront rather than discovered in production.
Open-source OBD libraries are useful for prototyping and educational work, but they are not generally appropriate for commercial use and often lack full electrical protocol support, comprehensive SAE standard implementation, and the ongoing maintenance that production deployments require.
The fastest way is a conversation with our team about your coverage requirements, hardware platform, and roadmap. Most evaluations start with a technical discussion and a clear picture of how integration would work on your specific product.
The build-vs-license framing in this post is most useful for teams considering writing OBD software internally. If your product currently uses an OBD chip (for example, the STN1110 or STN2100), the trade-offs are different – chip lead times and availability, per-unit BOM cost at volume, support for newer standards like J1979-2 (OBDonUDS), and the difficulty of adding OEM-specific parameters like odometer all factor into the decision. We cover that specific transition here: Transitioning from an OBD Chip to the OBD Protocol Stack.
Closing Thought
The build-versus-license question is almost always answered correctly by getting honest about the real numbers and equally honest about what business your company is actually in.
For most telematics, dashcam, fleet, and logistics hardware companies, OBD software is infrastructure that should be reliable, broad, and maintained by someone whose entire business is keeping it current. That frees your engineering team to focus on the product your customers actually pay for.If you are weighing this decision right now, book a demo to talk through your coverage requirements with our team, or explore the OBD Software Stack page for more details on what licensing includes.
