SPIRIT: an open hardware smartphone built around a Raspberry Pi CM5

A phone made from parts you can buy

SPIRIT is an open source smartphone built from available components, and the project description gives the priorities explicitly: user experience, performance, control, repairability, innovation and privacy. The basis is the Raspberry Pi CM5, the compute module form factor, which is what lets a phone-shaped device be built around a module that is sold separately from the board that carries it.

That choice is the design decision everything else follows from. A compute module is a small board with the processor, memory and connectivity on it, and the rest of the device is a carrier board, a display, a battery, radios and a case. SPIRIT describes itself as a smartphone based on the Raspberry Pi CM 5, and the topic list on the repository names compute-module-5, raspberrypi5, kicad and digikey, along with electronics-engineering and mobile.

The framing is open hardware in the strict sense. The electronics design is in the repository, the mechanical design is in a public CAD project, and the project is explicit that contributions and feedback are welcome with a contribution guide in the repository. There is a licensing directory at the top level, which is not something a software project needs and a hardware project does, since the licences for individual sub-designs can differ from the design's own.

The project is candid that it is unfinished. The README says the project is currently in the development phase, with progress documented on the wiki and on the V Electronics YouTube channel. The last push was on 2026-08-21, the repository is not archived, and there are no GitHub releases, which is consistent with a design in progress rather than a product.

What is actually in the repository

The top level listing is a hardware project's directory structure, and each entry tells you something about how the work is organised.

`EDA-kicad/` is the electronics design, in KiCad, which the topic list confirms with kicad-pcb and kicad-schematics. `mechanical/` holds the mechanical design, `branding/` holds the visual and industrial design assets, and the concept renders in the README live under `branding/Olive-Mavleaugue-early-renders/`, with the images credited to OliveOil-Design. There is a `math/` directory, which is likely where the calculations that size the power budget, the antenna or the thermal design live, and the primary language recorded for the repository is MATLAB, which fits a directory of numerical work rather than a codebase.

`external-addons/` is a directory of third-party designs the project builds on, and `resources/` holds reference material. The README's resources section links the Raspberry Pi CM5 and CM4 datasheets, and a CM5 and CM4 interactive pinout, which is what you would need to design the carrier board around the module's connectors.

`CONTRIBUTING.md` and `LICENSE.md` at the root complete the picture. The licence is recorded as a custom one that GitHub cannot classify, which is common for hardware projects where the design files and the documentation carry different terms, and the separate `licensing/` directory suggests the project is deliberate about that split rather than incidental.

The wiki is where most of the content lives rather than the repository. Its pages are listed in the README's quick links: technical specifications, hardware and electronics, software and operating system, the community page, the parts list, cost, ethical and environmental concerns, compliance and legality, and a DIY build guide.

The roadmap shows how far the design has come

The roadmap in the README is the most useful document for judging the project, because it is a list of what is finished, what is in progress and what has not started.

The chassis is the one part with a public artefact. A public Onshape project is linked, and the path is Onshape 3D model, marked in progress, then a 3D printable chassis, then a CNC chassis. The progression is a sensible one for a small-volume device, where a printed prototype validates the fit before anyone commits to a machined part, and it is the reason the concept renders show a paired phone and a rear close-up with what the image caption calls privacy switches.

The electronic systems line is a longer chain: select critical components, then footprints, symbols and 3D models, then the power system, marked in progress, then audio, then GPS and GSM, then LCD, then camera, then vibration and flashlight, then the fingerprint scanner. The order is the order of dependency, since you cannot lay out a board until the footprints exist, and you cannot design the power system without knowing what the display and the radios will draw.

Integration is where the project makes a choice that is still open. It says to integrate systems into one motherboard or a modular setup, and both options remain on the table. The difference matters for repairability, which is one of the stated priorities, and for the eventual cost.

The operating system is deliberately documented separately, with a wiki article of its own, and the topic list names debian, which suggests the software side of the project is not the same as the hardware side in terms of how much is decided yet.

Onshape for the case, KiCad for the board

There is a genuine tooling choice in the project and it is worth describing, because the two halves of a phone are designed in different places with different collaboration models.

The electronics are in KiCad, with the files in the repository under `EDA-kicad/`. That means the schematic and the board layout are version controlled in git, reviewed through pull requests, and reproducible by anyone with the tool installed. The KiCad project files and the footprint and symbol libraries are part of the same history as the documentation, so a design change and the reasoning behind it land together.

The mechanical design is in a public Onshape project rather than in the repository. Onshape is a browser-based CAD system, and a public document means anyone can open the model and look at it without installing a CAD package or requesting access, and the link in the README is to the document itself with a specific revision in the path.

That is a different collaboration model from the KiCad side, and it is a deliberate one rather than an accident. The chassis is the part most people want to see and comment on without wanting to run a toolchain, and the early renders in the README are there for the same reason. The trade-off is that the mechanical history lives in Onshape's version history rather than in git commits, so the two halves of the design do not share a single timeline.

The renders themselves are credited to OliveOil-Design, and the branding directory name, Olive Mavleaugue, suggests an industrial design concept that was developed alongside the electronics rather than after it.

Community, and a warning about impersonators

The README's quick links give a clear picture of how the project is run. There is a Discord server with an invite link, a YouTube channel for the V Electronics organisation, and a wiki with pages for the community and the contribution guide. Progress is documented in both places, which for a hardware project makes sense, since a commit in a KiCad file does not communicate a design decision as well as a video does.

One instruction in the README is worth repeating because it is unusual to see. There is an important callout warning people to watch out for fake websites and repositories, and asking them to search the issue list before making suggestions and opening new discussions. For an open hardware project that publishes schematics, a fake repository with modified files is a real risk, and the project is defending against it by making the issue list the place to start.

Several wiki pages are marked as coming soon, and the ones that are, are the ones a builder needs most. The parts list is marked coming soon, the cost page is marked coming soon, and so is the DIY build guide. The pages that exist are the ones a contributor needs: technical specifications, hardware and electronics, software and operating system, community, ethical and environmental concerns, and compliance and legality.

The last two are not the usual README furniture for a hardware project. A page on ethical and environmental concerns and a page on compliance and legality both being part of the core wiki navigation says the project is thinking about what it means to ship a radio-equipped device, which is where most of the legal exposure in a DIY phone lies.

Editorial conclusion

SPIRIT suits someone who wants to understand or contribute to a repairable, privacy-respecting phone rather than to buy one, and who is comfortable with hardware design workflows. It does not suit anyone expecting a finished device, since the parts list, the cost page and the DIY build guide are all marked as coming soon and the project is explicitly in its development phase. Before joining in, read the technical specifications page on the wiki, check the issue list rather than opening a new discussion, and look at the public Onshape project to judge how far the chassis design has actually progressed.

Frequently asked questions

Official sources

1. Issues
2. README
3. SPIRIT-org/SPIRIT on GitHub