Volograms

01

The idea

The goal was to make full-body 3D reconstruction available to everyday users.

A user could record a video of themselves or someone else. The video would be processed into an animated 3D model, which they could then use to make new content. The planned process was simple:

Create a model → create a video → share it → inspire others to create.

The product was open-ended. We didn't define one use case. The idea was for people, especially content creators, to find their own ways to use the technology.

When I joined, the 3D reconstruction backend was already working. There was also an early prototype and designs from an external agency. My role was to turn these parts into a complete mobile product.

02

From technology to product

The product had to work on iOS and Android and connect to a backend and a 3D/AR rendering engine. So first, we had to decide how to build it.

I looked at the main options with the team, including building separate native apps and using a cross-platform approach. I was the main mobile engineer and already knew Flutter, so we chose Flutter. It let us use one codebase while still supporting platform-specific features when needed.

I tested the approach with an MVP that brought together three main parts:

• Flutter — UI, navigation, state, and application logic
• Native iOS/Android — connection to the platform-specific AWS Amplify libraries
• Unity — 3D rendering and augmented reality

The architecture kept these parts separate while letting them work together in one app.

03

Building the app

I designed and built the mobile architecture so the app, backend, and rendering layers were separate.

Flutter handled the UI, state management, navigation, and application logic. I followed a Cubit-based structure to separate views, view state, and controllers. Backend features were in independent modules, not tied directly to the UI.

The backend brought another challenge. At the time, AWS Amplify had separate native libraries for iOS and Android. I built the native bridge between those APIs and Dart, giving the Flutter app one consistent API to use.

The app also used Firebase Crashlytics and supported notifications.

Some of the third-party tools were still new. AWS Amplify had bugs and limits, and the Flutter/Unity integration package was rough and had little documentation. I worked around these problems while keeping the app's architecture easy to maintain.

As the main mobile engineer, I was responsible for most of the app's decisions and implementation. I worked closely with the backend/3D team and with another engineer on the Unity integration.

04

Turning designs into a product

The agency had set the visual style and provided several screens, but the designs didn't always say how the product should work.

I worked with the CEO to turn the visual style into a reusable Flutter UI system. I made interaction decisions and extended the original style as we added features.

Using Flutter's Material components as a starting point, I built and adapted reusable buttons, text inputs, cards, typography, and shared colour definitions.

This gave the app a base we could use as it grew. New screens and features could look consistent without us having to solve the same UI problems again.

The work wasn't just about copying static designs. I turned an incomplete design specification into a working product, balancing the original style with technical limits and feedback from people using the app.

05

The AR experience

The 3D model was at the centre of the experience.

The app showed previously created models as animated previews. Selecting one opened the Unity-powered AR experience, where users could see the model through the camera and place it in the space around them.

From there, they could:

Place and resize the model → apply visual effects → record the experience → share the resulting video.

Unity ran as a native view inside the Flutter app. I worked with another engineer to connect the rendering layer to the rest of the app. We kept the Unity experience separate from the main Flutter UI and app logic.

This was one of the more unusual technical parts of the project. It meant connecting technologies that weren't made to work together.

07

What I learned

Volu succeeded technically: it showed that 3D reconstruction, Flutter, native mobile development, backend services, and AR could work together in a real consumer product.

The bigger challenge was showing that people had enough reason to use the technology and eventually pay for the product.

Looking back, I think we tested the technology more than we tested the product.

The app first focused on attracting users and getting feedback, but making money became a challenge. The team tried other commercial uses, including the video-card product, but the main question remained: who had a strong enough reason to use and pay for this technology?

Looking back, I would have done a few things differently:

• done more user and market research before committing heavily to the product;
• thought about making money from the beginning, instead of focusing mostly on getting users;
• run more small tests of different uses before building the full product.

For me, Volu taught me that making ambitious software work is only half the problem. People also need to understand its value and have a real need for it.