Documentation-first electronics publishing
Build a hardware learning site that feels like a lab notebook, not a placeholder homepage.
This rebuild turns the app into a static documentation hub for tutorials, blogs, product information, news, and project records. It exports cleanly for GitHub hosting now and keeps the content model portable for a future Django plus React stack.
Publishing blueprint
One site, four content streams, and project-linked artifacts.
Projects act as the anchor pages. Tutorials teach the workflows, product pages explain the hardware, blog posts capture lessons, and news records release moments.
board-dimensions/
code/
data-sheets/
datasheets/
schematics/
Projects
3
Project pages keep generated files, tutorials, and release notes tied to the same hardware slug.
Content types
4
Tutorials, products, blog posts, and news pages are all generated from the same content model.
Hosting model
Static
Next.js exports a plain site for GitHub hosting, so there is no backend cost or runtime dependency today.
Artifact buckets
5
Generated files can land in predictable folders without changing the route structure.
Project-centered structure
Each hardware effort gets a permanent home
Project pages are the connective tissue between generated assets and the editorial content that teaches people how the hardware works.
Mechanical validation
Enviro Beacon Node
A sensor board focused on low-power logging, enclosure fit checks, and stable radio behavior across revisions.
Tracks enclosure, antenna, and battery fit decisions across revisions.
Reserves generated folders for diagrams, code, schematics, and vendor PDFs.
Acts as the anchor point for tutorials, product notes, and news posts.
Rev B bring-up
Portable Power Monitor
A compact board that captures rail behavior, battery discharge, and inrush current without needing the entire lab bench.
Captures voltage, current, and accumulated energy during field tests.
Pairs firmware drops with schematics and board outlines in predictable folders.
Makes tutorial and blog content discoverable from the project itself.
Published reference design
USB PD Type-C Breakout
A compact USB Type-C Power Delivery breakout board with selectable voltages, publishable board files, and vendor reference documents.
Publishes schematics, board dimensions, and vendor datasheets from the hardware repo.
Uses a reusable workflow hosted by the learn site repository.
Keeps the project ready for richer editorial content later.
Content streams
The site is organized like a teaching platform
This layout borrows the best parts of hardware education sites: browsable sections, practical content, and strong links back to the project that generated the knowledge.
Tutorials
Tutorials and lab procedures
Practical guides for board bring-up, publishing artifacts, and building repeatable engineering workflows.
2 starter pages
Products
Product information and support docs
Reference pages that explain what a board is for, how it fits into a project, and where its supporting files live.
2 starter pages
Blog
Blog posts from the workbench
Narrative write-ups about design decisions, revision lessons, and the tradeoffs behind each hardware project.
2 starter pages
News
News and release updates
Short announcements covering site changes, artifact pipeline milestones, and hardware release checkpoints.
2 starter pages
Featured content
Start with the pages that define the workflow
These entries establish the tone of the site: teach the process, expose the supporting files, and keep the project context nearby.
Documentation site rebuild starts with a static-first release
The new site structure is live as a static export so content can ship immediately on GitHub while the long-term Django plan takes shape.
A repeatable bring-up checklist for fresh PCBs
Turn first power-on into a documented process instead of a one-off scramble with loose bench notes.
Publishing generated hardware files into the docs site
Set up a simple convention so another repository can push schematics, code, and dimension exports without changing the frontend.
Why every board revision needs a permanent logbook
A project without a durable record becomes impossible to debug six months later, especially once the revision names start to blur together.
Automation handoff
Reserve the artifact paths now so other repositories can publish into them later
The frontend already knows the bucket names. A GitHub Actions workflow in another repository only needs to copy generated files into the matching project slug.
Board dimensions
Mechanical exports, keep-outs, and enclosure references.
public/generated/<project-slug>/board-dimensions/
Code
Firmware releases, examples, and support scripts.
public/generated/<project-slug>/code/
Data sheets
Vendor documents mirrored with the dash-separated naming used upstream.
public/generated/<project-slug>/data-sheets/
Datasheets
Compatibility bucket for generated exports that omit the dash.
public/generated/<project-slug>/datasheets/
Schematics
Rendered PDFs, source snapshots, and revision notes.
public/generated/<project-slug>/schematics/
Why static first works
You asked for a site that feels closer to Adafruit Learn or SparkFun documentation than a blank app shell. The right first step is a static structure with strong content types and zero backend complexity.
When you are ready for Django, the presentation layer can change without rethinking the taxonomy: projects stay projects, tutorials stay tutorials, and generated artifacts still belong to the same project slugs.
Latest news
Documentation site rebuild starts with a static-first release
The new site structure is live as a static export so content can ship immediately on GitHub while the long-term Django plan takes shape.
Generated artifact folders are reserved for automation
Project pages now expose stable target paths for schematics, firmware bundles, and mechanical exports published by other repositories.