Most evaluations of automotive software development companies screen on the wrong things. Headcount, hourly rate, logos on a slide and a list of protocols the team has touched are all easy to collect and none of them predict whether the supplier will pass your gates.
The things that do predict it are duller and harder to fake: a documented standard process that survives an assessment, a traceability chain that holds across tool boundaries, engineers who work at silicon level rather than on top of a vendor SDK, and evidence rather than assertion.
This is a checklist you can run in a two hour technical call and a follow up document request. It is organised as process capability, functional safety, cybersecurity, technical depth, evidence, and commercial continuity, with the specific question to ask under each and the answer that should worry you.
Two questions that filter fastest
Before anything technical, two questions remove most of the field of automotive software development companies you are considering.
Are we buying capability or capacity? A supplier who sends engineers and bills by the hour is selling capacity, and the deliverable is attendance. A supplier who takes a scope and returns working firmware, a test rig and a certification pack is selling capability. Both are legitimate, and buying one while expecting the other is the most common failure in this market. Ask which they are proposing and what specifically you hold when the engagement ends.
What does the customer above us require? If you are a Tier 1 supplying an OEM, the OEM’s process requirements flow down to you and then to your subcontractors. If your OEM requires Automotive SPICE capability level 2, a subcontractor who cannot produce evidence inside your process becomes your finding, not theirs. Establish the flow down before you evaluate anything else, because it determines whether the rest of this checklist is a preference or a hard filter.
Process capability: ASPICE is the screen most OEMs actually apply
Automotive SPICE is the industry’s process assessment model for the maturity of development processes in software based systems. It is managed by the VDA QMC and derives from the ISO/IEC 330xx assessment family, and it is the single most common formal screen applied to automotive software development companies.
| Level | Name | What it means |
|---|---|---|
| 0 | Incomplete | Process is missing or fails to achieve its outcome |
| 1 | Performed | Process achieves its outcome |
| 2 | Managed | Process is planned and monitored, and work products are managed |
| 3 | Established | Process follows an organisation wide standard process |
| 4 | Predictable | Process is controlled quantitatively |
| 5 | Innovating | Process is improved continuously and systematically |
Many OEMs require level 2 or level 3 from suppliers, and in practice levels 2 and 3 are the only targets that matter, with levels 4 and 5 playing almost no role in supplier assessment. Assessments are conducted against evidence using the NPLF rating scale, and only intacs certified assessors can perform VDA recognised assessments.
The distinction between level 2 and level 3 is the one worth understanding as a buyer. Level 2 means individual projects are planned, monitored and managed. Level 3 means the organisation has a documented standard process that projects tailor from, with tailoring records and cross project data. A supplier can run one excellent project and still fail level 3.
That is exactly the pattern to probe, because teams that perform well on individual projects but cannot demonstrate a documented standard process will generate findings during assessment. Three failure modes recur:
Traceability chains that break across distributed teams and tool boundaries. Requirements in one system, architecture in another, tests in a third, and no maintained links between them.
Change management without downstream impact analysis. A requirement changes and nothing systematically identifies what else that touches.
No documented standard process with tailoring records, so every project is bespoke and nothing is repeatable.
ASPICE 4.0, published in 2023, expanded the scope from software to broader system coverage and added Hardware Engineering, Machine Learning Engineering and Validation process groups. Roughly ten processes were removed and ten added, level 3 guidance was reworked, and the terminology shifted from test to verification across the engineering process groups. If a supplier’s ASPICE evidence predates 2023, ask what they have done about the new process groups.
Ask this: what capability level have you been assessed at, by which intacs certified assessor, when, and for which scope. Then ask to see the assessment report rather than a certificate.
Functional safety: an ASPICE level tells you nothing about ISO 26262
This is the misunderstanding that costs programmes the most, and it is the claim automotive software development companies most often blur, so it is worth stating plainly.
ASPICE measures process capability. ISO 26262 specifies which functional safety activities and artefacts a project must produce based on risk classification. They are independent. Achieving ASPICE level 2 does not imply ISO 26262 compliance, and meeting ISO 26262 requirements does not guarantee any particular ASPICE capability level. The two overlap in configuration and change management practices and nowhere else that matters.
So a supplier who answers a functional safety question with an ASPICE level has either misunderstood the question or is hoping you have.
ISO 26262 classifies risk through three factors assessed during hazard analysis: severity from S0 for no injuries to S3 for life threatening or fatal, exposure from E0 for incredibly unlikely to E4 where injury could happen under most operating conditions, and controllability from C0 for controllable to C3 for difficult to control or uncontrollable.
| Classification | Determined by | Implication for a supplier |
|---|---|---|
| ASIL D | S3, E4 and C3 together, the maximum risk | The most demanding evidence, methods and independence requirements |
| ASIL C | One parameter reduced from the ASIL D combination | Substantial safety lifecycle obligations |
| ASIL B | Two parameters reduced | Defined safety requirements and verification evidence |
| ASIL A | Three parameters reduced | Lowest safety relevant classification |
| QM | Below ASIL A | No safety relevance; standard quality management only |
The second edition of ISO 26262, published in 2018, comprises twelve parts, ten of them normative, and extended coverage from passenger cars under 3,500 kilograms to all road vehicles except mopeds.
Ask this: which ASIL levels have your engineers actually worked to, on which components, and in whose safety case. Then ask who held the safety manager role. A supplier who has contributed software into an ASIL B or ASIL D item under someone else’s safety case has genuine relevant experience, and that is a different and more honest claim than certification.
Cybersecurity and the regulatory chain
Automotive software development companies now sit inside a regulatory chain whether their contract says so or not. Since July 2024 every newly produced vehicle in UNECE 1958 Agreement markets needs type approval under R155 for cybersecurity and R156 for software updates, which means your supplier’s engineering artefacts become evidence in somebody’s audit.
There is also a sequencing constraint that catches suppliers out. Cybersecurity process assessment is not a standalone exercise: a supplier cannot pursue an ASPICE cybersecurity assessment without first completing an ASPICE assessment covering the system and software process groups. A supplier claiming cybersecurity process maturity without underlying ASPICE evidence is describing an intention.
Ask this: how does your release process produce the version traceability, signed provenance and documented update failure routines that an R156 audit requires, as a normal output rather than something assembled afterwards. And separately: have you worked inside a customer’s cybersecurity management system, and what did you contribute to it.
Technical depth: distinguishing an embedded house from a software house
Process credentials tell you whether automotive software development companies can be audited. They tell you nothing about whether their engineers can do the work. For embedded and wireless programmes, four questions separate the two populations quickly.
What happens when we change silicon? A team that has written against a hardware abstraction layer with a stable contract answers immediately and shows you the layer. A team that has written directly against one vendor’s API promises a refactor. Vehicle programmes outlive silicon, so this is not hypothetical.
Show me a bring up you did on a customer’s board, not a development kit. Bring up means getting a radio working with the customer’s antenna, crystal, power tree and mechanical package. It is where silicon level competence becomes visible, and it cannot be faked in a conversation.
Show me an RF or coexistence report measured in a product. Not a development board on an open bench. In the final mechanical position, with every co located radio active and loaded. This one question eliminates a surprising proportion of candidates.
What test infrastructure would we own at the end? Hardware in the loop rigs, automated protocol qualification runs, RF automation, reproducible builds. If the rig leaves with the supplier, you bought hours.
For wireless specifically, add: which chipsets have you brought up, which certifications have you taken a product through, and can we speak to the engineer who did it rather than an account manager.
Evidence: what to request instead of a claim
Every claim in a capability deck has an artefact behind it or it does not, and requesting the artefact is the whole technique for evaluating automotive software development companies.
| Claim | Evidence to request |
|---|---|
| ASPICE level 2 or 3 | The assessment report, the assessor’s intacs credentials, the assessed scope and date |
| ISO 26262 experience | The ASIL level, the component, the customer’s safety case, the safety manager’s name |
| Cybersecurity capability | Contribution to a customer CSMS, plus the underlying ASPICE system and software assessment |
| Traceability discipline | A live walkthrough from one requirement to its architecture element, code and verification result, across the actual tools |
| Change management | An impact analysis record for an actual change, showing what it touched downstream |
| Standard process | The process documentation plus tailoring records from two different projects |
| Silicon level competence | A bring up report from a customer board |
| RF competence | A coexistence or RF report measured in a final product |
| Test capability | A demonstration of the rig running, and confirmation of who owns it afterwards |
| Certification track record | The certification listing or declaration, not a logo |
The single most revealing item is the traceability walkthrough. Ask them to pick a requirement from a past project, live, and follow it through to a verification result across their working tool chain. Teams with the discipline do it in ten minutes. Teams without it reschedule.
Two smaller tells are worth watching for in the same session. The first is who answers. If every technical question routes through an account manager, the engineers either are not available or are not confident, and both matter over a multi year programme. The second is how they handle a question they cannot answer. A supplier who says they have not done something, and describes what they have done that is adjacent, is giving you information you can plan around. A supplier who answers everything affirmatively is giving you nothing, because a capability list with no gaps in it is not a capability list, it is a sales document.
Commercial and continuity questions
Technical evaluation dominates these conversations, and the commercial terms with automotive software development companies cause more programme damage.
Who owns the IP, and is it assigned on payment or on completion? Get this in writing before work starts, not at the end.
What happens if you stop trading? Source escrow with a defined release trigger, or a documented handover package. For a fifteen year vehicle life this is a legitimate question even of a healthy supplier.
How fast can you ramp, and with whom? Ask for named engineers with relevant experience, not a headcount promise. Then ask about retention, because a team that turns over annually cannot hold context on a multi year programme.
What does exit look like? Documentation standard, handover period, and whether your own engineers can maintain the code. A supplier confident in their documentation answers this comfortably.
Where is the work done, and does that matter to us? Data residency, export control and customer preference all bear on this, and for defence adjacent programmes it can be decisive.
A scoring approach you can run
Score automotive software development companies by weighting the categories according to what your programme actually risks. A safety critical ECU weights functional safety and process capability heavily. An infotainment accessory weights technical depth and ramp speed. A programme with an OEM above you weights whatever they flow down.
Score each category from the evidence rather than the claim, using a simple scale: evidence provided and verified, evidence claimed but not provided, or not applicable. Then look at the pattern rather than the total. A supplier with strong technical depth and weak process is a subcontractor you can wrap inside your own process. A supplier with strong process and shallow technical depth is a prime contractor who will subcontract the hard part. Both can work. Not knowing which one you have is what does not.
Where needCode fits, honestly
Most automotive software development companies you will assess are generalists. needCode is an embedded wireless specialist, not a Tier 1 and not a general automotive software house. That distinction matters when you apply the checklist above.
What the team brings is technical depth of the kind section five describes: chipset bring up on customer hardware across Qorvo QM33 and QM35, NXP Trimension, Nordic nRF54 and nRF53, STMicroelectronics, Infineon and Silicon Labs parts and legacy DW1000 and DW3000 designs, UWB and BLE ranging and access systems through to FiRa and CCC certification, and test infrastructure including a purpose built UWB protocol analyser the team designed because the instruments did not exist. needCode is a certified Qorvo partner of more than eight years, a Nordic Semiconductor Design Partner for EMEA and a UWB Alliance member, and holds ISO/IEC 27001:2022 and ISO 9001:2015.
The honest positioning is that this is a specialist that works inside a customer’s process rather than a prime contractor bringing its own assessed process to your programme. For an OEM or Tier 1 that already runs an assessed development system, that is usually the right shape: you supply the process, we supply the wireless engineering that your process is not staffed to do. Our automotive and SDV practice and SDK design work are both structured that way.
Apply your own checklist to us. If the answer is that you need a supplier who arrives with an ASPICE level 3 assessment and a safety manager on staff, we will tell you so rather than waste your evaluation cycle.
To talk through where a wireless specialist fits in your supplier mix, book a discovery call.
Frequently asked questions
Level 2 or level 3, depending on what flows down to you. Automotive SPICE defines six levels from 0 to 5, but in supplier assessment only levels 2 and 3 are practically relevant, with levels 4 and 5 playing almost no role. Level 2 means individual projects are planned and monitored and work products are managed. Level 3 means the organisation has a documented standard process that projects tailor from, with tailoring records and cross project data behind it. The gap between them is the difference between a supplier who ran one good project and a supplier who can repeat it. Ask for the assessment report rather than a certificate, and check the assessor is intacs certified, since only intacs certified assessors can conduct VDA recognised assessments. Also check the date: ASPICE 4.0 arrived in 2023 and added Hardware Engineering, Machine Learning Engineering and Validation process groups.
No, and treating the two as interchangeable is a common and expensive error. ASPICE measures process capability. ISO 26262 specifies which functional safety activities and artefacts a project must produce, based on a risk classification from ASIL A to ASIL D. Achieving ASPICE level 2 does not imply ISO 26262 compliance, and meeting ISO 26262 requirements does not guarantee any particular ASPICE capability level. The two overlap in configuration and change management and little else. Evaluate them separately: ask for the ASPICE assessment report on one hand, and on the other ask which ASIL levels the engineers have worked to, on which components, inside whose safety case, and who held the safety manager role.
Start with the sequencing constraint, because it is a fast filter. A supplier cannot pursue an ASPICE cybersecurity process assessment without first completing an ASPICE assessment covering the system and software process groups, so a cybersecurity maturity claim with no underlying ASPICE evidence is an intention rather than a capability. Then move to the artefacts, since since July 2024 every newly produced vehicle in UNECE 1958 markets needs R155 and R156 type approval and your supplier’s outputs become evidence in that audit. Ask how their release process produces version traceability across ECUs and variants, signed release provenance, and documented routines for a failed update, as a normal output of the process rather than something reconstructed afterwards from version control history.
Ask them to pick one requirement from a past project, live in the call, and walk it through to a verification result across their actual tool chain. Requirements in one system, architecture in another, code in a third and tests in a fourth is the normal state of the industry, and maintained bidirectional links across those boundaries is what ASPICE assessments examine and what most suppliers fail on. Teams with the discipline complete the walkthrough in about ten minutes and enjoy doing it. Teams without it offer to send documentation later. For embedded and wireless work specifically, the equivalent hardware question is to ask for a bring up report from a customer’s board rather than a development kit, and an RF or coexistence report measured in a final product rather than on an open bench.
It depends on which gap you are filling, and the honest answer is that they solve different problems. A large supplier brings its own assessed process, a safety manager, and the ability to take prime responsibility, and will often subcontract the deepest technical work. A specialist brings engineers who work at silicon level and instruments the general market does not have, but usually works inside your process rather than bringing an assessed one. Neither is better in the abstract. Decide by looking at the pattern in your evaluation rather than the total score: if you already run an assessed development system and need capability your team does not have, a specialist wrapped inside your process is efficient. If you need someone to own the whole scope including the process evidence, you need a prime, and you should ask them who they will subcontract the hard parts to.
