A full-stack e-commerce platform with an AI sales assistant that answers from the store's own database. It quotes real products, real prices and the shopper's real orders, instead of whatever a language model happens to believe.
The Brief
The client came with a written specification. It called for a single Spring Boot monolith with a product catalogue, a persistent cart, checkout through a simulated payment gateway and an admin dashboard, plus an AI assistant that answers product questions, recommends and upsells the way a good sales associate would. The frontend was to be plain HTML, CSS and JavaScript served by Spring Boot, with no microservices.
Calling an AI API is the easy part. The real work was keeping the assistant from inventing products, prices or delivery dates, and building a checkout that stays correct when two shoppers want the last unit.
What We Built
-
✦
An assistant grounded in the database Before prompting the model, the sales-bot service works out what the shopper means. It pulls in the product currently on screen, keyword matches from the catalogue after stop-word filtering, and any stated budget, parsing phrasings like "under ₹50,000", "around 40k" or "below 1 lakh" into a rupee ceiling. It adds the shopper's recent orders only when the question is about an order and they are signed in. The system instruction then limits the model to that context.
-
✦
An assistant that still works without the AI With no API key configured, an offline rule-based responder answers from exactly the same context. If the live model errors or times out, the assistant falls back to that responder instead of failing the request. The chat widget labels which one answered each reply, and every exchange is saved for the admin's chat-log viewer.
-
✦
Predictable upselling Upsell suggestions are rule-based per category rather than generated by the model, so a nudge is consistent and never points to an accessory the store does not stock.
-
✦
Checkout that cannot oversell Stock is reserved at checkout in a single transaction that locks each product row with SELECT … FOR UPDATE. When two shoppers race for the last unit, one gets a clean "only N left" message instead of both orders going through. If any line fails, nothing moves, and a declined payment or a cancellation returns the reserved units to the catalogue.
-
✦
Orders as a state machine Legal status transitions are declared in one place, so an admin cannot jump an order from pending to delivered or reopen a failed one, and the admin UI only offers moves the backend will accept. Prices and product names are captured at purchase, so editing the catalogue never rewrites a past invoice.
-
✦
Simulated payments and an admin dashboard The payment gateway is a documented simulation. No provider is contacted and card details are never stored, with only the last four digits reaching the logs. The admin dashboard shows revenue and low-stock alerts, product management, order status changes and the assistant's chat logs. The cart lives in the database, so it follows the shopper across devices.
The Stack
Java 17 and Spring Boot 3.3 (Web, Data JPA, Security and Validation), with stateless JWT authentication through a request filter. The database is H2 in memory by default, with MySQL one profile away. The assistant calls the Google Gemini REST API, with the model configurable in one place. The code follows a conventional Controller, Service, Repository and Entity layering, with DTOs at the edge so entities are never serialised straight to JSON. There are eight REST controllers, and a single exception handler returns every error in one consistent shape. The storefront is eleven pages of vanilla HTML, CSS and JavaScript served from Spring Boot, and the chat widget is self-contained. The project builds with the Maven wrapper, so Maven itself is not required.
The Outcome
The platform starts with one command on JDK 17 and seeds itself with six categories and 22 products, so the whole flow can be demonstrated with nothing configured. It ships with 18 automated tests on JUnit 5 and MockMvc. They cover the order state machine, the full register, cart, checkout and payment journey (asserting that stock is reserved, kept on success and restored on decline), the oversell guard, role checks on admin routes, and the offline assistant's budget parsing, context and upsell behaviour. It was handed over with a documented path to production: a real gateway with webhook-driven order states, refresh-token rotation, caching and pagination for the catalogue, rate limiting on the chat endpoint and schema migrations.
Need something similar? Reach out — we build AI assistants that answer from your own data, inside systems engineered to stay correct.