MAX ELMAN

Vibe Coding a 3D Print Build Log from Messy Maker Data

I wanted one clean place to track what I built and printed each month across Printables, MakerWorld, Cults, and local 3MF files. The problem: every source had different data quality, different formats, and different access issues. This project became less about “showing cards on a page” and more about building a reliable data pipeline for personal maker history.

This system was built with Codex GPT-5-3.

Monthly Build Loghttps://maxsanfrancisco.com/monthly-build-log

Backdated Prints Archivehttps://maxsanfrancisco.com/backdated-prints

The Goal

I wanted two pages:

  1. Monthly Build Log
    A curated, visual timeline of finished and in-progress work.
  2. Backdated Prints Archive
    A long historical list merged from old exports and scraped data, with filters and source links.

The core requirement was accuracy: one real project should appear once, even if it showed up in multiple places with different names.

The Hard Parts

1. MakerWorld blocking and metadata mismatch

MakerWorld pages were Cloudflare-protected from server-side fetches, so direct scraping from the host failed. In practice, this meant extracting data locally and importing it into the site data pipeline. Also, MakerWorld “times” were often interaction times (or ambiguous), not always reliable publish dates.

2. Printables “Make” titles were sometimes garbage

A chunk of older Printables makes exported as titles like +1, +4, etc., which are not usable as project names. That required placeholder detection and fallback logic so bad titles didn’t pollute the archive.

3. Duplicate detection is messy in real life

The same project might exist as:

  • A 3MF filename
  • A Printables make
  • A Printables upload
  • A MakerWorld rating
  • A manual entry
    …all with different titles and slight date differences.

What I Built

Every source is normalized into a common entry shape:

  • title
  • timestamp
  • source links
  • merge keys

Then entries are merged by:

  • canonical URL keys
  • source IDs (model/make IDs)
  • normalized title keys (strict + loose)

Loose title logic strips noise words like platform names, “make of,” etc., so obvious matches merge even when titles differ.

Explicit alias and override support

Some duplicates are too human to solve with pure fuzzy logic, so we added manual aliasing and URL-level title overrides for known edge cases. This cleaned up recurring mismatches without risking broad false merges.

Placeholder handling

The log detects and handles placeholder titles (+1, numeric-only, Model #…, etc.).
For MakerWorld unpublished placeholders, it hides those entries entirely in the backdated list.

Better labeling and badges

The script standardized badges and added a Designed rule based on source semantics:

  • Entries from Printables Make are not treated as designed by default.
  • Entries from Printables Upload or explicit authored titles can be treated as designed.
  • We moved Designed placement to improve readability across desktop/mobile layouts.

Filters that are actually useful

Backdated archive now supports filtering by:

  • All
  • Printables
  • MakerWorld
  • Cults
  • 3MF
  • Designed

Counts are integrated directly into the filter controls so the top section is compact and practical.

Mobile cleanup

A lot of effort went into responsive polish:

  • better wrapping for long titles
  • no overflow in hero/filter rows
  • consistent badge placement
  • cleaner hierarchy between date, title, and source badges

Why This Matters

Most personal maker logs fail because data quality collapses over time. This project solved that by treating the build log like a small production system:

  • ingestion from multiple imperfect sources
  • normalization
  • deduplication
  • explicit exceptions
  • UI tuned for real-world readability

The result is a log I can trust and maintain, not just a pretty page.

What’s Next

  • Fill missing titles for older Printables make IDs via targeted enrich passes.
  • Add admin UX improvements for faster manual corrections.
  • Keep expanding the monthly log while auto-merging into the historical archive.

If you’re building in public, this is the real work behind “just keeping a build log”: data cleanup, source trust, and repeatable structure. The UI is the easy part.

Monthly Build Log: https://maxsanfrancisco.com/monthly-build-log

Backdated Prints Archive: https://maxsanfrancisco.com/backdated-prints

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *