From a Real-World Problem to a Software Project: The Idea Behind Haseen

Every software project should begin with a question worth answering.

Not which framework to use. Not which library to install. Not how the dashboard should look.

But what problem am I trying to solve, and why does it matter?

That question led me to the idea behind Haseen a project focused on identity and access governance.

The Problem: Who Should Have Access to What?

Imagine a company with dozens or hundreds of employees.

Each employee needs access to specific systems, files, and resources to perform their job. An accountant might need access to financial reports, while an HR employee needs access to personnel records.

Now imagine an accountant accidentally having access to confidential HR files, or a former team member retaining permissions they no longer need.

These situations raise important questions:

• Who has access to a particular resource?
• Are those permissions actually necessary for the employee's role?
• How can administrators review and manage permissions without losing track of them?
• What happens when someone needs temporary access to a resource outside their usual responsibilities?

As organizations grow, answering these questions becomes more complicated. Managing permissions is not simply about granting or denying access. It is about maintaining control, visibility, and accountability over time.

That is the problem space I wanted to explore.

Introducing Haseen

Haseen is an in-progress project built around the idea of an identity and access governance dashboard.

The goal is to provide administrators with a structured interface for reviewing employee permissions, understanding access relationships, and managing access requests.

Rather than treating permissions as a collection of disconnected settings, I want Haseen to present them in a way that makes their relationships easier to understand.

The project revolves around three main ideas.

1. Understanding Permissions

Administrators need a clear picture of which employees have which permissions.

A permission matrix can help make this relationship visible by presenting employees, roles, and permissions in a structured format.

A permission tree can provide another way to navigate resources and understand how access is organized.

These are not just visual components. Their design affects how easily someone can identify an unexpected permission or understand the consequences of a change.

2. Managing Access Through Roles

Instead of assigning every permission independently to every employee, a system can use roles to organize access.

For example, an accountant role might include permissions related to financial reports and accounting tools.

Employees assigned to that role receive the permissions associated with it, subject to the system's access rules.

This introduces an important design consideration: roles and permissions have a many-to-many relationship. A role can contain multiple permissions, and the same permission can belong to multiple roles.

Modeling these relationships correctly matters because the interface must represent the underlying data accurately. A visually convincing dashboard is not enough if its data model cannot express the rules it is supposed to manage.

3. Temporary Access Requests

Some employees occasionally need access to resources outside their normal responsibilities.

Giving them permanent access may create unnecessary risk, especially when the requirement is temporary.

Haseen explores the idea of temporary access requests, allowing access to be requested for a limited period.

For example, an employee might need access to a particular resource to complete a short-term task. That access should have a defined expiration rather than remain available indefinitely.

There is an important engineering detail here: temporary access expiration must be enforced by the backend, not merely by a frontend timer.

The interface can display the expiration time and communicate the request's status, but the server must enforce the actual access rules.

This distinction is one of the architectural considerations I want to understand as the project develops.

Why I Chose This Project

I did not want to build another dashboard that only displays charts, cards, and tables.

I wanted a project with a meaningful problem behind its interface, where the design requires more than arranging components on a screen.

Haseen provides an opportunity to explore several engineering challenges:

• Modeling relationships between users, roles, and permissions.
• Designing interfaces for complex data rather than isolated components.
• Managing filtering, searching, and navigation through a large set of records.
• Representing different states of access requests clearly.
• Thinking about security boundaries and the responsibilities of the frontend and backend.

Each of these challenges creates an opportunity to make deliberate design decisions and understand why those decisions matter.

The project also gives me a reason to think beyond individual React components. A component may work correctly in isolation, but it still needs to fit into a consistent data model and a coherent application structure.

Why React and TypeScript?

My current focus is frontend development, particularly React and TypeScript, so I am approaching Haseen primarily from that perspective.

React provides a way to organize the interface into reusable components and manage the relationships between different parts of the UI.

TypeScript adds explicit types that help describe entities such as users, roles, permissions, and access requests. It also makes different states easier to represent clearly.

For example, an access request might be pending, approved, rejected, or expired. Modeling these states deliberately can make the application's behavior easier to reason about than relying on arbitrary strings scattered throughout the codebase.

However, neither React nor TypeScript automatically makes an application secure. Real access control requires backend enforcement, appropriate data handling, and careful authorization checks.

Understanding where the frontend's responsibilities end—and where the backend's responsibilities begin—is part of what makes this project valuable to me.

More Than Building a UI

One of the most important things I want to get out of Haseen is a deeper understanding of software engineering decisions.

Why should relationships between roles and permissions be modeled in a particular way?

Which state belongs in the URL, which belongs in the UI, and which should come from the server?

How should an interface communicate that an operation is pending, has failed, or is no longer allowed?

What should happen when two administrators make conflicting changes?

These questions do not always have one universally correct answer. The right approach depends on the requirements, constraints, and architecture of the system.

Working through them is an important part of moving from writing components that work to designing software that is maintainable and reliable.

Where Haseen Stands Today

Haseen is still a work in progress.

My current priority is building a solid frontend foundation, improving the data modeling, and understanding the architectural decisions behind the interface. I am not presenting it as a completed enterprise access governance platform or a production-ready security product.

Instead, I see it as an opportunity to develop a more disciplined approach to building software around a real problem.

There is still more to explore, particularly around backend authorization, persistence, and enforcing temporary access rules. Those concerns need to be understood and implemented properly before a system of this kind could be trusted with real organizational access.

Final Thoughts

The idea behind Haseen is straightforward: make employee permissions easier to understand, review, and manage.

The engineering challenge is turning that idea into a system whose interface, data model, and access rules work together consistently.

For me, that is what makes the project worth building.

I want Haseen to be more than a portfolio screenshot. I want it to be a project through which I can demonstrate how I approach problems, make technical decisions, and improve my understanding of software engineering.

Because building software is not just about making something work.

It is about understanding what should work, why it should work that way, and what it takes to make it reliable.

---

Haseen (حصين) is an ongoing personal project exploring identity and access governance through React, TypeScript, and software engineering fundamentals.