Pass compliance the first time..

The pattern is familiar: a product reaches the end of its design phase, goes to a compliance test, fails, and the engineering team is back at the drawing board — usually with schedule pressure, sometimes with a tooling commitment already in place. Re-design at that stage is the most expensive moment to discover a compliance gap.

We work with engineering teams before they reach that point. The objective is the same one their compliance lab would set: pass the relevant standards the first time, with reliable margin, on a schedule that fits the project rather than fights it.

This is engineering consultancy — not certification, not test execution, not regulatory advisory. We do not certify products and we do not replace accredited compliance laboratories. What we do is help engineering teams understand which standards apply, which methods within those standards drive the design, and how to verify compliance early enough that surprises don't reach formal testing.

A structured review of a product (concept-stage, prototype-stage or pre-production) against the standards it must meet.

What we look at:

• The list of standards that actually apply (often shorter or longer than the team initially assumes)
• How each applicable standard's test methods map to specific design features — enclosure geometry, connector selection, PCB grounding, cable management, material choices
• The relationship between standards (where one standard cites another, where two standards have overlapping test profiles, where tailoring is possible)
• Failure modes the test programme is likely to expose and the design changes that would address them
• Practical test sequence — what to verify in-house early, what to defer to formal test

Output:

A written design review report that lists the applicable standards and methods, the design features driving each, the residual risks and the recommended actions. Engineering teams use the report to drive their own design decisions; we do not certify the design.

When this fits:

• Concept-stage product (cheapest moment to apply the result)
• Prototype-stage product where the team needs an external perspective before locking the design
• Product update or platform-change where the existing design must be re-evaluated against a different standard

A detailed test plan for the product — the document that drives both pre-compliance verification and the formal certification campaign.

What goes into a test plan:

• Standards and test methods mapped to product features
• Severity and procedure selection (where standards offer choice)
• Sample preparation requirements and the number of samples needed
• Sequence of testing — what runs first, what depends on what, what can run in parallel
• Acceptance criteria for each test
• Equipment list and required calibration
• Documentation and data acquisition requirements per the standard's evidence rules

Output:

A test plan document that the team can hand to its compliance lab, its in-house test team or to an external contractor like ourselves. The test plan reduces ambiguity in the formal test campaign — both sides know exactly what is being tested, how, and what counts as pass or fail.

When this fits:

• After a design review when the team is ready to start formal verification
• Independently of a review, when the team has a good design but needs structure for the test campaign
• Before engaging an accredited lab — a tight test plan reduces lab cost and lab cycle time

A higher-level engagement that maps the product's full compliance path — applicable regulations, applicable standards, certification authorities, test programme, supporting documentation — from where the team is now to certification or product release.

What this covers:

• Regulatory landscape for the product's target markets (EU CE, US FCC, defense procurement specifications, aviation type certification basis as applicable)
• Standards selection — which standards apply because of which regulation, which are voluntary best practice
• Sequence of evidence gathering — what evidence is needed by when, what authorities review which evidence
• Internal documentation needed (technical file, design history, declarations of conformity as applicable)
• Realistic time and resource estimates for the certification work

Output:

A roadmap document with a sequenced list of deliverables, dependencies and decision points. Engineering teams use this as a planning tool; project managers use it to budget time and money against the actual scope of work.

When this fits:

• Early in a new product programme, when the team has the technical direction but has not mapped the compliance work
• When entering a new market with an existing product (where applicable regulations and standards differ)
• After a regulatory landscape change that affects an existing product