AUTOMEX | Multilingual Technology Services Platform

Project Overview

AUTOMEX is a multilingual platform for a technology services business. It combines a public site for discovering services and requesting work with a client dashboard for following requests, bookings, support conversations, and account activity. A separate Django application provides the content, account, CRM, notification, and AI assistant APIs behind those experiences.

The product serves two audiences. Prospective clients can explore services, industries, case studies, articles, and technical capabilities before contacting the business. Existing clients can sign in to see their requests and communicate about ongoing work. The business can manage published content and operational records through an administrative interface.

I worked across the connected frontend and backend codebases to turn those needs into one coherent platform. The frontend uses Next.js, React, and TypeScript. The backend uses Django, Django REST Framework, PostgreSQL, Redis, and Celery. The public site is available in English, Spanish, German, French, Chinese, and Arabic, including right to left presentation for Arabic.

The Problem

A technology services website can explain what a company offers, but that alone does not manage what happens after a visitor makes contact. A quote request must be captured, a consultation needs availability, a client may need to check progress, and a support conversation must remain connected to its original request. If each step lives in a separate tool, both the client and the business lose context.

AUTOMEX brings public discovery and client operations into a shared system. The public pages help visitors understand services and submit inquiries. The CRM stores those inquiries as structured records. The dashboard gives authenticated clients a place to review activity, while an administrative interface supports content publishing and follow up.

The technical challenge was to make the experience feel unified even though it is built from two applications with different responsibilities.

My Approach

I treated AUTOMEX as a connected product rather than a collection of pages. The frontend and backend have distinct jobs, but each important user journey crosses their boundary.

1. Public pages present content managed in the backend.

2. Contact, quote, and booking forms create CRM records through the API.

3. Account flows establish a client identity for protected dashboard activity.

4. Notifications and support keep the conversation attached to the relevant record.

5. The backend AI assistant can respond to a visitor and capture a lead when the visitor provides contact information.

This structure lets the public experience, client experience, and internal administration evolve around the same underlying business data.

Full Stack Architecture

The two repositories meet at the API boundary. Public content and forms use an application key through a server side client, while private dashboard requests use a user's access token. The diagram separates the shared records from background delivery and AI assistance.

Frontend application

The Next.js 16 application renders the public website and the client dashboard. React components support interactive navigation, forms, search, account screens, and dashboard views. TypeScript helps keep content and API response handling consistent across many routes.

The public site includes service pages, case studies, a portfolio, articles, partner information, industry pages, technical expertise, AI capabilities, contact pages, and consultation and quote forms. Many content pages request data from the Django API on the server, then render localized results for the active route.

Backend application

The Django 5 application exposes a versioned REST API. Its main domains are accounts, content, CRM, AI assistance, notifications, and shared services such as media and search metadata. Django REST Framework provides serializers, permissions, pagination, filtering, and API views. PostgreSQL stores business records; Redis supports caching and background task infrastructure.

The backend also provides an administrative workspace using Django Unfold. Administrators can manage services, blog posts, case studies, portfolio entries, partners, team information, inquiries, bookings, support tickets, notifications, and integration settings.

The boundary between applications

The frontend uses one server side client for public content and CRM requests that require an application API key. Account and dashboard operations follow a separate authentication path using user tokens. This split reflects a real product distinction: public content must be available to visitors, while a client's own records require individual authorization.

The backend publishes an OpenAPI schema, and the frontend includes a command for generating TypeScript API types from that schema. This gives the two codebases a shared contract without requiring them to live in one repository.

Multilingual Content and Presentation

AUTOMEX serves six languages: English, Spanish, German, French, Simplified Chinese, and Arabic. The frontend uses localized routes and message files. Arabic pages also change text direction and related interface behavior.

Translation is not limited to navigation labels. Backend content models support translated names, descriptions, and slugs. The frontend sends the active route language when requesting content, and the API resolves the appropriate translation. One small but important detail is that the frontend and backend use different codes for Simplified Chinese; the API client maps between them.

The language system also affects search visibility. The frontend generates localized metadata, alternate language references, structured data, and sitemap entries for public pages. The backend supplies published content and additional sitemap information so new services, articles, and case studies can appear in those routes.

Public Content and Editorial Workflow

The public website is backed by a content system rather than a set of fixed marketing pages. Administrators can create and manage services, service categories, industry information, case studies, blog posts, portfolio projects, partners, testimonials, team profiles, certifications, and related reference data.

The content API returns records that are active or published for public display. Its serializers shape the data needed by listing and detail pages, while filters and pagination support discovery across larger collections. The frontend caches appropriate content requests for short periods and keeps transactional CRM operations fresh.

This separation matters for day to day operations. A service description or case study can change in the administrative interface without a corresponding edit to the public page component. The same content can then appear in several localized views with consistent structure.

CRM and Consultation Workflows

AUTOMEX turns visitor actions into structured CRM data. Public forms support contact inquiries, quote requests, consultation bookings, and newsletter subscriptions. The backend records the request type, client details, related service information, and activity history.

Consultation booking uses stored availability slots. When a request is submitted, the backend checks the selected date and time against the slot definition and available capacity. The booking operation runs in a database transaction and uses row locking for existing reservations before checking capacity. The browser display is therefore not the only place where availability is checked.

Clients who sign in can view their requests, booking information, support tickets, and related activity in the dashboard. They can also send messages on a request, manage ticket conversations, and review saved calculation submissions. Guest visitors have a separate token based path for checking submitted requests and participating in support conversations without first creating an account.

Accounts and Client Dashboard

The account API supports registration, email verification, sign in, password recovery, magic links, Google sign in, profile updates, and session management. The backend issues user tokens and applies permissions to protected account and dashboard endpoints.

On the frontend, the dashboard combines summary cards, recent activity, and quick actions with dedicated pages for requests, bookings, support, notifications, conversations, profile information, security settings, and calculations. These views pull from the user's records rather than displaying generic sample data.

The backend keeps the authorization check close to the data. Dashboard queries filter requests, bookings, tickets, and other records to the authenticated user. Guest routes use tracking tokens and separate lookup rules instead of pretending that a guest has a full account session.

AI Sales Assistant

The AI assistant API uses Groq through a provider interface in the Django backend. A chat request includes the visitor's message, language, and conversation session. The service stores both sides of the exchange and sends recent conversation history with a system prompt to the model.

The assistant is connected to the CRM, but it does not automatically turn every conversation into a lead. If a visitor supplies an email address in a message, deterministic extraction can capture that address and create a lead once for the conversation. Information returned by the model can help identify a service of interest, while the contact detail that triggers lead creation comes from the visitor's own message.

If the AI provider fails, the conversation remains usable. The backend stores a clear fallback reply instead of failing the request with a server error. Signed in clients can also review their previous assistant conversations through authenticated history endpoints.

Notifications and Follow Up

The platform stores notifications and exposes a client notification center with unread counts, read actions, and preferences. Email delivery is handled by background tasks. Delivery attempts and failures are recorded, allowing the business to inspect what happened rather than assuming every message arrived.

Celery workers process email notifications, while scheduled tasks support consultation reminders and digest emails. In app notifications are represented by stored records that the dashboard can read directly.

The notification model also has SMS, WhatsApp, and Slack channel options. Their external delivery providers are not yet implemented in the current code, so the case study does not present them as working outbound integrations.

Operations and Quality

The backend includes a Docker Compose setup for Django, PostgreSQL 15, Redis, a Celery worker, and a Celery scheduler. Gunicorn runs the Django application inside the web service. This gives the backend a repeatable environment for the API, database, cache, and background work.

The backend repository also includes an automated test suite and a CI workflow. The workflow performs Django system checks, checks for missing migrations, and runs tests on pushes and pull requests. These checks are a useful foundation for a platform with many related data models and business workflows.

The frontend and backend each have their own deployment lifecycle. Keeping them separate makes their responsibilities clear, while the API contract and shared domain concepts connect them into one product.

Engineering Decisions and Tradeoffs

Separate public content from private account data

Public pages and authenticated dashboards have different access needs. A server side API client handles content and form requests, while account operations use user authentication. The backend applies API key checks to public content endpoints and user permissions to protected records.

Keep localization in the data flow

A translated interface is not enough if the service catalog still returns only one language. AUTOMEX carries the locale from the route into backend content queries and search metadata. This makes localized pages a property of the complete request path rather than a visual overlay.

Preserve business context across forms and conversations

An inquiry becomes more useful when its service interest, booking, messages, and status can be reviewed later. Structured CRM records and activity timelines provide that continuity for clients and administrators.

Treat AI as an assistant, not the source of truth

The Groq integration can respond to visitors and help identify a relevant service, but contact extraction and lead creation are handled by application logic. A provider failure produces a fallback message rather than blocking the rest of the site.

Current Scope and Future Work

The repositories show a substantial implemented platform, but they do not establish business outcomes such as revenue, conversion improvement, or client volume. Those results should only be added when verified measurements are available.

There are also clear areas for further work. The frontend includes an assistant API client and a conversation history page, but the current source does not mount a public chat interface. Connecting that interface would expose the existing backend assistant workflow to visitors. SMS, WhatsApp, and Slack delivery can be connected to real providers. Account token storage can be moved toward server managed cookies. The frontend could gain its own automated test coverage, and end to end tests could exercise the full path from a public inquiry through backend storage to the client dashboard.

The language configuration in the current code contains six storefront languages. Older documentation mentions ten, but the implemented frontend and backend language lists agree on six. Describing the actual supported set keeps this case study aligned with the software people can inspect.

Outcome

AUTOMEX connects discovery, inquiry, follow up, and client service in one multilingual platform. Visitors can explore the company's capabilities and submit requests. Clients can return to see progress and communicate. Administrators can manage the content and operational records behind those experiences.

For my portfolio, the project demonstrates work across a real frontend and backend boundary: localized React experiences, typed API integration, relational domain modeling, authentication, CRM workflows, AI assistance, background tasks, content administration, and deployment infrastructure. Its value is in how these pieces support the same client journey, not merely in the number of technologies used.

Source Repositories

The implementation is split between the frontend repository and the backend repository.