Ever Gauzy: The Operating Context Behind the Feature List
Ever Gauzy is the subject of this series: an open business-management platform from Ever Co. LTD that brings together project work, customer relationships, finance, human resources, recruiting, and time and activity tracking. The focus here is not whether Gauzy has a long list of modules. It is how those modules remain related through a shared operational context—and what that connection lets an organization understand, control, and eventually automate. By the end of this series, a reader should be able to trace a real piece of work through Gauzy and judge both the value of that traceability and the conditions that make it trustworthy.
The problem hidden by a feature list
A feature list tells us what a product contains. It does not tell us what the product means when its parts are used together. Gauzy’s repository names capabilities associated with enterprise resource planning, customer relationship management, human resource management, applicant tracking, project management, sales, invoicing, payments, inventory, reporting, and employee time and activity tracking. Read as separate headings, these capabilities resemble a familiar collection of business applications. The more important question is whether the same people, organizations, projects, and records can cross those boundaries without losing their meaning.
Consider a small consultancy delivering a client project. A new worker may first appear as a candidate, then become an employee assigned to a team. That employee may receive a project task, track time against it, generate activity and timesheet evidence, and contribute to a budget report. The client is not only a contact: the client can be associated with the project, time records, expenses, invoices, and payments. An external GitHub issue may be synchronized into the same project as a Gauzy task. A document can later be linked to the organization’s work and made searchable. This is a hypothetical use of the relationships the repository models, not a claim that every organization must follow this exact process. Its purpose is to show what the relationships are for.
The value appears in the connections. A project manager can ask not only, “How many tasks are open?” but also, “Which work is consuming the project’s budget, who is authorized to see that information, and which external issue explains the change?” A finance user can begin with an invoice item and retain links to the project, task, employee, expense, or product behind it. An employee can have a time-off request or approval policy without creating a second, unrelated identity record. Gauzy’s central promise is therefore less about putting every business activity on one screen than about keeping the relevant context attached as an activity moves through the organization.
That promise also creates a cost. When many domains share records, a decision in one domain can affect another. A wrong organization scope can change a report. A permissive permission path can expose financial or monitoring data. A database or plugin change can affect startup and migrations. The platform’s breadth is useful only if the reader understands these dependencies rather than treating integration as free convenience.
A first mental model of Gauzy
The simplest way to understand Gauzy is to start with identity and scope. The repository distinguishes a tenant or workspace from an organization, an authenticated user from an organization-specific employee record, and a membership from a role. An organization can contain employees, clients, projects, invoices, payments, reports, teams, and other operating records. A user can have default and last organization or team selections, while a separate membership record expresses access to an organization. An employee belongs to an organization and connects that organization-specific role to a user account.
This distinction matters because “the user” is not a sufficient answer to most business questions. The same account may work with more than one organization. A manager may be allowed to see a team’s records while an employee may be limited to their own. A project, time log, invoice, or document needs a tenant and organization context before its content can be interpreted safely. Gauzy carries that context through authenticated requests and uses it in services and guards. Later, the series will examine the mechanism in detail; for now, the important idea is that context is part of the record’s meaning, not decoration added by the interface.
Within that scope, the operating model has several layers. Goals and key results express intent. Projects give that intent a delivery setting, with clients, members, teams, dates, billing choices, and budgets. Tasks and sprints describe work that can be assigned and updated. Time logs and activity records describe what happened, while timesheets and reports turn those observations into reviewable or billable summaries. Contacts, invoices, payments, income, and expenses connect delivery to money. Integrations and documents extend the same context beyond the core records.
These are not interchangeable layers. A goal’s progress is not the same thing as a task’s status. A time log is not the same thing as an activity signal. An invoice total is not proof that a project was profitable. A mapped GitHub issue is not evidence that the imported issue was resolved. Keeping the distinctions visible is essential: shared context should connect records without flattening their different purposes.
The diagram is intentionally compact. It does not claim that Gauzy enforces one mandatory workflow or that every relationship is active in every installation. It shows the questions that make the product coherent: Who is acting? In which organization? For what purpose? What evidence was produced? Which client or financial record is affected? What came from, or can be reused by, an external system or knowledge base?
One core, several ways to arrive at it
The repository separates the shared application core from the shells that deliver it. The web frontend is built with Angular. The API is built with NestJS and supports ordinary HTTP controllers as well as GraphQL infrastructure. The API bootstrap also produces interactive documentation for authenticated and API-key access. The frontend, desktop applications, integrations, automation clients, and external consumers can therefore approach a common set of domain services instead of each implementing its own version of employees, projects, or time records.
Gauzy is also packaged for different operating conditions. A browser-based deployment can place the web interface beside an API and a database. Docker Compose definitions describe a small demo shape and a fuller infrastructure shape with services for caching, object storage, search, analytics, business intelligence, and tracing. The Server desktop application can run a local API and UI around local data, while the Desktop application can operate locally or connect to a remote server or database. A Desktop Timer focuses on time and activity capture. A separate worker can take queue-owning processing, such as document extraction and embedding, away from the API process.
These are not merely distribution preferences. They move responsibility. A local server can be approachable for a small organization, but its operator owns local storage, updates, backups, and access. A centralized deployment can make collaboration and administration easier, but it increases the need for reliable database, network, secrets, monitoring, and recovery practices. A worker can protect API responsiveness for heavy asynchronous work, but it adds another process and a queue contract. The shared model survives across these shapes; the operational burden does not.
Plugins are the other major boundary. The backend plugin contract allows a capability to contribute Nest modules, database entities, event subscribers, configuration, providers, and lifecycle behavior. The frontend plugin system can contribute routes, navigation, tabs, dashboard widgets, page extensions, translations, settings, and lazy-loaded components. This makes it possible for a product feature to be added without placing every controller and screen in the central shell. It also means plugins run inside the application’s trust and dependency boundaries. They are composition, not a security sandbox.
What the shared context can—and cannot—tell us
The repository gives strong evidence about relationships and mechanisms. It shows that a time log can carry employee, project, task, client, and team links; that a project can carry budgets and delivery relationships; that an invoice item can preserve links to work and expenses; that an integration can maintain an external-to-Gauzy mapping; and that permissions and feature flags are part of the request path. These are useful design facts. They let a reader reason about what a deployment can connect and where a control should be tested.
They do not prove that every feature has the same maturity, that every integration is configured, or that a report measures the underlying business reality perfectly. Activity percentages and screenshots are observations with privacy and interpretation risks, not direct measures of value. A duration multiplied by a bill rate is a transparent calculation, but it is not a complete profitability model. A project aligned to a goal has strategic context, but alignment alone does not establish an outcome. A broad README feature list is evidence of intended scope, not an independent assessment of production readiness.
The same restraint applies to security and portability. Gauzy includes authentication, tenant-aware services, role and organization permission checks, soft deletion, request correlation, secret validation, and deployment controls. Yet a repository cannot certify the security of an operator’s configuration. The current code explicitly wires PostgreSQL, MySQL, and SQLite/Better-SQLite3 paths while rejecting MongoDB, even though the high-level README speaks more broadly about database possibilities. Optional monitoring, AI, object storage, queues, and integrations each add their own governance questions.
The practical judgment this series supports is consequently conditional. Gauzy is most interesting when an organization needs a self-hostable, extensible way to keep people, delivery, work evidence, clients, and money in one context. That value is strongest when the organization can define permissions, monitoring rules, retention, backups, database and plugin compatibility, and operational ownership. If those responsibilities are treated as afterthoughts, the same connectedness that makes Gauzy useful can make mistakes travel farther.
The first pressure point is the context carried by a request: how Gauzy decides which user, tenant, organization, employee, role, and feature state a record belongs to. Until that boundary is clear, every later connection—from a task to a timesheet or from an invoice to a project—remains ambiguous. Understanding that context is the foundation for deciding whether Gauzy’s operating story is coherent in practice.