Development case study · Product in progress
Isolith: turning a flat floor plan into something you can move through.
Isolith is Social Linker's architectural visualization product currently in development. The product starts from a simple problem: a 2D floor plan communicates dimensions well, but many clients, buyers, and non-specialists struggle to understand what the space will actually feel like.
Problem
Floor plans are precise, but they ask the viewer to mentally reconstruct scale, circulation, and room relationships.
Product idea
Use the plan as the starting point for a navigable 3D experience instead of asking the user to rebuild everything manually.
Direction
The development goal is a clearer spatial communication layer for architects, interior designers, property teams, developers, and clients.
Product thinking
The interface has to make a complex technical process feel obvious.
The product experience has to bridge two very different mental models: the architectural drawing and the spatial model. That means the interface cannot simply expose technical controls and expect the user to understand the pipeline.
The product direction therefore emphasizes a clear source-to-model flow, understandable room and plan context, and a viewer that keeps the 3D result central rather than burying it under configuration.
What this demonstrates
Product positioning
A focused promise: turn a 2D floor plan into an interactive 3D walkable model.
UI/UX systems
A product interface that has to coordinate source material, rooms, model state, and spatial exploration.
Web product development
A browser-based product experience rather than a static concept or presentation mockup.
Brand system
A distinct product identity that can live independently while still being clearly built by Social Linker.
Public development evidence
What the public preview proves — and what it deliberately does not claim.
Isolith is still in development. Its public repository is intentionally a limited browser-only preview rather than a claim that the production system is finished or launched. That boundary is useful evidence because the implementation, privacy limits, validation limits, and private production surface are documented instead of hidden behind a marketing screenshot.
Browser-only preview
The public repository contains a compressed browser deployment artifact and build/server files, not the private production backend or customer data.
Privacy boundary
The published preview documents local floor-plan processing and no fetch, XHR, WebSocket, beacon, or telemetry calls; its external runtime dependency is pinned Three.js 0.169.0.
Validation boundary
The documented 90.13% mean structural F1 comes from a frozen, license-safe synthetic 1,000-plan holdout. It is not a guarantee for every drawing and is not construction-grade CAD/BIM validation.
Production boundary
Authenticated data, server-side conversion, Blender rendering, and provider-backed AI stages remain outside the public preview and are not presented as public-preview capabilities.
Why it matters for client work
We use the same product discipline when we work on someone else's software.
Developing a product means making and revisiting real decisions across product structure, interaction, implementation, testing, and iteration. The navigation has to scale, edge cases have to be handled, the interface has to remain understandable, and implementation details become real. That experience informs our web application development and SaaS development work.