5 Notion databases to Rule Them All: How Lifen organised 1000s of flying pages
Transforming scattered knowledge into structured, searchable assets
At Lifen, we streamline medical data to improve the quality of care and clinical research. With 80% of our tech teams working remotely—distributed across France—effective asynchronous communication isn't optional, it's essential.
Early in our remote journey, we chose Notion as our central knowledge management platform. Its where documentation, decisions, and discussions live. However, like many growing companies, we initially struggled with information sprawl. Our workspace ballooned to over 400,000 pages, making critical information nearly impossible to find.
This article shares how we transformed that chaos into a structured system of five specialised Notion databases that now form the backbone of our remote collaboration.
Our building blocks : Databases, fields and templates
We transformed our chaotic documentation into a streamlined knowledge ecosystem using Notion databases.
Databases
Why databases over pages: Isolated Notion pages quickly become unfindable, while databases offer built-in searchability, visibility, and consistency
Public by default: Unlike standalone pages that are often buried within sub-pages, databases make information discoverable by default
Consistent organisation: Databases create a predictable structure where team members know exactly where to look for specific types of information
Fields
Essential fields only: We limit our fields to the critical few: ID, status, team, author, approvers, and cross-database links
Standardised naming: Consistent field names across databases reduce cognitive load
Structured values: Whenever possible, we use select fields with predefined options rather than free text
Relational power: Cross-database links create a knowledge graph where information flows naturally between contexts
Templates
Reduced friction: Templates lower the barrier to documentation by providing a starting structure
Consistent quality: Predefined sections ensure all critical information is included
Team customisation: Some teams have created specialised templates that better suit their specific needs while maintaining core fields
Continuous refinement: Templates evolve based on feedback and changing requirements
Notion features that prevent database overwhelm
Saved filtered views: We create pre-configured views that show only relevant information—for example, Opportunities filtered by team, status, or quarter
Review reminders: Notion's review feature helps us schedule regular document reviews, ensuring content stays accurate and relevant
Custom sorting: Consistent sorting (by ID, status, or date) makes information predictable and scannable
The combination of these three elements—well-structured databases, thoughtfully designed fields, and flexible templates—creates a system that's both rigid enough to maintain order and flexible enough to adapt to different teams' needs.
Our 5 databases
After experimenting with different approaches, we settled on five core databases that cover the full lifecycle of our work—from knowledge preservation and idea generation to planning, implementation, and progress tracking. Each serves a distinct purpose while interconnecting to create a comprehensive knowledge ecosystem.
Tech Handbooks (THBs) 📒
What they contain: Coding standards, architectural principles, security guidelines, onboarding procedures, and technical best practices.
Why we created them: To establish a single source of truth for all technical knowledge that doesn't change frequently.
How we use them: When a new developer joins, they start by reading relevant handbooks. When discussing architecture, we reference specific THBs rather than recreating explanations.
Example: Our "[THB-42] Component Maintainer Responsibilities" defines ownership rules across our microservices architecture, preventing confusion about who maintains what.
Request For Comments (RFCs) 💬
What they contain: Proposed changes, ideas for consideration, problems needing solutions, and collaborative decision-making discussions.
Why we created them: To provide a lightweight framework for proposing changes before implementation begins.
How we use them: Anyone can create an RFC to suggest improvements. The team discusses asynchronously, and decisions are documented for future reference.
Example: An RFC proposing to reduce pull request sizes led to new guidelines that significantly improved our code review process.
Opportunities (OPPs) 🍀
What they contain: Product and technical initiatives linked directly to company OKRs, with clear ownership and prioritisation.
Why we created them: To bridge the gap between high-level company goals and specific implementation work.
How we use them: During planning cycles, teams select opportunities aligned with OKRs. This database forms the foundation of our roadmap while maintaining team autonomy.
Example: An opportunity to improve our local development environment was directly linked to our OKR of increasing developer productivity, making its business value clear.
Design Notes (DNs) 📚
What they contain: Technical implementation details, architecture decisions, security considerations, and implementation plans for specific features.
Why we created them: To document how a feature will be implemented before coding begins.
How we use them: Engineers write DNs for significant changes, which are reviewed by architects and component maintainers before implementation starts.
Example: A Design Note for our authentication system redesign documented security implications, migration strategy, and technical approach—accelerating both implementation and code review.
Newsletters (NLs) 🗞️
What they contain: Biweekly team updates including recent deployments, operational metrics, retrospective insights, and upcoming objectives.
Why we created them: To maintain cross-team visibility without requiring synchronous meetings.
How we use them: Every two weeks, teams publish updates that are shared in Slack. This creates transparency and keeps everyone informed of progress.
Example: Our frontend team's newsletter highlighting performance improvements prompted the backend team to prioritise complementary API optimisations.
A Journey of Continuous Improvement
Our system didn't appear overnight. Our Notion workspace once contained over 400,000 unstructured pages across all departments. While HR had standardised some practices, the tech side lagged behind. Documents were created without clear ownership or status, becoming unfindable within weeks.
The path to 5 databases
One of our key learnings was finding the balance between too many databases (creating confusion) and too few (resulting in mixed, hard-to-filter information).
It's crucial to separate conceptually different types of content. For example:
Ideation (RFCs) needs separation from implementation design (DNs)
Progress updates (Newsletters) should be distinct from the initiatives themselves (Opportunities)
Each database should have a clear, singular purpose. When information feels like it doesn't quite fit anywhere, that's a signal you might need a new database—not that you should force it into an existing one.
We recommend starting small. Tech Handbooks and Design Notes are excellent first databases because teams quickly see their value. Then gradually expand as you identify gaps in your knowledge architecture.
What We Learned Through Iteration
Limiting database types prevents fragmentation
Clear boundaries between databases guide users to the right place
Standardised field names and values outperform free text
Centralisation and proper linking create a coherent knowledge network
Strict ownership ensures information stays current
Challenges remain. Maintaining these databases demands daily discipline. We constantly balance structure with agility as our needs evolve.
The Concrete Benefits
This structure delivers multiple advantages:
Asynchronous collaboration: Teams work independently without waiting for meetings.
Reduced interruptions: Information is findable without disturbing colleagues.
Transparent decisions: New team members understand not just what we do, but why.
Faster onboarding: New hires quickly access relevant knowledge.
Deep work: Less time spent searching means more time for focused work.
Equal participation: Written communication levels the playing field for all voices.
Leveling Up with AI
There's a common myth that AI can magically find information in thousands of unstructured pages. Reality proves otherwise.
By integrating Dust.tt with our structured Notion databases, we've created specialised AI agents that can accurately retrieve information. The clear statuses and distinct database types allow these agents to differentiate between ideas, implementations, and discontinued projects.
For example, when someone asks about a feature in Slack, adding a specific emoji triggers our Dust.tt agent. It searches our structured databases and provides relevant answers—but only if the information exists in our documentation. This creates a positive feedback loop: better documentation leads to better AI assistance.
Conclusion
Transforming thousands of scattered pages into five powerful Notion databases represents more than an organisational improvement—it's the backbone of how we work. In a world of information overload, our approach enables every team member to find what they need, contribute effectively, and focus on what matters most: building exceptional healthcare technology.
Written by Florent Chenebault
Join the Lifen journey
Our tech culture continuously evolves. We're redefining remote collaboration through structured knowledge management. We're looking for professionals who value writing, thrive in remote environments, and are passionate about healthcare innovation.