Selected work by Akhil PP Mohandas

The interesting problem wasn’t getting an LLM to generate text. It was building enough structure around the model that teams could trust the result: mapped inputs, traceable outputs, review workflows, and approval before anything moved forward.

I worked across the React interface, FastAPI services, UX architecture, data flows, and LLM integration. That meant translating the way insurance teams review documents into both screens and backend workflows.

Engineering notes

• Structured data and schema mapping
• React review interfaces
• FastAPI services
• LLM generation workflows
• Human review and approval logic
• AWS infrastructure

Flow

structured input → generation → review → approval

Note

The model was only one part of the system. Most of the interesting work was designing everything around it so people could actually trust what it produced.

ConcreteEIS covers dashboards, authentication, permissions, and role-gated workflows. ConcreteGPT adds a RAG layer that lets users search internal information without manually moving between disconnected documents and systems.

I worked across the stack: React interfaces, FastAPI services, PostgreSQL schema design, authentication, RBAC logic, and AWS deployment.

The harder part wasn’t building individual screens or endpoints. It was making sure the software’s permission boundaries matched how people inside the organization were actually allowed to work.

Engineering notes

• React frontend
• FastAPI services
• PostgreSQL
• Authentication and RBAC
• RAG-based knowledge retrieval
• AWS deployment pipelines

Note

RBAC sounds simple until everyone needs access to everything—except responsibility for everything.

Instead of relying only on brochures or salesperson-led explanations, visitors could explore construction machines, browse supporting media, and move through product recommendations directly on the kiosk.

I designed the interaction flow, built the React interface, structured the recommendation logic, and connected machine information with video-driven exploration.

Designing for a public touchscreen changed a lot of the usual assumptions. People are standing, distracted, unfamiliar with the interface, and often tapping before they’ve read anything.

Engineering & UX notes

• React-based PWA
• Large-screen touch interactions
• Kiosk-friendly navigation
• Product recommendation logic
• Machine metadata and media integration
• Interfaces designed for short attention spans

Note

People at expos do not read. They tap random things until the UI earns their trust.

Designing for public touchscreens is basically designing for chaos, but with bigger buttons.

Instead of asking an LLM to discover relationships on its own, the system models operational evidence as a graph and retrieves that evidence before generation. The LLM’s job is to explain the investigation—not invent one.

Incidents, services, deployments, commits, logs, metrics, runbooks, and timelines are represented as connected evidence in Neo4j. The system traverses that graph, assembles relevant evidence, scores possible hypotheses, and only then passes grounded context to a local LLM.

How it works

incident → graph traversal → evidence → hypothesis scoring → local LLM → cited RCA

Engineering notes

• Neo4j evidence graph
• Bounded graph-first retrieval
• Deterministic hypothesis scoring
• FastAPI orchestration
• Local inference with llama.cpp
• Quantized GGUF models
• Chainlit investigation interface

The system currently includes graph ingestion, retrieval, evidence assembly, structured prompting, local inference, and interactive investigations.

Next

• Semantic retrieval alongside graph traversal
• Graph enrichment from unstructured operational documents
• Investigation replay and offline evaluation
• Better confidence calibration
• Production ingestion connectors and observability

Note

The goal isn’t to build another chatbot for logs. It’s to make every conclusion traceable back to the evidence that produced it.

I owned the project from UX and frontend architecture through implementation and deployment, building a multi-page Next.js experience with a strong focus on responsive behavior, SEO, maintainability, and production performance.

Engineering Notes

• Multi-page Next.js architecture
• Reusable, responsive frontend components
• SEO and performance optimisation
• Lighthouse scores of 95+ across performance, accessibility, SEO, and best practices
• Production deployment and infrastructure work
• AWS Fargate optimisation that reduced infrastructure costs by up to 90% compared with the previous EC2 setup

Note

This project taught me that a company website is still an engineering system — performance, architecture, deployment, SEO, and maintainability matter long after the first version ships.

The assessment turns a series of business and operational questions into a structured readiness score. It combines AI with deterministic scoring so the experience can interpret context without making the final evaluation dependent on unpredictable model output.

Users see their results immediately after completing the assessment, along with a breakdown of their readiness. The system also generates a more detailed PDF report that turns those results into something teams can review and use beyond the website.

I worked across both the frontend and backend — from designing the assessment flow and results experience to building the FastAPI services, scoring workflow, AI integration, report generation, and AWS deployment.

Engineering Notes

• End-to-end assessment experience
• AI-assisted analysis with deterministic scoring
• Live readiness scores and result breakdowns
• Detailed PDF report generation
• FastAPI backend
• Frontend and backend integration
• AWS deployment

Note

The interesting problem here was deciding where AI should help and where it shouldn’t. AI adds context and interpretation, while deterministic scoring keeps the core result consistent and explainable.

I designed and developed the website using React, Tailwind CSS, and Framer Motion. The frontend was built around reusable components, responsive layouts, and motion that helps guide the experience without getting in the way of the content.

Engineering Notes

• Component-based React architecture
• Tailwind CSS styling system
• Framer Motion interactions
• Responsive layouts across desktop and mobile
• Modular sections for a content-heavy marketing experience
• Performance, accessibility, and maintainability improvements
• Netlify deployment

The goal was straightforward: give the client a clean, responsive website that worked well and could still be managed without needing a developer every time something changed.

For this project, WordPress was the practical choice. A custom React stack would have added complexity without making the final product meaningfully better for the client.

What I worked on

• Responsive website implementation
• WordPress setup and customization
• Content structure
• Deployment and hosting
• A workflow the client could maintain after handoff

Note

Not every problem needs the stack I use most often. Choosing the simpler tool is still an engineering decision.