Muxcard: a credit-card sized computer built on an ESP32-C3

The thickness target, not the footprint, is the hard constraint

Plenty of devices are called credit-card sized while being obviously larger than a card. Muxcard starts from the opposite direction. The author wanted a smartcard with a display that is the size of a real credit card, including the actual thickness, and the target for the total build was around one millimetre.

For context on that number, official ISO7816 smartcards are specified at 0.76mm, and many real-world cards slightly exceed that in practice. So the project is deliberately thinner than a stack of real cards, and the image in the repository makes the point by showing the frame of the device carved from an actual NFC card.

The stated motivation is a fascination with extreme space constraints, and the thesis is that shaving millimetres is what separates this from a tracker shaped like a card. The prototype described in the repository is a functioning unit rather than a render, running without external power and with no electronics hidden outside the card body.

That constraint also explains the engineering choices later on. When your budget is one millimetre, the display, the battery, the antenna and the interconnects are all competing for the same stack, and every decision that saves a fraction of a millimetre has to be won back somewhere else.

ESP32-C3, e-paper and NFC, with firmware and hardware split in the repository

The component set is stated plainly at the top of the project: an ESP32-C3, an e-paper display and NFC. The ESP32-C3 is the microcontroller, the e-paper display gives the card a visual surface without a power-hungry backlight, and the NFC part handles both the contactless side of the smartcard identity and the ability for a phone to interact with the card.

The repository itself is thin, with three top-level entries beyond the usual files. There is a firmware directory, a hardware directory, and a LICENSE file. That split tells you the project is a hardware-first effort with the device design and the device code kept apart, which is the arrangement you want if you intend to iterate on the physical stack without touching the code, or the other way around.

The public description calls the result a fully working computer that is literally the size of a credit card, and the README shows a short visual demo covering a few of the things that could be possible. The project is not archived and the last push was on 2026-05-11, so the tree is a snapshot of a prototype in progress rather than a released product.

Etching the flex PCB on a 3D printer, by UV exposure

The manufacturing story is unusual and it is the part with real transferable value. The author was too impatient to wait for a fab to produce a flex PCB, given weeks of customs delays and the risk of receiving a board that did not work, so the first boards were made at home.

The method is lithography, the same basic process a fab uses, performed with a 3D printer. The finding worth keeping is that a 3D printer works surprisingly well as a lithography machine, reaching a detail level that CNC cannot. The obstacle was exporting a copper layer in a form the printer would accept, which the author solved with UVTools, a piece of software that includes tools aimed specifically at PCB lithography.

The substrate was ordinary kapton tape with copper foil laminated on top, covered by a thin photoresist layer. Getting there meant many attempts at stackup, chemical concentrations, curing times and developing times, with the author describing the first results as a reconsideration of their motivation. The final result matched the detail level of most default professional PCBs.

Two shortcuts are worth knowing about. There were no vias and no solder mask, so the board is single layer, which required workarounds. And a one-use stencil was made from stacked photoresist film, which handled solder paste well enough that hand-applying it was not needed.

Thin copper traces tear, so longer nets get more turns

The DIY board has a failure mode that a factory flex PCB does not have in the same form. Thin copper traces adhere to the tape surprisingly well, but they rip apart easily when bent, and the traces on this board are exactly the thin, long kind.

The fix was not better material but geometry. More turns were added to longer nets so the strain gets distributed instead of accumulating in one place across a single long run. That is a routing-level workaround.

The prototype also taught a lesson about CAD versus physical assembly. Connecting parts, leaving bending buffer, choosing bonding material and tolerating real-world variation all had to be worked out in the physical world rather than on screen, and the author's own conclusion is that the first handmade unit feels as if it would break from being handled roughly, even though it functions well technically.

If you plan to build one, that is the part to budget time for. The electrical design is not the obstacle. Stacking, bonding and mechanical survival at one millimetre is.

V0.1 is a placeholder build, and the README says so

The repository is candid about the state of the hardware. Much of V0.1 is described as a placeholder, with a list of what that means in practice.

Many parts are hand-built and fragile. The rigid version of the display was used rather than the flexible one, partly because flexible displays are not very available. The battery is intentionally undersized for debugging, with 58mAh and 70mAh versions named as candidate cells that would fit. And the assembly, in the author's phrase, currently resembles a tiny crime scene.

That last point is the honest summary of the whole project. The concept works, which is the achievement, but the object is not a consumer product. The README frames the first prototype as a proof of concept whose purpose was to find out what the real challenges are beyond component height, and the author says the progress since then has reached professionally manufactured prototypes.

The important part is listed as the core concept working: no external power, no hidden electronics outside the card, and no elements that violate the thickness rule. If you are evaluating this project, judge it on that claim and not on the appearance of the prototype.

The use cases are a wish list, and the launch is a mailing list

The README lists ideas, and it is important not to read them as shipped features. The suggestions are a minimalist wallet for QR codes, NFC keys, tickets and boarding passes, a smart-home dashboard and control, an offline store for passwords, 2FA and a crypto wallet, and a business card that is memorable. It also names pentesting and ethical hacking in the mould of Flipper Zero, alongside hardware hacking generally.

The video demo shows a few of the things that could be possible rather than a finished interface, and the project summary uses the same hedged wording. So the honest reading is that the hardware is a platform and the software surface is still being designed.

That is also why there is no purchase path. The author plans to launch the project soon, and the way to follow is a sign-up form at muxcard.com, plus accounts on Instagram and X. The repository has no GitHub releases, no tagged versions and no install instructions, and the visible README gives no firmware build instructions, which means there is no documented way to flash a device from what is described here.

For an engineer, the reasonable entry point is the hardware tree and the fabrication write-up, not the feature list.

A custom licence and no release history to plan upgrades against

Two facts shape what you can do with this repository.

First, licensing. The licence is recorded as a custom licence that GitHub cannot classify, with the terms in the LICENSE file at the repository root. When a licence is bespoke, the only useful source is the text itself, so read LICENSE before reusing the hardware design, the firmware or the board files. Hardware licences often carve out manufacturing rights separately from the code, and a bespoke text can do things a standard SPDX identifier would not. Nothing here is legal advice, and the file in the repository is what settles the question.

Second, maintenance. The last push was on 2026-05-11, the repository is not archived, and there are no GitHub releases and no tagged versions. There is therefore no upgrade path to speak of, no changelog to diff, and no compatibility promise between revisions of the design.

The practical consequence is that adopting Muxcard means adopting a snapshot. If you want the concept rather than the device, the parts most worth taking are the fabrication method and the honest account of what the physical constraints cost. If you want the device, the wait is for a launch whose date, price and firmware are all still unstated.

Editorial conclusion

Study Muxcard if you care about extreme packaging, since the honest engineering write-up of a flex PCB etched on a 3D printer is worth more than the device itself. Do not buy, build or expect a product from it, because the firmware tree and hardware tree are published while the manufacturing path, the firmware features and the launch date are not. Verify three things first: that the firmware and hardware directories contain what the README claims, that the custom LICENSE file in the repository root allows your intended reuse, and that the last push was on 2026-05-11 with no GitHub releases published.

Frequently asked questions

Official sources

1. Issues
2. krauseler/muxcard on GitHub
3. Project website
4. README