Liflow was born from a very concrete need: I wanted a sharing tool that was simple, clear, and truly useful in everyday life.
When collaborating with my loved ones or a few people, I constantly found myself juggling between multiple tools: WhatsApp for chatting, Discord for some groups, Google Drive for files, sometimes a calendar on the side… Everything was scattered, hard to find, and rarely thought of as a coherent whole.
I wanted to bring everything together in one place, without unnecessary noise.
A Sharing Application, But Not Like the Others
Liflow is a sharing application based on capsules. Each capsule is independent and contains only the people involved.
In a capsule, you can:
- share notes
- store files and photos
- manage a todo-list
- share events
Always with a simple rule: you only share with those you want.
In practice, this leads to very concrete uses:
- a capsule for a baby registry, shared with the concerned loved ones
- a private capsule to prepare for childbirth and maternity, just the two of you
- a lighter capsule to discuss F1 with a few friends
It's these real uses that guided the development, not the other way around.
The Core Problem I Wanted to Solve
What I wanted to avoid at all costs was the constant switching between tools.
On WhatsApp or Discord, information gets lost quickly in discussions. On Drive, files are there, but without context. And finding specific information often becomes tedious.
With Liflow, all content is structured by capsule and above all searchable: notes, files, events. For me, that's where the real value of the application lies.
UI Inspirations, But No Imposed Model
I drew inspiration from certain interfaces I use daily, in small touches. For example, the user menu deliberately borrows codes similar to Discord.
However, regarding the substance of the application, I didn't follow any existing model. Liflow doesn't try to be a Notion, a Slack, or a classic project manager.
That's probably what makes the app seem "for everyone"... and at the same time very personal.
Too Many Features, Then a Step Back
The first version of Liflow was far too ambitious.
I had multiplied features:
- different types of events
- complex sharing levels
- sometimes gimmicky AI uses, like automatic reminder suggestions
Result: an application harder to understand and use.
With the release of Next.js 16, I made a radical decision: start everything from scratch. Fewer features, a clearer architecture, cleaner code.
This refactoring significantly improved fluidity, performance, and above all the readability of the product.
AI, But Only When It Makes Sense
Today, AI in Liflow has a deliberately limited role:
- summarizing notes
- doing voice transcription
Nothing more.
The goal isn't to impress, but to concretely help, without taking the user's place.
What Liflow Taught Me as a Developer
This project taught me to slow down.
Before coding, I now take more time to think about:
- architecture
- the real usefulness of a feature
- acceptable compromises
Liflow also confirmed something for me: I like building projects from A to Z, even alone, and caring about the details. I'm demanding, sometimes too much, but I prefer taking this time rather than delivering something shaky.
And What's Next
Liflow continues to evolve, but without haste. The idea isn't to always add more, but to keep an application clear, coherent, and pleasant to use over time.
It's both a product I use daily and an experimentation ground that suits me.
Conclusion
Liflow isn't a perfect project, but it's a completed project.
Every feature has a real utility, every choice has been thought through, and the application could very well stay as is for years without losing its meaning.
For me, that's exactly what a good product should be: something simple, reliable, and well enough thought out to last.
This project pretty well summarizes my way of working today: taking the time to think, making clear choices, and building clean, useful, and coherent applications from start to finish.