> ## Documentation Index
> Fetch the complete documentation index at: https://documentation.orbitdev.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Company structure and culture

> Orbit's organization should grow according to actual workload, not according to how impressive a department chart looks. Early-stage work usually requires people to cover multiple responsibilities.

Orbit's organization should grow according to actual workload, not according to how impressive a department chart looks. Early-stage work usually requires people to cover multiple responsibilities. Formal teams should be created when ownership, complexity, and sustained workload justify them.

## 17.1 Functional areas

Possible future areas include:

* **Product and design:** user research, product planning, interaction design, accessibility, and product quality.
* **Engineering:** client applications, backend services, platform infrastructure, integrations, and developer tooling.
* **AI research:** model experiments, training systems, evaluation, and inference.
* **Security and reliability:** application security, infrastructure controls, incident response, and operational readiness.
* **Robotics and hardware:** only if the company commits resources to physical systems and can support the necessary safety expertise.
* **Documentation and developer relations:** technical writing, examples, community support, and API adoption.
* **Business operations:** finance, contracts, hiring, partnerships, and administration.
* **Customer support:** troubleshooting, escalation, service communication, and feedback analysis.

These are possible functions, not claims that these departments or employees currently exist.

## 17.2 Ownership and decision-making

Every production system should have a named owner or clearly assigned responsible role. Changes to authentication, payments, model routing, data retention, and agent permissions should receive review appropriate to their impact.

## 17.3 Engineering culture

A healthy engineering culture values clear issues, small pull requests, reproducible bugs, automated tests, and written decisions. People should be able to challenge assumptions without turning technical disagreement into a contest of status.

## 17.4 Learning and hiring

Hiring should follow the actual needs of the product. AI research, cybersecurity, infrastructure, legal compliance, and robotics all require specialized competence. Ambition can set the direction; it cannot replace expertise.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.