Contact

LiBlul — Owner · Full Stack Developer

LiBlul — a 360° virtual tour platform

A platform where creating a 360° virtual tour became simple — visual editor, one-link sharing

In brief

Problem

A visual editor simple enough for non-technical users, performant delivery of heavy panoramas, and infrastructure that absorbs peaks.

Intervention

A full-stack SaaS platform — editor, optimisation pipeline at import, self-managed hosting.

Outcome

An online platform that lets anyone create and publish virtual tours without technical skills.

Context

360° virtual tours remain costly to produce and publish. LiBlul aims to make creating them accessible: import panoramas, compose a tour, share it.

Problem

Building such a platform means holding three topics at once: a visual editor simple enough for non-technical users, performant delivery of heavy panoramas, and a service that absorbs visitor peaks without costing a fortune.

Constraints

  • Non-technical end users: the editor must be understood without documentation.
  • Heavy panoramas: load time directly conditions conversion.
  • User data to protect (accounts, private content).

Solution

Iterate on the editor with real usage, keep the foundation simple while everything holds, and measure what matters: tours created, tours viewed, load time.

Outcome

An online platform that lets anyone create and publish virtual tours without technical skills.

What this project demonstrates

Designing a complete product — from the editor to the accounts, delivery included — and driving it from concept to operations.

Under the hood

Stack, architecture decisions — the technical detail behind the outcome.

My role

Owner and full-stack developer: product, UX, development, infrastructure and monitoring.

Architecture

  • Full-stack application: Angular client, server-side API.
  • Panorama optimisation pipeline (adapted to screens and networks).
  • Self-managed hosting, monitoring and automated backups.

Key decisions

  • Optimise at import, not at view time: smoothness is paid for once, at import — not on every view.
  • Deliberate but bounded nodal editor: composing a tour stays visual, without exposing technical complexity.
  • Owned infrastructure: the same cost/control trade-off as the other projects, with product-level monitoring.

Challenges

The image-quality versus file-weight compromise: a tour that loads poorly does not convert. The second challenge is the product itself: defining what makes an editor “simple” (fewer options? better defaults? better flows?).

Making complex content accessible? Let’s talk about your project.

Architecture decisions

  • Optimise at import, not at view time

    Why : Panoramas are heavy and load time directly conditions conversion.

    Consequence : Smoothness is paid for once, at import — not on every view.

  • Deliberate but bounded nodal editor

    Why : Non-technical users must use the editor without documentation.

    Consequence : Composing a tour stays visual, without exposing technical complexity.

  • Owned infrastructure

    Why : Absorb peaks without costing a fortune.

    Consequence : Product-level monitoring and automated backups.

All case studies