framedeck is a cyberdeck built around a Framework mainboard, released as a guided tour

A slab computer, in the spirit of the TRS-80 Model 100

framedeck is one machine, built once, and published as a set of design files. The designer describes it as his take on the slab style computers that were somewhat popular before the world settled on clamshell designs for portable computers, and he says plainly that he wanted a TRS-80 Model 100 as a child and that this sort of design was a big influence. That is the design brief, and it explains the proportions in the photographs: a flat rectangular body with the display and keyboard on one face, built as an object rather than a kit of parts.

The machine runs a Framework mainboard, the single board that normally sits inside a Framework laptop. The mainboard is described as a full Intel based system on a single board with good storage and memory expansion, decent on board graphics and full power management. The design decision that makes the project interesting is that the board was designed to fit into a laptop first, so some of its connectors are specialised, but the pinouts are published and that opens up the expansion options.

The result is a working computer rather than a mockup. The build includes a battery taken from the Framework laptop, a custom mechanical keyboard, a wifi card, SSD storage, 16GB of memory, a 7 inch IPS display and speakers. The author describes the goal as making a fairly useful computer, and the honest ambition of the project is a working personal device.

The collaboration came with a condition attached

The origin story matters for how the repository is licensed and what it contains. As Framework was preparing the release of the technical documentation for the mainboard, they emailed the designer to ask whether he would be interested in a collaboration of sorts. They would provide one of their laptops and some additional modules for him to build something unique with, and the only condition was that he released the designs for public use.

That condition explains the shape of what you find here. The designs are public, which is the point of the repository, and the Framework mainboard documentation itself, including pinouts and CAD models, is the enabling factor that made a build like this possible in the first place. Without the pinouts, a specialised laptop connector would have been a dead end.

It also explains the tone of the README, which is written as an account of the design decisions rather than as an assembly manual. The author says he jumped at the chance to play with the board and describes the result as what he came up with after some experimentation, and the repository is offered as a sort of guided tour meant to give some inspiration and show what might be done with the mainboard.

The copyright line names Richard Sutherland and dates the work to 2022, and the files are released under the MIT licence and CC BY-SA 4.0, with the LICENSE file carrying the details of which applies to what.

USB-C is the expansion story, pinouts are the second one

The practical question for anyone considering the Framework mainboard as a general purpose single board computer is what you can actually plug into it. The answer given here starts with the easy path: the board has four standard USB-C ports, which the author says provide many possibilities without even trying the other on board connectors. Storage, an SSD, and peripherals all hang off those.

The second path is the specialised connectors. Because the board was designed to fit into a laptop, some of the connectors are not the generic kind you would find on a development board, and the mainboard documentation exists precisely so that integrators can use them anyway. The pinouts, the CAD models and the other resources in that documentation are what turn a set of laptop internal connectors into an expansion surface.

For a builder, this is the distinction that matters. A design that only used the four USB-C ports would be unremarkable. A design that uses the specialised connectors needs the documentation, and the fact that the documentation was published at the same time as the mainboard became generally available is what makes framedeck reproducible in principle.

The other on board assets the designer singles out are storage and memory expansion, on board graphics and full power management. The graphics matter for a 7 inch panel rather than a laptop screen, and the power management matters because the power solution in this build is a laptop battery.

Two power options, and the battery came from the laptop

The power story is unusual, and it is the part of the build most likely to be copied. Rather than designing a custom power system, the author used the battery from the Framework laptop and the mainboard's own power management, with the stated reasons being solid capacity and the fact that it is already designed to work with the on board power management.

The alternative path is documented for anyone who does not want to carry a laptop battery around. The mainboard can be powered via USB-C, so a solid power bank would provide plenty of runtime, and any USB-C power brick works for stationary use. That is a genuinely useful property for a portable machine that people will use in different places, and it is a consequence of the board carrying full power management rather than something the case design had to solve.

The battery and the power management are the same decision, though, so a builder cannot pick one without the other. Using a USB-C supply means abandoning the battery that came with the laptop, and using the battery means inheriting the connector and charge circuit that go with it. The build tour covers the detail the README skips, and that is where the specifics live.

The case is layered acrylic and brass, not a printed shell

The case was the part the author most wanted to get right visually. He wanted something that showed off the mainboard, the custom keyboard PCB and looked unusual, and clear acrylic and brass won. He considered 3D printing and could have done it in several sections, but building the unit from layers of laser-cut acrylic offered, in his words, interesting challenges and opportunities.

That choice is visible in the repository layout. There is a case/ directory with a layers.md document, and the top level holds framedeck_acrylic.f3z, which is the CAD assembly for the acrylic parts, alongside a gerbers/ directory for the printed circuit boards and a kicad/ directory holding the keyboard design. There is also a printed_parts/ directory with a bits.md document, so a small number of 3D printed elements are part of the design after all.

The layered approach has an obvious advantage and an obvious cost. The advantage is that the internals stay visible, which is what the author wanted and what makes the photographs interesting, and each layer is a flat cut that a laser cutter can produce. The cost is that every layer has to be cut and then assembled in order, so the build needs a laser cutting service and the tolerance stack of many stacked sheets, rather than a single printed shell that can be corrected with a reprint.

The MIT and CC BY-SA licensing covers the design files, so anyone can build a variant, and the documentation set lists a parts list, the case layers, the printed bits and a separate document on the keyboard.

The custom keyboard PCB has its own documentation

One README link asks 'What's with that keyboard?', and it points at docs/keyboard.md, which tells you the keyboard is treated as a project of its own rather than an accessory. A custom mechanical keyboard in a deck format needs a PCB to place the switches, a controller to read them, and a case, and the kicad/ and gerbers/ directories in the repository are where that design lives alongside the acrylic work.

The fact that a separate document exists for it says something about the build's difficulty. A mechanical keyboard is the part of a computer most likely to be assembled from a kit, and a designer building a slab style deck from scratch has to decide whether to buy a keyboard module or design the whole thing, including how the switches, the plate and the electronics sit in the layered case. The repository treats that as worth a page of its own.

The rest of the documentation set follows the same logic. docs/build_tour.md is the walkthrough, docs/parts.md is the parts list, case/layers.md covers the case, printed_parts/bits.md covers the printed elements, and docs/keyboard.md covers the keyboard. The author asks readers to reach out if they want to build one or something similar, and says he would be happy to answer questions and provide advice, which is the support model for a one-off design with no vendor behind it.

A guided tour with a warning attached

The author is direct about the limits of the documentation. He calls the repository a sort of guided tour, says it is not meant to be a comprehensive guide, says all the normal caveats apply if you want to dive in and build something based on it, and notes that although he is including all of his design files for reference there are lots of details of the build he probably will not cover.

That last sentence is the important one for an adopter. The files are complete enough to study and to derive a variant from, and the documentation covers the parts he found interesting or tricky, but a builder starting from nothing will hit steps that are not written down. There is also no kit to buy and no bill of materials you can order from directly, since the parts list is a document rather than a shopping list with links.

The project has no GitHub releases, so there is no versioned distribution of the design files, and the repository is not archived with the last push on 2026-05-25. The files are MIT and CC BY-SA 4.0 licensed, and the author accepts donations through Ko-fi, which is the practical answer to the question of who maintains it.

Judged as a document, this is more valuable than most build guides because it records why a designer made each choice and which parts were difficult. Judged as a kit, it is a starting point, and the README says as much.

Editorial conclusion

framedeck suits a maker who wants a specific, opinionated example of what the Framework mainboard can become and is comfortable deriving the rest of the build from the published files rather than from step by step instructions. It does not suit a builder who needs a kit, a wiring diagram that covers every connector or a documented bill of materials they can order from, and the author says so directly about the details he probably will not cover. Verify first that the Framework mainboard documentation and its pinout and CAD resources match the revision you plan to use, and treat docs/parts.md as a starting list rather than a complete one before spending money on a build that needs laser cutting, a custom keyboard PCB and a display.

Frequently asked questions

Official sources

1. brickbots/framedeck on GitHub
2. Issues
3. License: MIT
4. README