For a while now I’ve been printing stuff almost every week and just… not showing it anywhere. A quick photo, maybe a Discord post, and then it disappears into the void. I wanted a place where I could actually log everything — a running record of what I’ve made, when I made it, and where the model came from. Something that felt like mine.
So I built MattMakes3D.com.
This post is going to get into the weeds on how the whole thing is put together — the stack, the workflow, and why I made the decisions I did. If you just want to see the prints, go click around the site. If you want to know how the sausage is made, keep reading.
The Goal
Simple: a site that shows off what I’m printing week to week, with zero friction to update. I didn’t want to log into a CMS, write a blog post, upload images, fill out metadata, and hit publish every time I finish a print. I wanted to add a row to a database and have the site update itself.
That’s the north star the whole stack is built around.
The Stack
Astro — Static Site Framework
The frontend is built with Astro. If you haven’t used it, Astro is a static site generator that ships zero JavaScript by default — you get HTML, CSS, and only the JS you explicitly opt into. For a content-heavy showcase site, that’s exactly what I want. Fast, lightweight, and no unnecessary runtime overhead.
Astro also has a great component model. I can write .astro components that look a lot like HTML with a little frontmatter at the top for data fetching and logic. The whole site compiles down to static files that get served instantly from the CDN.
One feature I’m using heavily is View Transitions — Astro 4’s built-in page transition system. When you navigate between pages on the site, instead of a hard reload you get a smooth fade. The header and MakerDeck bar persist across navigations so they don’t flash or re-render. It gives the site a much more app-like feel without any client-side routing framework.
Notion — The CMS
Every print on the site lives in a Notion database. Each row is a print, with fields for:
- Title — the name of the model
- Date Printed — when it came off the bed
- Photo — a URL pointing to the image (more on hosting below)
- Model URL — link to MakerWorld, Printables, Thingiverse, etc.
- Model Source — the platform name (shown in the card and lightbox)
- Featured — a checkbox to mark something as a featured make on the homepage
- Status — used to filter the Print Queue panel
There’s no Notion SDK involved. The site talks directly to the Notion REST API using native fetch(). At build time, Astro calls the API, pulls all the print data, and bakes it into the static HTML. The result is a site that reads like a database-driven app but serves like static files.
This setup means I can add a new print from my phone, tablet, or any device that can open Notion — which is all of them.
Vercel — Hosting and Deployment
The site is deployed on Vercel. It’s connected to the GitHub repo, so every push to main triggers a new build and deploy. The whole pipeline — build, optimize, CDN deploy — takes under a minute.
Vercel also exposes Deploy Hooks: unique URLs you can POST to in order to trigger a rebuild without a code push. That’s the key piece that makes the auto-update workflow possible.
Make.com — The Automation Glue
Here’s where it gets fun. Since the site is statically generated, it only reflects what Notion had in it at the time of the last build. If I add a new print to Notion, nothing happens on the site until I trigger a rebuild.
Rather than manually hitting a button every time, I set up a Make.com scenario that watches the Notion database and automatically triggers a Vercel rebuild when anything changes. The scenario runs every 15 minutes, checks for updates in the Notion database, and if it finds any new or modified rows it fires a POST request to the Vercel deploy hook. Combined with a scheduled nightly rebuild at 3am as a backstop, the site stays current with almost no manual effort.
No code. No scripts running on a server. Just a two-step automation that keeps everything in sync.
Image Hosting
Images are hosted running off my DreamHost account. The workflow is simple: I drop photos into a local folder on my computer, Cyberduck watches that folder and automatically syncs new files to DreamHost via FTP. I then paste the URL into the Photo field in Notion.
I went through a few iterations on image hosting. I originally tried using GitHub’s CDN (images uploaded via GitHub Issues), but those URLs use JWT tokens that expire — so images started 404ing after a few days. Not ideal. DreamHost was already in my stack for other things, and the images performance has been solid.
How a New Print Gets Published
Here’s the full flow from print completion to live on the site:
- Print comes off the bed.
- I take a photo and drop it into my local sync folder.
- Cyberduck automatically uploads it to DreamHost CDN.
- I open Notion on my phone and add a new row: title, date, paste the CDN image URL, add the model link and source, check Featured if it deserves the spotlight.
- Make.com detects the new row within 15 minutes and POSTs to the Vercel deploy hook.
- Vercel rebuilds the site, Astro fetches the updated Notion data, the new print appears.
Total hands-on time after the print itself: about 2 minutes.
Site Features
Homepage — Latest Prints
The homepage shows up to two Featured Makes at the top — larger cards I hand-pick for prints I’m most proud of. Below that is a grid of the 12 most recent prints with a “View All Makes” button linking to the full archive.
Lightbox
Clicking any print card opens a lightbox — a full-screen overlay with the full-size photo, print title, date printed, model source, and a direct link to the model. There’s also a Share button: on mobile it triggers the native share sheet, on desktop it copies a direct link to your clipboard. Each lightbox has a unique URL hash (e.g. mattmakes3d.com/#titan-falcon) so you can share a link that opens directly to that print.
Archive — Full Print History
The archive page has every print ever, with two view modes: Grid (same card layout as the homepage) and Timeline (grouped by year and month, great for seeing the progression). There’s also a live search that filters by title or year.
Print Queue
A sidebar panel showing what’s currently queued up or in progress — models I’m planning to print next. It pulls from the same Notion database, just filtered by status.
Design
The design is intentional: dark navy background, amber accents, Bebas Neue for display headings, Barlow for body text, IBM Plex Mono for labels and metadata. It’s supposed to feel like a maker’s workspace — technical but not cold, polished but not corporate.
What’s Next
The site works well for what I need right now, but I’ve got bigger plans.
Open source for makers. The whole codebase is going to be available for other makers to fork and use for their own print showcase. If you’re a 3D printing hobbyist who wants a site like this, you shouldn’t have to build it from scratch. My goal is to make it easy to clone the repo, connect your own Notion database, and have a live site in an afternoon.
MakerDeck integration. Down the line, I’m working on a version of this concept that plugs directly into MakerDeck.net — letting makers upload their prints to a shared platform and automatically cross-post to the MakerDeck Discord. That’s a bigger project and still in the early stages, but it’s where this is all heading.
Final Thoughts
I’ve been wanting to build something like this for a long time. Not a blog with posts, not a social feed, just a clean archive of the things I make. Astro, Notion, Vercel, and Make.com turned out to be a surprisingly tight combination for exactly this kind of project — static performance with dynamic content, all driven by a database I can update from my couch.
If you want to follow along with what’s coming off the bed, MattMakes3D.com is the place. And if you’re a maker who wants to build something similar, stay tuned — the repo is coming.
— Matt