Before this project, I had never opened a digital LEGO design tool. Not Stud.io. Not LDraw. Not BrickLink's older design tools. Not any of the third-party alternatives. I had built hundreds of LEGO sets by following printed instructions, and I had designed a few small modifications by hand — holding bricks, testing connections physically, and working from intuition rather than software. The idea of designing a building digitally, brick by brick on a computer screen, was entirely foreign to me.
The IMS Pagoda project changed that calculus immediately. An 11-story building at 1:38 scale with modular floor separation, cantilevered canopy overhangs, angled facades, and interior detail is not something you can prototype by hand. The part count alone would make physical prototyping financially insane — buying thousands of bricks just to test whether a structural connection works, then disassembling and reordering when it does not. Digital design was not optional for this project. It was mandatory.
So I downloaded Stud.io. BrickLink's free design tool. The software that an entire community of MOC builders swears by. And I opened it with absolutely no idea what I was doing.
Stud.io is powerful software. It is also not intuitive for beginners. The interface assumes a baseline familiarity with 3D modeling concepts — camera orbiting, part rotation axes, grid snapping — that I did not have. The first few hours were spent not designing anything, but learning how to navigate the viewport. How to orbit around a model. How to zoom without accidentally moving something. How to select a single brick without selecting the entire assembly.
The part selection system was the next hurdle. Stud.io's part library is enormous — it contains virtually every LEGO element ever produced, organized by category, subcategory, and searchable by number or name. That comprehensiveness is its greatest strength and its biggest barrier for new users. When you know you need "a 2×4 brick," you can find it instantly. When you know you need "some kind of bracket that attaches sideways and has studs on two faces," the search becomes an exercise in vocabulary. You need to know what LEGO calls things before you can find them.
The connection system took the longest to internalize. In physical building, connections are haptic — you feel the stud click into the anti-stud, you feel whether a part is seated correctly. In Stud.io, connections are visual and logical. The software shows you valid connection points, snaps parts into alignment, and highlights conflicts. But reading those visual cues requires learning a new spatial language. I spent entire design sessions placing a part, realizing it was rotated 90 degrees wrong, undoing, re-rotating, placing again, realizing the connection point was one stud off, undoing again. The feedback loop in digital building is slower than physical building until the interface becomes second nature.
The first week with Stud.io was humbling. I have been building LEGO for decades, and suddenly I could not figure out how to place a 1×2 plate where I wanted it. The software makes you earn your fluency.
What eventually broke through the learning curve was repetition. Not tutorials — although I watched several — but the repetitive act of placing hundreds of bricks, one at a time, on the ground floor design. By the time I finished the first floor plate, the basic operations were muscle memory. By the second floor, I was working at a pace that felt productive rather than frustrated. By the fifth floor, I was using keyboard shortcuts I did not remember learning.
The most important thing Stud.io did for this project was not what I expected. I expected the software to be a documentation tool — a way to record designs so I could order parts accurately. That function is valuable, but it is not what changed the project.
What changed the project was the ability to test structural connections digitally before buying a single part. In physical building, testing a structural idea means having the parts on hand. If you do not own the right bracket or the right plate size, you cannot test the connection. You guess, you order, you wait for delivery, you test, and if it fails, you order something else. The iteration cycle is measured in days or weeks.
In Stud.io, the iteration cycle is measured in seconds. I can try a canopy overhang attachment method, test whether the plates have enough overlap for structural integrity, realize the connection is too weak, undo it, try a different bracket arrangement, and have a working solution — all in the time it would take to open a BrickLink order page. The design process went from linear and expensive to iterative and free.
This speed of iteration fundamentally changed how I approached the build. Instead of committing to a design early and working to make it succeed, I could explore multiple design approaches for every problem and choose the best one. The canopy overhang alone went through more than a dozen iterations in Stud.io before I settled on the current approach. In a physical-only workflow, I would have tried two or three options at most before committing to whichever one seemed least bad.
Every image on these pages is a Stud.io render. Not a photograph of a physical model — a digital render produced by Stud.io's built-in rendering engine. The software takes the brick model, applies realistic materials, lighting, and shadows, and produces an image that looks remarkably close to what the finished physical model will look like.
The rendering capability serves two purposes in this project. First, it allows me to evaluate the model's appearance before it exists physically. Does the color balance look right? Do the proportions read correctly from different angles? Does the canopy overhang cast the right shadow pattern? These are questions that can only be answered visually, and Stud.io's renders provide visual answers that are close enough to reality to be useful for design decisions.
Second, the renders serve as the visual documentation for this build series. Sharing the design process requires showing the design, and the renders make that possible at every stage — from early floor plates to fully detailed floor modules. Without Stud.io's rendering engine, this series would be text descriptions of brick arrangements. With it, you can see exactly what I see when I am designing.
The renders are not perfect. Stud.io's rendering engine handles opaque materials well but struggles with transparent elements. Trans-clear bricks render with a degree of refraction and reflection that does not always match how real transparent LEGO elements look under room lighting. The glass facades on the Pagoda model look slightly different in renders than they will look in the physical build. This is a known limitation, and I account for it by mentally discounting the transparent element rendering when evaluating a design.
One of the most practically valuable features of Stud.io is that it uses real BrickLink part numbers. Every brick, plate, slope, bracket, and specialty element in the software corresponds to an actual part that can be ordered from BrickLink's marketplace. The part number in your Stud.io file is the part number you type into BrickLink's search bar when it is time to buy.
This direct connection between design and procurement eliminates an entire category of errors. In a physical-only workflow, you might identify a part by description — "I need a 1×2 plate with a clip on the side" — and then search BrickLink for something matching that description, hoping you find the right one. In Stud.io, the part you place in the design is the part you order. The number is right there. No translation required.
That said, part verification is still essential. As I described in Part 5: The Details, I have encountered situations where part numbers were wrong — fabricated from memory or misidentified from incomplete searches. Stud.io reduces this risk but does not eliminate it. My verification process is to cross-check every part in the final design against BrickLink's listing page, confirming that the part image, dimensions, and available colors match what the design requires. This step catches errors that would otherwise result in wrong parts arriving in the mail.
Building in Stud.io and building with physical bricks are related skills, but they are not the same skill. The differences became clear early in the learning process and have remained consistent throughout the project.
Physical building is tactile and immediate. You feel the connection. You feel the weight. You can flex a structure and immediately know whether it is rigid or fragile. The feedback is instantaneous and multisensory. The frustration in physical building is material — not having the right part, breaking a connection while trying to attach something adjacent, running out of a color mid-wall.
Digital building is visual and precise. You see the connection. You see the alignment. You can rotate the model to any angle and inspect from any distance. The feedback is visual only, which means structural weaknesses are harder to detect intuitively. The frustration in digital building is interface-related — selecting the wrong element, accidentally moving something, losing track of which layer you are working on in a complex multi-floor model.
Stud.io includes a stability analysis tool that partially bridges this gap. The tool evaluates the model's structural integrity and flags elements that are not adequately supported or connected. It is not a physics simulation — it will not tell you if a cantilevered section will sag under gravity over time — but it will tell you if a brick is floating in space or connected by only a single stud when it needs more support. I run the stability check on every floor module before considering it complete. It has caught connection errors that I missed visually more than once.
The other major difference is color accuracy. Stud.io renders colors under idealized lighting conditions with consistent, neutral illumination. Real LEGO bricks look different under different room lighting. The white in Stud.io is a clean, bright white. Real white LEGO bricks under warm incandescent light look slightly cream. Under fluorescent light they can look slightly blue. The difference is subtle but noticeable when you are trying to match colors between the digital design and the physical build. I have learned to trust Stud.io's color representation as a general guide while expecting the physical build to look slightly different in person.
Stud.io's file structure naturally supports the modular approach that this build requires. Each floor of the Pagoda is designed as a separate subassembly within the project. I can work on floor three without floor four loaded. I can render floor seven in isolation to check its proportions. I can export a single floor's part list without including parts from other floors.
This floor-by-floor workflow mirrors how the physical build will be assembled. Each floor is a self-contained module that sits on top of the floor below, connects via a defined interface, and can be removed without disturbing anything else. Designing each floor as a separate subassembly means the digital design process and the physical assembly process follow the same logic. There is no translation step between "how it was designed" and "how it goes together."
The modular approach also makes the design process mentally manageable. An 11-story building with interior detail, exterior facades, canopy overhangs, and structural connections is an overwhelming project when viewed as a single entity. Broken into individual floors, it becomes eleven manageable projects. I can sit down for an evening session and focus entirely on floor five's window spacing without thinking about floor nine's railing attachment. The scope stays contained, the progress stays visible, and the design decisions stay focused.
Stud.io integrates with BrickLink's marketplace, which means the software can estimate the cost of a design based on current part prices. This feature is not precise — prices fluctuate, availability varies by seller, and shipping costs are not included — but it provides a ballpark that is accurate enough to inform design decisions.
Early in the project, cost estimation changed a fundamental design rule. The original floor plate design used 6×24 plates as the primary structural element. The cost estimation showed that 6×24 plates in white were significantly more expensive per-unit than smaller plates — expensive enough that the total floor plate cost was unreasonable at the quantities this build requires. The design rule was changed: no 6×24 plates, always substitute with 6×16 plus 6×8 combinations. The cost per floor dropped substantially, and the structural performance remained identical.
That single design rule change, driven by Stud.io's cost estimation, saved hundreds of dollars across the full build. Without the ability to price-check a design before ordering, I would have discovered the 6×24 plate problem at the checkout page — after the design was finalized and the mental model was built around those parts. Changing the design at that stage would have been far more painful than changing it during the digital design phase when the cost data first became available.
The cost estimation also enables informed trade-offs. When I am choosing between two structural approaches for a connection — say, a Technic-pin-based method versus a bracket-based method — I can check which approach costs less in parts before committing. Sometimes the simpler, cheaper approach is structurally sufficient. Sometimes the more expensive approach is worth the cost for structural reliability. Either way, the decision is informed by data rather than assumption.
If you are picking up Stud.io for the first time for a MOC project, here is what I wish someone had told me before I started.
Start with a small design. Do not open Stud.io for the first time and try to design your dream MOC. Build a 10×10 wall with a window. Build a simple staircase. Build a 2×4 car. Get the basic operations — place, rotate, move, delete, undo — into muscle memory before you attempt anything that requires sustained concentration. I wasted hours fighting the interface on complex design problems that I could have solved in minutes if I had spent the first afternoon on simple exercises.
Learn the keyboard shortcuts early. Stud.io's mouse-only workflow is workable but slow. The keyboard shortcuts for rotation, duplication, and camera control are dramatically faster. Print out the shortcut reference sheet and keep it next to your keyboard for the first week. After that, you will not need it.
Use subassemblies from the start. Even if your project seems simple enough to design as a single file, organize it into subassemblies from the beginning. You will thank yourself later when you need to isolate a section, export a partial part list, or work on one area without accidentally disturbing another. Reorganizing a flat design into subassemblies after the fact is tedious. Starting organized is free.
Verify part numbers before you fall in love with a design. It is possible to place a part in Stud.io that exists in the software library but is extremely rare, discontinued, or only available in colors you do not need. Check BrickLink availability and price for critical parts early in the design process. Discovering that a load-bearing element costs twelve dollars per unit when you need forty of them is a problem best discovered before you build an entire floor around it.
Render early, render often. The working viewport in Stud.io does not look like the rendered output. Colors look different. Proportions read differently without realistic lighting. Render your design periodically as you work — not just when you finish — to catch visual problems that the working viewport hides. A render takes a few minutes. Redesigning a floor because it looked wrong in the first render takes hours.
Save compulsively. Stud.io is generally stable, but crashes happen. Losing an hour of brick placement to an unexpected crash is one of the most demoralizing experiences in digital building. Save after every significant change. Use version numbers in your file names so you can roll back to earlier designs without losing work.
Stud.io is free, powerful, and built for exactly the kind of project I am attempting. It is not easy to learn. But it is worth learning. This project would not exist without it.
The design is in Stud.io. The part numbers are verified. The cost estimates are calculated. What comes next is the part that every LEGO builder lives for — getting real bricks in hand.
In Part 8: The Bulk Buy, I cover my first experience buying bulk LEGO on Facebook Marketplace. The thrill of finding a listing that might contain the parts you need, the reality of hauling home bags of unknown bricks, and the deeply therapeutic process of sorting through thousands of pieces looking for white and light gray — the two colors this build demands by the hundreds.