Buildable turns a pile of loose, unsorted LEGO into a set of models you can actually finish — and lets you decide how to spend your bricks.
Most LEGO tools assume your collection is catalogued, tidy, digital. Real bins aren't — they're mixed across years, half-remembered, three childhoods deep. Buildable is built for that bin: spread it out, take one photo, and it shows you what's buildable right now — then allocates the pile so everything you pick comes out complete. Nothing double-booked, nothing dying halfway.
Everyone has the pile. No one has the path.
Every set comes with two things: the bricks, and the booklet that tells you what to do with them. Break the set apart, mix it into the bin, and the booklet is gone forever. What's left is potential with no path.
So the pile sits there. “What can I even make with this?” has no answer — and the worst answer arrives deep into a build, when the piece you need isn't there. The model dies half-finished. Nobody forgets that feeling.
The demand is already proven.
I'm not the first to see this. Brickit — an app that scans a pile, identifies the bricks, and suggests builds — has proven people want exactly this, and earned a real community doing it. Credit where it's due: they cracked the hardest technical part, recognizing bricks from a photo, and made it genuinely fun.
But talking to real builders — and reading Brickit's own reviews — the same three gaps surface again and again:
It's colorblind. It reads shape, not color, so builds come out mismatched and you fix them by hand. (Confirmed by Brickit's own developer; flagged independently in my survey.)
It thinks small. Great for little models; not for ambitious builds.
It breaks trust. Misreads and glitchy results mean you can't fully rely on what it hands you.
The demand is settled. The opportunity is the execution.
What would this look like if the build it gave you was always right, always finishable, and as big as you dared?
The research was sitting in my closet.
I didn't have to look far for a user. Fifteen intact sets, a bin of loose bricks from my own childhood, more mixed in from my brothers. Two decades of LEGO with the instructions long gone. If anyone could tell me where the pain was, it was my own closet.
To test whether this was just my problem, I surveyed the Israeli LEGO collectors' community — a deliberately expert-heavy crowd. Twelve builders responded, most owning 50+ sets. A small, focused sample, and I read it as exactly that: the signal from the serious end of the hobby.
builders keep a chaotic pile of loose bricks — even the most organized collectors.
12 of 12 builders — every single one, even the most organized collectors — keep a chaotic pile of loose bricks, decoupled from its sets.
If even people who catalog their collections live with the pile, the pile is universal. That settled the premise.
The missing-piece heartbreak showed up too. 7 of 12 had started a build and discovered a critical piece missing partway through — and of those, most rated the frustration at the absolute maximum.
When a piece is missing mid-build, how much does it sting?
It doesn't happen daily. But when it happens, it stings — which is the whole case for guaranteeing the finish. You're not preventing a minor annoyance; you're preventing the worst feeling in the hobby.
My users found the gaps before I did.
Before I'd researched the competition, my respondents named its flaws for me. Asked what would make or break an app like this, they kept returning to the same things — unprompted:
“Accuracy — the actual part colors versus the colors in the instructions.”
“If it doesn't really identify the parts, it just wastes my time.”
“Keep it simple and easy — don't make me create an account or hand over personal details.”
Real builders and a shipping product pointing at the same three weaknesses — color, reliability, simplicity — that became the brief.
The research also split my own bin cleanly in two:
Same bin, two mindsets — so the system has to flex: gentle and guided for one, fast and sharp for the other. One engine, different fidelity.
And one practical green light: 10 of 12 said they'd happily spread their bricks out and photograph them for a reliable result. The patient builder will do the work — if the payoff is trustworthy.
Would you spread your bricks out and photograph them for a reliable result?
Guarantee the finish.
Suggesting a build was never the problem — Brickit does that, and does it fun. The problem is that a suggestion has to earn trust: pieces all there, colors that match, a model that finishes. So I defined Buildable around one promise:
Only ever offer a build you can actually finish — right, complete, and as big as you dare.
If the app can't guarantee it, it doesn't make the offer. A builder burned once — by a missing piece or a colorblind result — stops trusting the app entirely.
That promise turned the three gaps into three design targets:
Get it right. Recognize bricks with their color, so the build that comes out matches the build you were promised.
Guarantee the finish. Only offer builds the pile can actually complete — no missing piece at step 80, no substitution guesswork dumped on the user.
Let ambition scale. One big showpiece, or several smaller builds — you choose, and the system budgets the pile so each one completes. Directly answers the “it only thinks small” gap.
One adaptive system. Same engine, different fidelity.
In practice: the same pipeline reads how much help you want. A first-timer gets bigger steps, tighter guidance, and safer builds by default; a collector gets density, speed, and the ambitious end of the catalog. Not two apps — one flow that meets you where you are.
Click through the real thing.
The full Buildable flow — scan a pile, pick a build, follow it brick by brick. Best experienced on desktop.
Six steps from a chaotic pile to builds you can trust — each one designed against a gap real builders named.
Capture
Spread the pile, shoot at an angle. The app guides the photo so recognition works — no sorting required.
The ritual flexes — full guided version for a patient collector, a forgiving “just add a handful” for a kid. 10 of 12 builders said they'd happily do it.
Theme — while it processes
While the app reads your pile, you pick what you're in the mood to make.
Turns unavoidable wait into a real choice — and makes sure you get builds you actually want, not a random duck when you wanted a car.
Identify — in color
Every brick, recognized with its color — then a quick confirm-and-correct pass for the few it's unsure of.
The gap Brickit admits it doesn't solve. Color is the difference between the build you were promised and a mismatched one.
Decide — how many
Now that it knows what you've got, you choose how to spend it: one ambitious build, or several smaller ones.
Brickit thinks small. This is where ambition scales — the choice is the point.
Allocate — the guarantee
The centerpiece — the promise made visible
The system budgets your bricks across every build you picked — so each one finishes. Nothing double-booked. Nothing missing.
The promise made visible. Every offered build is one the pile can actually complete — or it isn't offered.
How the pile gets budgeted.
The system assigns every brick to exactly one build — and only offers builds the pile can actually finish.
Build
Follow the build. Progress all your models together, or one at a time — your call.
The guidance flexes too — gentle and visual for a first-timer, fast and dense for a collector. Same engine, different fidelity.
And the promise is kept — every brick was there, the build finishes.
One adaptive flow, six deliberate steps, each answering something real builders told me was broken.
Coming back.
The flow above is the first-time journey. On return, Buildable opens to a home base — your past builds, a build to resume, and one tap to scan again. No account, no friction: your builds live on your device.
Honest about what's unproven.
Buildable is a concept, not a shipped product. The honest measure isn't downloads — it's whether the thinking holds up. Here's what I trust, and what I don't.
Recognition is the whole ballgame.
Color-accurate recognition is the wedge — and the riskiest assumption in the concept. I designed the honest-uncertainty flow because I don't believe recognition will ever be perfect. It's the first thing I'd stress-test before anything else.
I proved the problem, not the whole audience.
Twelve collectors validated the premise — but that's the expert end. I designed for a kid and a collector, yet mostly heard from collectors. The adaptive mode is my strongest bet and least-tested one. The next round of research belongs to the casual half I barely heard from.
The allocation is elegant — and unproven at scale.
"Budget one pile across complete builds, nothing double-booked" is the idea I'm proudest of. But I validated the desire more than the feasibility. Whether it holds across thousands of messy real inventories is the prototype that comes right after.
What I'd change: cut even more.
Every time I removed something — the nav, an icon, forced sign-in — the concept got stronger. Users didn't ask for more features; they asked for the core to work and stay simple. The hardest discipline here wasn't building the system. It was resisting the urge to make it do more.
Buildable started as "an app that finds builds in your pile." It became sharper: only ever promise a build you can actually finish. If I got one thing right, it's that.