Why we shipped 3D before we knew anyone wanted it

Why we shipped 3D before we knew anyone wanted it

A telecom customer asked us a simple question one afternoon: “Could I just see the IFC on my phone, on site?” We didn’t have a confident answer, a roadmap slide, or a market-sizing deck. What we had was a question from a real user and a decision to make — guess at whether it mattered, or build a small, real version and find out. This is the honest story of why we shipped 3D before we knew anyone wanted it, and what that taught us about building in public.

The question we couldn’t answer from a spreadsheet

You can analyse a feature to death. We could have surveyed users, modelled demand, debated internally for a quarter about whether “3D on site” was a real need or a shiny distraction. But every one of those paths is a way of guessing — dressed up as rigour. The only thing that actually answers “do people want this?” is putting a real version in front of real people and watching what they do. The spreadsheet can’t tell you; the slab can.

Why we shipped instead of studying

So we made a call that feels reckless written down and felt obvious in the room: build a lightweight 3D viewer with pinning, ship it, and let real usage settle the question. Not a prototype in a drawer — a real, bounded feature people could actually use on site. The bet wasn’t “3D will definitely be huge.” The bet was “we’ll learn more in two weeks of real use than in two months of speculation.” That’s demand-driven development: ship a genuine but modest version, then let demand — not opinion — tell you what to do next.

What “a real but bounded version” actually meant

Shipping fast only works if you’re honest about scope. We didn’t build a coordination platform or pretend to. We built exactly enough: upload an IFC, get a lightweight 3D model that opens on a phone, drop pins on it with a photo or a voice note. Bounded on purpose. The discipline wasn’t in how much we built; it was in refusing to build — or claim — the parts we hadn’t earned yet. A small thing that’s completely honest beats a big thing that overpromises.

Keeping the claim modest on purpose

Here’s the part that matters most, and it’s a product decision, not a disclaimer. We were strict, from day one, about what the 3D feature is and isn’t. A pin is anchored to a point in 3D space — not a BIM element. It does not read element IDs or properties, does not version the model, and is not BIM coordination, a CDE, or a replacement for Revit. It’s a dated snapshot of the model for field documentation — a first, honest step into 3D on site. We could have used bigger words. We didn’t, because the bigger words would have been a lie, and a lie is a terrible foundation for a product you want people to trust.

What real usage actually told us

Then we watched. Who opened a model on site, and what did they do with it? Did the pins get used, or did the feature sit untouched? Real behaviour is unsentimental in a way that surveys never are — people don’t use a thing to be polite. Watching actual use let us see the shape of the real need instead of the imagined one, and decide where to invest next from evidence rather than hope. (The mechanics of how it works are in pins on 3D models: documenting an IFC from your phone, and the coordinator’s-eye view is in how a BIM coordinator reviews a 3D model from a phone.)

The lesson: gate development on demand, not certainty

You almost never get certainty before you build — and waiting for it usually means building the wrong thing slowly. The alternative isn’t recklessness; it’s shipping a real, bounded, honestly-scoped version and letting demand gate what comes next. Ship to learn, keep the claim modest, watch what people actually do, then decide. It’s slower than a grand plan on paper and faster than a grand plan in reality.

Why we tell this story out loud

Building in public means saying “we weren’t sure, so we tested it” instead of pretending we always knew. That honesty isn’t a weakness in the story — it’s the whole point. The teams we want to use PinMy are the ones who can smell an overclaim from across the site, and the way you earn their trust is by being straight about how the thing actually came to be. We shipped 3D to find out. That’s it. And being able to say that plainly is worth more than a tidier story would be.

FAQ

Did PinMy build 3D because of proven demand? No — we built a real but bounded 3D viewer to test demand, after a telecom customer asked if they could see an IFC on their phone. We shipped to learn rather than waiting for certainty.

Is the 3D feature full BIM coordination? No. A pin marks a point in 3D space, not a BIM element; it doesn’t read element data or version the model. It’s a dated snapshot for field documentation — a first step into 3D on site, not BIM coordination or a CDE.

What is demand-driven development? Shipping a genuine but modest version of a feature, then letting real usage — not internal opinion — decide whether and how to invest further. You learn from behaviour instead of guessing from a spreadsheet.

What PinMy is NOT

Even as an origin story, the boundary holds: the 3D feature is not BIM coordination, not a common data environment, and not a Revit replacement. A pin marks a point in space — a dated snapshot — not a model element, and it doesn’t read element data or version models. The web PDF report is useful but still maturing, and pricing lives only on the pricing page. What PinMy did was ship something real and modest to learn from, and say so plainly.

See what we shipped

Open an IFC on a phone and judge the modest version for yourself.

• See how it works: pinmy.co
• Book a 15-minute demo: tidycal.com/pinmy