Designing the front door to AI hardware creation

BuilderLab started with a difficult idea: describe any hardware idea and turn it into something that can be manufactured. When I joined, the prototype showed where the product was headed, but the frontend was not ready. The interface was complicated, some controls were broken, and expensive visual choices made the first experience slower than it needed to be.

The hero made the tradeoff obvious. Its large interactive 3D model looked impressive, but it put the browser to work before students knew what BuilderLab did or why it mattered. The landing page led with the technology instead of explaining the product.

My responsibility was to lead frontend development across the landing page and chat experience while the rest of the team concentrated on the generation and manufacturing workflow behind them.

BuilderLab is designed for students whose ideas may be further along than their engineering vocabulary. The interface could not feel like enterprise manufacturing software or expect students to understand the system before getting started.

I rebuilt the landing page with a clearer hierarchy and a more direct way into the product. The design stays dark, bold, and product-led, but avoids the dense dashboards and generic corporate look common to technical platforms. Advanced hardware creation should feel serious without feeling out of reach.

An open-ended chatbot would have handed the hardest part of the interaction back to the student. Someone may know they want to build a drone, enclosure, or robotic device without knowing how to describe its configuration, proportions, defining features, or manufacturing constraints in one complete request.

I designed the chat interface around structured tool calls. BuilderLab asks one focused question, presents concrete options, and leaves room for a custom answer. Each response informs the next step, so the conversation clarifies the idea piece by piece instead of repeating known information or hiding the requirements inside a technical form.

The interaction was as much an architecture problem as a visual one. The frontend had to preserve conversation context, render questions and system states as distinct parts of one transcript, and show progress clearly while the backend decided what to ask next. That kept the experience conversational. An unstructured exchange on its own was still not enough to produce a manufacturable result.

BuilderLab combines interactive 3D content with compute-intensive generation, so performance directly shapes the product experience. A visually impressive feature still failed if it delayed the first useful interaction, competed with scrolling, or consumed resources without helping the student make a decision.

The team made a deliberate product decision to support laptops and larger devices rather than dilute the core 3D workflow for phones. Limiting the scope to those devices did not remove the need for responsive work. The interface still had to behave across different laptop screens, browser dimensions, and input conditions.

We have not completed formal performance measurement, so I cannot claim a percentage improvement yet. For now, the change is in our process: we consider asset weight, rendering cost, scroll ownership, and device capability during design instead of waiting until the end.

Several early pull requests were rejected because I had designed and tested too narrowly. One iteration added a second scrollbar to the chat experience; others broke down across the range of devices we still intended to support. Together, those failures showed that the problem was in my process, not one isolated CSS issue.

I started treating responsive behavior, scrolling, and complete-page interaction as part of the implementation from the start. A component was no longer finished just because it looked right in one viewport or worked on its own. It had to hold up in the environment where people would actually use the product.

BuilderLab is now a functional, production-bound prototype approaching its first deployment. It has not been validated with external users yet, and there are no launch or performance metrics to claim. My next milestone is to help turn the current frontend into a stable V1, then use real usage and performance evidence to decide what needs to change after launch.