BrickTracker 1.4 represents a significant evolution in how we track LEGO collections. While previous versions focused exclusively on tracking complete sets, version 1.4 introduces support for individual minifigures and individual parts—loose pieces that exist outside of any specific set. I’ll try and provides a technical deep-dive into the database architecture changes that made this possible, walking through seven designed migrations and the real-world problems they solve.

Why This Feature Matters: The Community Request

This wasn’t just a nice-to-have feature. It was one of the most requested capabilities from the BrickTracker community. Two GitHub issues (#68 and #69) captured the frustration collectors were experiencing.

About a year ago, I released BrickTracker, my selfhosted solution for tracking LEGO collections and missing pieces. Since then, it was featured as a Content Spotlight in the selfh.st newsletter (which was honestly a huge deal for me personally). Thanks to all the feedback and suggestions from this community, I’m excited to share version 1.3, which is a big overhaul!

What’s BrickTracker?

For those who missed the original post: BrickTracker helps you manage your LEGO collection when you have multiple copies of sets, need to track missing/damaged pieces, and want everything stored locally. I built it because I reached 400+ sets and couldn’t find an existing tool that did what I needed. Read more here.

Day 12 was the finale of Advent of Code 2025. The puzzle appeared to be about fitting oddly-shaped presents into regions under Christmas trees - a classic constraint satisfaction problem. But there was a twist.

Part 1: Can They Fit?

Given various present shapes and regions under trees, determine how many regions can fit all their listed presents.

Example shapes:

1
2
3
4

Shape 0:    Shape 4:    Shape 5:
###         ###         ###
##.         #..         .#.
##.         ###         ###

Example regions:

Day 11 was about finding paths through a directed graph. Part 1 was straightforward DFS pathfinding. Part 2 looked like it needed the same approach, but brute force was too slow - the solution required combinatorics and memoization.

Part 1: Count All Paths

Given a graph of devices with directed connections, count all possible paths from you to out.

Example:

1
2
3
4
5
6
7

you: bbb ccc
bbb: ddd eee
ccc: ddd eee fff
ddd: ggg
eee: out
fff: out
ggg: out

Paths: you→bbb→ddd→ggg→out, you→bbb→eee→out, you→ccc→ddd→ggg→out, you→ccc→eee→out, you→ccc→fff→out

Day 10 was a mathematical disguise wrapped in a factory automation problem. What looked like pathfinding turned out to be linear algebra - specifically, systems of equations that need Gaussian elimination to solve efficiently. At least, that’s what I thought until Part 2 humbled me.

The Problem

Factory machines have indicator lights and buttons. Each button toggles specific lights. Find the minimum button presses to configure all machines.

Example input: [.##.] (3) (1,3) (2) (2,3) (0,2) (0,1) {3,5,4,7}

Day 9 was about finding the largest rectangle between red tiles on a theater floor. Part 1 was straightforward geometry. Part 2 required checking if rectangles fit inside a polygon - which is where I reached for an external library.

Part 1: Largest Rectangle Between Any Two Points

Given coordinates of red tiles, find the largest rectangle using any two red tiles as opposite corners.

This is pure geometry: for every pair of points, calculate the rectangle area and track the maximum.