# How I Built a Serverless AI Accounting App with AI assistant and Saved My Family from Spreadsheet Chaos > Source: > Published: 2026-08-26 18:28:34+00:00 As a data engineer, I spend my days designing clean, optimized data structures. But at home, I face a much tougher crowd: my family. We manage our shared finances together to optimize our budget, and because of where we live and work, we have to do this in several different currencies (like USD, EUR, CZK, and UAH) Like any developer, I first tried to find a ready-made app to solve this. But I ran into a classic problem: they were either bloated with a million features we didn’t care about, or they were missing the exact features we actually needed. So, we did what any desperate family does: we opened a **Google Sheet**. We tracked our money there for a while, not because it was perfect, but because it helped us figure out what we actually needed from a real application. It was our "living schema design" before I wrote a single line of code. In this article, I want to show you how I looked at this problem from two sides—as a frustrated user who just wants to log expenses, and as a data engineer obsessed with clean database design. Here is the story of how I built our custom home accounting server. By 2025, I was ready to replace our Google Sheet. My main programming language is Python, so I had three realistic choices: FastAPI, Flask, or Django. As a data engineer, I didn’t want a messy database. I decided to use a **Star Schema**, which is usually used in big data warehouses, but is actually perfect for transaction bookkeeping. Think of it like this: the central table is the star of the show, and everything else just adds context. `Transaction` ):`User` , `Family` , `Currency` , `Account` , and `Category` . By late 2025, I had built the database, a simple web UI, an API, tests, and manuals. I packaged it into two Django apps—`members` and `transactions` —and hosted it locally on an Ubuntu server running **Gunicorn**. It worked beautifully, but I was not done yet. In 2026, I looked at the 10-page text manuals I had written for my family. Let's be honest: nobody—especially your family—wants to read a dry technical guide just to find out how to log a credit card transfer. I decided to do two things: make the app **Serverless** and replace the boring manuals with a **friendly, conversational AI assistant**. To do this, I built a third Django app called `assistant` . But I didn't want a generic chatbot that just parroted generic answers. I wanted a smart assistant that knew exactly what the user wanted. So, I designed it to instantly classify user messages into **four distinct intents**: AI can be slow and expensive if you aren't careful. To make sure my family didn't have to wait 10 seconds for a response, I built a hybrid pipeline using two different cloud providers: **Groq** and **Azure OpenAI**. `gpt-oss-20b` (for lightning-fast intent classification) and `gpt-oss-120b` (for generating replies and SQL queries).`text-embedding-3-small` model and did something sneaky: I configured it to generate embeddings with only By reducing the dimensions to 512, the embeddings generated **much faster**, and the size of my vector database shrank dramatically. Best of all, we didn't notice any drop in search quality. The result? The AI assistant responds instantly, without any visible lag. To keep the AI's knowledge base updated, I wrote a custom **Django management command**. Whenever I edit our markdown spec files, I just run this command. ``` # Ingest general information python family_acc/manage.py ingest_docs documentation/general_info.md --category general ``` It automatically parses the markdown layout, slices it into clean chunks, generates 512-dimension vectors, and uploads them to our hosted PostgreSQL database (with the `pgvector` extension) on **neon.tech**. The whole process takes only a few seconds. Letting an AI write raw SQL queries against your personal database is like letting a toddler run around with a permanent marker—they mean well, but they might delete something important. To prevent SQL injections or accidental data deletion, the database connection used by the Text-to-SQL engine is strictly restricted to read-only ** SELECT** statements. The AI can read our data to answer questions, but it can never edit, modify, or delete a single row of transactions. After testing everything locally in Docker containers, it was time to put it in the cloud. Thanks to my experience with Azure, AWS, and Google Cloud, deploying the container to **Google Cloud Run** was surprisingly smooth. The app immediately connected to our cloud database on neon.tech and the Groq/Azure AI APIs without a single hiccup, working perfectly on the very first try. In a production deployment, you never want to expose API keys or database passwords. Here is how I set up secure DevOps: `DATABASE_URL` and API keys) in Building this application taught me that the best coding projects are the ones that solve real-world problems in your own life. Here is what I learned: This project is a perfect proof of concept showing that you don't need a massive team to build a secure, modern, AI-powered system in the cloud. You just need a clear plan, a bit of data engineering, and a family that is tired of manual spreadsheets.