From schematic to bring-up: scoping a bespoke electronics project.

A bespoke electronics project runs through a fixed sequence of stages, whether it is a clean-sheet product or a single board bolted onto an existing system: requirements and feasibility, architecture, schematic and PCB design, firmware, prototype and bring-up, design verification, and DFM and production transfer. Each stage has a defined deliverable, and you can enter the sequence at any point — a stalled schematic, a firmware bring-up needing a second pair of senior eyes, or a DFM pass ahead of a production run are all legitimate starting points, not just a clean-sheet design. What follows is what to expect at each stage, what you should receive at the end of it, and how the two questions that matter most to anyone commissioning this work — who owns the IP, and how compliance standards get handled — are answered before a line is drawn.

Stage 1 — requirements & feasibility

Before any design work starts, the requirement gets written down: what the board or system has to do, the environment it operates in, the interfaces it must meet, target cost and volume, and any regulatory constraints that follow from where and how it will be used. Feasibility is assessed against that requirement — is it achievable with the intended architecture, components and budget, or does something have to give. The deliverable here is a written requirements specification and a feasibility assessment, not a verbal understanding. It is the reference the rest of the project is built and tested against.

Stage 2 — architecture

Architecture sets the system's shape before schematic capture begins: the block diagram, power architecture, processor and key component selection, interface and communication choices, and how hardware and firmware responsibilities divide between them. Getting this stage right matters more than any single circuit decision downstream — a weak architecture shows up as rework at bring-up or, worse, at production. The deliverable is an architecture document and block diagram that schematic and firmware design both work from.

Stage 3 — schematic & PCB design

Schematic capture and PCB layout are developed together, not handed off in sequence, because layer stack, signal integrity and layout constraints feed back into circuit decisions. This stage covers circuit design proper — power sequencing and protection, DC-DC conversion, analogue front ends, sensor interfaces and signal conditioning — alongside PCB layout: layer stack, routing, and EMC-aware placement. Power and battery work sits here too, described broadly rather than by specific application: power electronics, battery and energy-storage systems, and battery management (BMS) design are treated as core disciplines, applied to whatever the requirement calls for. The deliverables are reviewed schematics, a bill of materials with component selection and sourcing notes, and native PCB layout files ready for fabrication.

Stage 4 — firmware

Firmware architecture is set alongside the hardware design, not written after the board comes back, so driver and bootloader decisions can still influence pin-out and peripheral selection. This covers drivers, bootloader, RTOS configuration and MCU firmware, built to the same architecture document as the hardware. The deliverable is commented, version-controlled firmware source — yours to build on, not a compiled binary you cannot maintain.

Stage 5 — prototype & bring-up

Once boards come back from fabrication, bring-up is the first point the design meets reality: power-up sequencing, instrumented checkout against the design intent, and debugging whatever the prototype reveals that simulation and review did not catch. This is where architecture and schematic decisions get validated or corrected. The deliverable is a working prototype and a set of bring-up and test notes — what was checked, what was found, and what changed as a result.

Stage 6 — design verification

Design verification testing (DVT) checks the design against the original requirement systematically, not just functionally. This stage includes pre-compliance EMC/EMI checks — run early enough to catch a problem while it is still a layout change, not a redesign. The deliverable is a DVT report mapped against the requirements specification from stage one, closing the loop on what was asked for and what was built.

Stage 7 — DFM & production transfer

Design-for-manufacture review checks the design for what changes at volume — tolerances, component sourcing and second-sourcing, assembly process, and test coverage on the production line. Production transfer is a documented handover to your manufacturer and test house; 1722 liaises with them directly through the transfer, but volume manufacture itself sits with your manufacturer, not run in-house. The deliverable is a DFM report and a transfer package: final design files, BOM, assembly and test documentation.

Who owns the IP

You do. Every engagement is work-for-hire: you commission the work, 1722 delivers the output, and the design IP — schematics, layout, firmware source, calculations, test data — is yours from delivery. There is no licence to negotiate, no retained rights, and nothing held back. A mutual NDA is offered as standard on every engagement, before any design detail changes hands in either direction, protecting your proprietary information and any prior art brought to the work.

Standards, designed in from the start

Compliance standards are a design discipline applied from schematic onward, not a late-stage test bolted on before shipping. EMC/EMI, CE/UKCA, LVD, FCC, UL, IEC 62133 and UN 38.3 are named and designed to at the relevant stages — power and layout decisions at schematic and PCB stage, pre-compliance checks at design verification — so that formal testing at production transfer confirms what the design already accounts for, rather than surfacing a rework. 1722 holds no third-party certification and does not claim one; formal certification testing is arranged with an accredited test house as part of production transfer.

What each stage leaves you with

Taken in sequence, the seven stages produce a consistent set of artefacts, not just a working board:

• Requirements & feasibility — a written specification and feasibility assessment.
• Architecture — a block diagram and architecture document.
• Schematic & PCB — reviewed schematics, a BOM, and native PCB layout files.
• Firmware — commented, version-controlled source code.
• Bring-up — a working prototype and bring-up/test notes.
• Design verification — a DVT report mapped against the original requirement.
• DFM & transfer — a DFM report and a documented transfer package.

Every artefact is something your team keeps and can act on independently of what happens next — there is no stage that produces advice alone.

Where to start

Most engagements do not start at stage one. A design that has stalled at schematic, a firmware bring-up that needs a senior review, or a board heading toward production that has never had a DFM pass are all common entry points. Scope and deliverables are agreed against where the design already stands, with the same written statement of work and the same IP terms regardless of which stage you commission. A short discovery call is usually enough to place the work correctly — what stage it is really at, what already exists, and what a written statement of work for the remaining stages should cover.