Autaria - Full-Stack CRM & Agent-Assisted Engineering by Fedor DorodnovAutaria - Full-Stack CRM & Agent-Assisted Engineering by Fedor Dorodnov

Autaria - Full-Stack CRM & Agent-Assisted Engineering

Fedor Dorodnov

Fedor Dorodnov

Architecture illustration: a shared FastAPI backend supports the CRM, client portal and separate Master demo.
Architecture illustration: a shared FastAPI backend supports the CRM, client portal and separate Master demo.
Autaria is an automotive service system connecting customers, vehicles, orders, images and technical manuals through shared data. It includes a FastAPI backend, a SvelteKit CRM, an Astro client portal and a separate Vue-based Master demo.
I developed the system with AI agents and structured its architecture: domain boundaries, shared API contracts, the data model, interfaces and file processing. I also designed the context agents work within, so a change to a form, service or model remains connected to the surrounding layers.

Turning the Domain into an Application Structure

The CRM preserves the relationships between customers, vehicles and orders: whose vehicle is being serviced, which customer an order belongs to, and which items and images are attached. The customer page loads related vehicles and orders. Order creation selects a customer and vehicle, and the backend checks both entities within the current tenant.
HTTP handlers, business services, DTOs, repositories and storage adapters have separate responsibilities. Pages use domain-specific API adapters. Shared packages provide transport, authentication, uploads, realtime and basic UI, while complex CRM components remain in Svelte. Sharing packages does not imply that every application has the same features.

Tenant Boundaries and Data Ownership

In the main business routes, the requested tenant is checked against the JWT before PostgreSQL receives the context used by Row-Level Security. Order relationships with customers and vehicles also include the tenant in database constraints. Data ownership is therefore checked beyond the interface.
PostgreSQL mechanisms maintain order totals when items change. The calculation has one owner, and the interfaces consume the shared result. Authentication and system routes have their own rules; RLS is not presented as a universal policy for every endpoint.
Selected domain relationships: order items and images belong to orders; technical manuals are linked to vehicles.
Selected domain relationships: order items and images belong to orders; technical manuals are linked to vehicles.

Order Images and Technical PDFs

I separated two file workflows. Images belong to an order, while technical manuals are linked to a vehicle. A manual is not an automatically generated order report.
Manual upload proceeds through metadata creation, an upload request, direct transfer to S3-compatible storage and confirmation. A separate Python worker renders missing PDF pages on request. Redis supports state and queuing, with explicit retries and a dead-letter queue for failed tasks. The interface supports page previews and export of selected pages after checking that they are ready. Socket.IO sends events to tenant rooms so related interface state can update.
Technical manuals use direct storage uploads and on-demand page rendering. Export builds a PDF subset after the selected pages are ready.
Technical manuals use direct storage uploads and on-demand page rendering. Export builds a PDF subset after the selected pages are ready.

Agent Work That Follows the Architecture

I organized agent context through a short AGENTS entry point, a documentation index and focused playbooks. Work starts by identifying the domain and layer, then reading the relevant source of truth and selecting a route for the change: backend, CRM slice, portal, orders, media or manuals.
The instructions preserve DTOs, transport contracts, tenant context and UI ownership. The instructions require an appropriate check after implementation and a review of adjacent layers for inconsistencies. Separate skills support Astro layout, hydration, detail shells and Tailwind cleanup while preserving behavior.
This process makes engineering decisions and change boundaries explicit. It consists of instructions, tools and my work with agents; it is not a claim of an autonomous scheduler or an automatically running reviewer team.
The documented agent workflow routes a bounded change through owner documents, a relevant playbook and adjacent-contract checks.
The documented agent workflow routes a bounded change through owner documents, a relevant playbook and adjacent-contract checks.

Checks, Development Environment and Project Stage

Compose and Make describe development, testing and observability environments. The project includes smoke tools, backend and worker metrics, vehicle-catalog import and demo-data preparation. Checks follow the changed surface; the existence of a tool does not substitute for a recorded run.
The result is an implemented CRM foundation with connected domains, a shared backend, a client portal and file-processing workflows. Master remains a profile-and-avatar demo, and some dashboard and financial data is demonstrative. This case presents the architecture and engineering work without claiming user counts, revenue or production scale.
Stack: Python, FastAPI, PostgreSQL, SQLAlchemy, Redis, MinIO/S3, Socket.IO, TypeScript, SvelteKit, Astro, Vue, Docker.
This experience is relevant to CRM systems and client portals that need consistent interfaces, data boundaries, background processing and development with AI agents.
Like this project

Posted Sep 15, 2026

An automotive CRM with FastAPI, connected client applications, tenant boundaries, PDF processing and focused AI-agent playbooks.