Every company has information. Very few have a good way to organize it.
Whether it's onboarding guides, HR policies, technical documentation, meeting notes, or project updates, a company’s data usually ends up scattered across multiple tools or different platforms. Some documents live in Google Drive while others live in Notion, some are buried in Slack conversations, and at times the only person who knows the answer is the colleague who's been there the longest. As organizations grow, finding the right information becomes harder than creating it. That simple observation became the starting point for this project.
Over the past few weeks, I've been working on Atlas, a full-stack enterprise knowledge platform. (The name isn't final yet, but I'll be referring to the project as Atlas throughout this series until I settle on one.) Its aim is to centralize company information, employee management, and organizational knowledge into a single system.
My long term vision is to build a platform where employees can manage documents, organize teams, search organizational knowledge, and eventually interact with an AI assistant that understands information related to the company. This article is the first in a series documenting my entire development journey from the first database table to an AI powered enterprise knowledge platform.
In this first milestone, I focused on building the foundation that everything else will rely on: authentication, employee management, organizational hierarchy, and the relationships between employees, departments, and teams. Before adding AI, I wanted to make sure the underlying system was designed properly.
Why This Project?
I was searching for some good portfolio projects which could solve a real problem while also pushing me to learn technologies beyond basic CRUD applications.
Most of the ideas I found focused on solving one specific problem. I wanted to build something larger that could grow over time while still solving a real-world problem. That's when I started thinking about how organizations actually manage their internal knowledge and structure and about their data being spread across various platforms. This led me to the idea of wanting to build a platform that could bring all of that together.
Therefore, instead of focusing only on document storage, I wanted to create a system that understands how an organization is structured. Employees belong to specific departments, departments contain teams, managers oversee employees, and documents should eventually be connected to those relationships.
This first phase isn't about AI yet. Before introducing any sort of voice controlled actions or conversational features, I wanted to build a solid foundation with a well-designed database, proper relationships, authentication, and employee management. Once those fundamentals are in place, adding AI becomes much more meaningful instead of feeling like an afterthought.
Building the Foundation
Once I had a clear picture in my mind of what I wanted to build, the next step was to choose a technology stack that will help the project to grow over time. Since this isn't just a small application but a long-term project, I wanted every technology to have a clear purpose.
For the frontend, I chose React with Tailwind CSS to build a clean and responsive interface while keeping the components modular and reusable.
The backend is powered by FastAPI. I chose it mainly because of its simplicity, excellent performance, and seamless integration with Python. Since I plan to introduce AI capabilities in the later stages, using Python from the beginning felt like the most practical decision.
For the authentication and database, I chose Supabase with PostgreSQL. Supabase handled user authentication really well while also providing a relational database that made it easy for me to model employees, departments, teams, and their relationships.
Rather than treating the database as just a place to store data, I wanted it to accurately represent the structure of a real organization. Now that meant designing proper relationships between employees, departments, managers, and teams instead of relying on disconnected tables. At this stage, the focus wasn't on adding as many features as possible. It was on making sure the foundation could support everything I wanted to build later. With the technology stack decided, I could finally start building the first version of the platform.
Here's what the current dashboard looks like after implementing authentication and the initial employee management module.
Building the First Version
After deciding the architecture, I started building the first functional version of the platform one module at a time. The first priority was authentication. Before users could interact with any company data, I wanted a secure way for them to create accounts, log in, and access a protected dashboard. Supabase Authentication made this process pretty straightforward and allowed me to focus more on the application's functionality instead of building an authentication system from scratch.
Once authentication was working, I moved on to employee management, which is basically the core of the platform. I built an employee directory where users can view employees, search for specific people, and open individual employee profiles.
The employee directory displays all employees in the organization, with quick access to individual profiles.
Each profile allows administrators to update employee information such as designation, department, reporting manager, and team assignments. I haven’t implemented the permissions system yet, so at the moment anyone can edit employee profiles. That’s something I plan to address once I start working on role-based access control.
Each employee has a dedicated profile where administrators can update departments, managers, and team assignments.
After that, I started designing the organizational structure by creating separate tables for employees, departments, teams, and the relationship between employees and teams. Instead of storing everything in a single table, I wanted the database to reflect how organizations actually work. This made it possible to represent one-to-many relationship, such as managers overseeing employees, as well as many-to-many relationship where an employee can belong to multiple teams. The database design is still evolving as I continue building new features, so I expect it to change as the project grows.
Current database schema showing how employees, departments, and teams are related.
Now these features may seem simple on the surface, but they provide the foundation for everything I plan to build next. Future modules like document management, role-based permissions, organizational search, and AI-powered knowledge retrieval will all depend on these relationships. Building this layer carefully now will make the later stages of the project much easier to extend.
Challenges Along the Way
As expected, not everything worked on the first try. Some of the biggest lessons came from debugging rather than building new features.
One of the first issues I ran into was Supabase Row Level Security (RLS). At one point, departments simply refused to load even though the database contained the correct data. I spent quite a while checking my frontend code, which became really exhausting. I was convinced I had made a mistake somewhere in my React code. I kept going through the same components and queries over and over again because everything looked correct, but the data simply refused to appear. At one point, I was back in Supabase trying to edit the table again when I noticed that Row Level Security (RLS) was enabled. The funny part is that I didn't even know what RLS was at the time, so I ended up Googling it. A few minutes later, I realized it was the very thing preventing my application from reading the data. That experience taught me to look beyond my application code and consider how database permissions can affect the entire system.
Another challenge was designing the relationships between employees, departments, and teams. Modeling real-world organizational structures isn't as straightforward as it first seems. Deciding when to use one-to-many relationship and when to introduce many-to-many tables took a bit of experimentation, and I ended up making several changes to the database schema as the project evolved.
I also came across smaller but equally frustrating issues. One of them involved PostgreSQL rejecting inserts because of a CHECK constraint that I had accidentally configured incorrectly. Another was relying on window.location.reload() after saving changes, which worked but wasn't really the React way of doing things. Refactoring the application to update the UI through state instead of refreshing the page made the overall experience much smoother.
Looking back, I realized these weren't just bugs to fix, they were opportunities for me to better understand how React, FastAPI, PostgreSQL, and Supabase work together in a full-stack application.
Where the Project Stands Today
At the time of writing this article, the project has a working authentication system, an employee directory, employee profiles, department and team management, manager assignments, and a relational database that reflects an organization's basic structure. While there are still plenty of features left to build, the platform has reached a point where the core foundation is finally in place.
In the next phase of development, I will focus on expanding beyond employee management. My plan is to build a centralized knowledge base where organizations can store and organize documents, followed by role-based access control to ensure users only have access to the information they're supposed to see. Once those pieces are in place, I'll begin working on the AI layer of the platform, allowing employees to search company knowledge, ask questions about internal documentation, and interact with an assistant that understands the organization's information.
Finally, I want the assistant to go beyond simply answering questions and actually perform tasks within the platform and eventually I’d also like to introduce voice control to give it a bit of a Jarvis-like experience.
There's still a long way to go, but that's exactly why I'm excited to document the journey. Rather than waiting until the project is "finished," I want to share each stage of the process whether it’s the decisions, the challenges, or everything I learn along the way.
Final Thoughts
This project is still in its early stages, and there's a lot more to build before it becomes the platform I have in mind. Even so, working on this first phase has already taught me a lot about designing databases, building full-stack applications, and solving problems that don't always have obvious solutions.
This is only Part 1 of the journey, and I'll be documenting every milestone as I continue building it, sharing both the successes and the mistakes along the way. If you have any feedback, suggestions, or ideas, I'd genuinely love to hear them. The project is still evolving rapidly, and I'll share the source code publicly once the architecture becomes a little more stable.
Thanks for reading, and I'll see you in Part 2!
Top comments (0)