
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.

