Mohammadreza Talebi

Fargah Design OS

A full-screen managed workspace for company computers, bringing assigned applications, projects, teams, permissions, devices, audit, and private AI into one environment.

Explore the project

By Mohammadreza Talebi · 5 min read

Fargah Design OS
Managed workspace — concept visual · Concept visual · not a live screenshot
Year
2026
Role
System design / Engineering
Scope
Windows · Access · Audit
Status
Pilot

The project, in context

Fargah OS, implemented through the Command Center, is a managed company workspace that connects team roles, assigned projects, work logs, controlled files, devices, software licences, and CRM handoff. I designed and engineered the system around who is doing the work, what stage it has reached, and which action that person can take next.

A project needs more than a shared folder.

A request may start with sales, continue through design, require technical detailing, and return for revision before delivery. A folder can hold the files but cannot explain who owns the next step or whether a particular document is final. If team accounts, software access, and project permissions are managed separately, small changes become difficult to follow across the whole company.

The challenge was to make that operational structure visible without placing every administrative control in front of every employee. Designers, detailers, sales staff, and managers need different views of the same project. File access and workflow actions must follow those responsibilities in the server rules as well as in the interface.

Responsibility becomes part of the workspace.

The Command Center provides one navigation system for team, projects, work logs, devices, licences, products, CRM, and audit. A role-permission model determines the visible operations, while project workflow rules govern assignment, design handoff, detail submission, approval, revision, and publication back to CRM. The project is treated as an evolving record rather than a row with an unstructured status label.

Device and software access sit beside the team context. The per-PC agent handles activation and licence state, and administrative actions are recorded. The managed Windows experience is a company work surface, not a replacement for the operating system: its value comes from making work, access, and responsibility understandable in one place.

What I built

The parts that make this project useful in day-to-day work.

  1. Team roles and explicit permissions

    Accounts have defined roles and a permission catalogue. Managers can configure allowed actions, and the server checks permissions on administrative routes. Disabled access and password-change states have their own handling instead of being hidden behind a generic success message.

  2. Project assignment and stage transitions

    The project workflow distinguishes design management, designers, detailers, and executive oversight. Assignment and transition actions include design handoff, finalising design, submitting details, approving, requesting changes, and publishing results to CRM when authorised.

  3. Files with a project context

    Files are attached to the project rather than shared only as loose links. Assignment can control visibility for designers and detailers, and download actions have an audit record. Notes and activity help preserve the reason behind a handoff or revision.

  4. Work logs connected to delivery

    Work logs sit beside project records and team responsibility. Their purpose is to make the progress of assigned work easier to inspect and discuss, while project activity visibility follows role rules. The workspace supports operational reporting without exposing every team's records to every account.

  5. Devices and software licences

    The platform separates the server dashboard from the workstation agent. Licences, activation, device state, and product access can be managed through the same environment. Signed local entitlement and the handling of authoritative denial are documented as part of the access lifecycle, not as a blanket security guarantee.

  6. CRM continuity and an audit trail

    CRM access uses an authorised handoff rather than sharing employee passwords. The recorded release includes one-time SSO with expiry and replay checks. Audit records make administrative changes and relevant project/file actions traceable, giving managers more context when investigating a change.

From structure to release

  1. Map the real handoffs

    I started from the journey between sales, design management, design, and detailing. Each handoff needed a responsible person, relevant files, a clear state, and an allowed next action. That map shaped both the screen structure and the project workflow service.

  2. Apply the same rules on the server

    Interface visibility is backed by permission and project-access checks. Separate actions and route handlers make role boundaries inspectable in the implementation. This was especially important for assignment, approval, files, and CRM handoff.

  3. Treat updates as operational changes

    The documented release process includes an external verified backup, startup health checks, preservation of operational data, and rollback on failed updates. The portfolio describes a pilot workspace with implemented features; it does not imply fresh acceptance on every company device.

Delivery and current scope

  • A .NET management server and bilingual Command Center interface.
  • Team permissions, project stages, files, work logs, and audit records.
  • A workstation agent and software-access lifecycle connected to the management platform.
  • CRM handoff, staged installation/update procedures, backup and rollback documentation.

Questions about this project

Is Fargah OS a new operating system?

It is a managed company workspace implemented through the Command Center and Windows components. Windows remains the underlying operating system; the product organises company work and access above it.

Does every employee see the same projects and files?

Visibility and actions depend on role permissions, assignment, and project workflow rules. The server implementation checks these boundaries as well as adapting the available interface controls.

How does a project move from design to delivery?

Management assigns the project to its designer and detailer. Each role receives the relevant files and available actions. Design, detailing, review, changes and final handoff have separate states, while notes and activity preserve the context of each decision.

Have a similar project in mind?

Tell me what you need to build and where the current experience falls short.

Start a conversation+989304330645
Next projectFargah.ir