Why I framed Servexa as an evidence-driven operations system—not a generic AI chatbot.
Implementation journey of a bilingual MDX blog, from architecture decisions to localization and content management.
A comprehensive look at how I prepared for the more holistic parts of software engineering interviews, including system design, reviewing CV projects, and acing take-home assignments.
A personal account of my experience preparing for algorithmic interviews, the mindset shifts required, and the strategies that finally made things click.
Warranty work is a decision problem before it is an AI problem. A support agent may need a policy, a product record, purchase evidence, repair history, technician notes, part availability, and the current case state before deciding whether a claim is eligible or what should happen next. When those sources sit in disconnected screens and documents, the hard part is not generating a fluent answer. It is assembling the right context without losing provenance or bypassing the workflow that makes a decision legitimate.
That observation shaped my first engineering question for Servexa: should I build a conversational assistant, or should I build an evidence-driven layer inside warranty operations?
I chose the second. Servexa became a full-stack operations platform in which AI is one participant, not the system of record and not the final authority.
I was the primary engineer. I designed and implemented most of the monorepo across the React frontend, Express backend, FastAPI and LangGraph runtime, PostgreSQL and pgvector knowledge path, Redis coordination, and AI approval workflow. The commit history also contains collaborator and automation contributions; I do not recast those as my own. “Primary engineer” here means direct responsibility for the main architecture and a substantial majority of implementation—not “worked entirely alone.”
The public repository at revision 6aca2a1 is the baseline for implemented claims. Architecture intentions and local work that are not committed are labeled separately.
A generic chatbot optimizes for a conversation. Warranty operations optimize for a defensible state transition.
Those goals overlap, but they are not identical. A useful response might summarize a policy or suggest a diagnosis. A legitimate business action must also answer harder questions:
This led me to frame the product around support staff, technicians, and managers rather than around an abstract “AI user.” The committed product vision and system overview describe the same core position: assist investigation and action while keeping business authority outside the AI runtime.
I decomposed the problem into three layers.
This layering changed what “AI integration” meant. The frontend needed cards for evidence, diagnosis, workflow progress, and pending approvals—not only chat bubbles. The backend needed contracts for sources and proposed actions. The AI runtime needed context identifiers and a way to pause. Most importantly, the execution path needed to return to Express, where authorization and transactions already belonged.
The committed system includes a React application, an Express business service, and a Python AI service. The browser uses Express APIs rather than calling the AI service directly. Express owns authentication, authorization, business records, uploads, and approval persistence. FastAPI and LangGraph own orchestration and reasoning. PostgreSQL stores business data and knowledge chunks; pgvector supports semantic distance. Redis supports coordination and stream-based job foundations.
The user-facing copilot work includes structured evidence sources, suggested actions, workflow state, and approval components. The shared copilot response contract makes those elements explicit instead of forcing the UI to parse prose. The approval card and decision hooks turn a proposed operation into something a person can inspect and decide.
That is an implemented capability. Its expected product value is better context and control for warranty staff. I do not have verified production measurements showing faster resolution, fewer incorrect approvals, or a particular adoption rate, so I do not claim them.
The shortest implementation path would have been a browser chat component calling FastAPI, with the model querying whatever data it needed and invoking actions directly. It would reduce initial wiring and make a demo easy.
I rejected that design because it creates two authorities. Express would own business rules until an AI path bypassed them. Permission logic would drift across JavaScript and Python. A model tool call could mutate state without sharing the same transaction, validation, or audit behavior as the normal product API. The UI might ask for confirmation, but a confirmation dialog is not authorization and does not prevent duplicate execution.
I accepted more integration work to keep one business authority. The trade-off is real: multiple services mean contracts, transport, failure handling, and more difficult local development. The next article explains why I still consider that cost justified.
At the repository level, the design demonstrates that I can connect product context to technical boundaries:
On 14 August 2026, I reran focused suites for the server approval service and action registry, shared HITL contracts, and two web approval behaviors. Thirteen tests passed across six files. This validates those focused behaviors in the test environment. It does not validate the entire warranty journey, Python runtime, restart recovery, or production deployment.
Servexa remains incomplete as a production system. Retrieval evaluation is not yet rigorous enough to quantify answer quality. Some event and browser-streaming capabilities are partial. The current service transport carries migration debt. Approval processing rejects sequential duplicates, but the committed decision path does not yet prove atomic safety under concurrent requests. Full browser-to-database-to-AI restart scenarios have not been validated in this evidence pass.
These are not footnotes to remove from a case study. They show where the engineering problem becomes harder than the demo.
My most important early decision was not choosing LangGraph, pgvector, or Redis. It was deciding what the AI was allowed to mean inside the product. Once I treated the model as a reasoning component rather than a business authority, the rest of the architecture had a clearer test: does this change preserve evidence, permission, state, and human control?
If I restarted the project, I would formalize that evidence model and acceptance criteria before building as much UI. It would make retrieval evaluation, approval traceability, and end-to-end testing materially easier to specify from the beginning. The architectural direction remains the same; the sequence would be more verification-driven.
The remaining four articles are complete drafts and are still under editorial review. They will be linked here as each article is approved for publication.
Return to Engineering Servexa Warranty AI for the full planned reading order.