FAQ

  • What does PK Systems actually do?
  • What kinds of projects are a good fit?
  • What information do you need to quote?
  • How do engagements typically work?
  • What deliverables do you provide?
  • Do you work under NDA and how do you handle confidentiality?
  • Who owns the IP and the work you produce?
  • Do you offer fixed-price work or day rates?
  • How quickly can you start?
  • Can you work remotely, and do you do on-site work?
  • Do you provide testing and validation?
  • Do you help with compliance (UKCA/CE, EMC, etc.)?

PK Systems is a UK-based independent engineering consultancy providing embedded software development, electronics design, and systems engineering for deployable products.

We support teams from prototype through production support, including bring-up, debugging, redesign, and manufacturing handover.

We’re a good fit when you need experienced engineering support on:

  • Embedded firmware and drivers (MCUs, RTOS, Embedded Linux)
  • Electronics design (schematic, PCB layout, power, interfaces)
  • Bring-up, fault finding, and root-cause analysis
  • Design reviews (risk, manufacturability, maintainability)
  • Manufacturing handover support (build packs, test notes, DFM)

If you’re looking for a generalist agency for “anything software”, we’re probably not the right fit.

A quote is faster and more accurate if you include:

  • What you’re building and its purpose (one paragraph is fine)
  • Current stage (prototype / pre-production / in-field issue / redesign)
  • Key constraints (power, cost, size, environment, schedule)
  • What you want delivered (e.g., PCB + firmware, bring-up support, review report)
  • Any existing material (schematics, logs, repo link, photos, test results) if available
  • Your target start date and deadline (if any)

If you don’t have all of this, we can still start with a short scoping call.

Most work follows a simple structure:

  1. Scoping call (define the problem, constraints, and “done”)
  2. Defined work package (fixed scope and deliverables)
  3. Progress updates (so you can track what’s happening)
  4. Handover pack (so your team can maintain and continue the work)

For urgent fault-finding, we can also do time-boxed investigation first, then propose the fix options.

Deliverables depend on the engagement, but commonly include:

  • Schematics, BOM, PCB layout files, fabrication notes
  • Firmware/source code, drivers, build instructions
  • Bring-up notes and debugging findings
  • Test notes/results against agreed acceptance criteria
  • A handover pack so your team can continue without rework

We aim to deliver work that is maintainable and supportable, not “throw it over the wall”.

Yes. We’re comfortable working under NDA, and many clients prefer it.

We treat project information as confidential and only share work artefacts with the people you authorise.

If needed, we can also agree what may or may not be referenced publicly (for example: anonymised outcomes).

In most client engagements, the client owns the deliverables produced under the contract (source code, design files, documentation), subject to any agreed third-party licensing for tools/libraries.

If you have specific IP requirements, we’ll confirm them during scoping and reflect them in the paperwork.

Both, depending on the situation:

  • Fixed scope / fixed price works well when deliverables are clear.
  • Time and materials (day rate) is often better for investigation, bring-up, and fault-finding where unknowns are real.

We’ll recommend the approach that reduces risk and avoids “scope theatre”.

It depends on current commitments, but we can usually offer:

  • A short scoping call quickly, and
  • A start date once scope and priorities are clear.

If you have a deadline, say so upfront — it changes how we plan the work.

Most work is delivered remotely with structured updates and shared artefacts.

On-site work can be arranged when it’s genuinely beneficial (for example: lab bring-up, production support, or hardware access constraints).

If on-site access is required, we’ll confirm location, timing, and any site requirements during scoping.

Yes — but we define it properly. We prefer to agree:

  • What “pass” looks like (acceptance criteria)
  • How it will be tested (methods, equipment, constraints)
  • What evidence will be provided (test notes, logs, measurements)

This avoids ambiguous “tested” claims and makes the handover defendable.

We can support design decisions and documentation that reduce compliance risk (for example: EMC-aware layout guidance, interface robustness, review notes, and preparation for testing).

We don’t pretend to be a test lab, but we can help you arrive at testing with fewer surprises.