How I Built a Telegram Expense Bot and a 3D Game with Codex

I gave myself two challenges. The first was to build something connected to fintech so I could keep practicing product logic around expenses, receipts, categories, analytics, and the habit of tracking money.

The second was to build a real game mechanic—not just a decorative UI prototype, but a system with 3D graphics, a scene, camera behavior, effects, and character states. I am not a traditional software engineer, so this became a useful test of how far I could go with Codex when I already understood the product, the visual direction, and the experience I wanted.

The result was a Telegram bot that accepts a receipt photo, a banking screenshot, a PDF, or a plain-text transaction. It extracts the amount, date, merchant, receipt items, and category, then stores the expense. I connected that utility to an arcade game so expense tracking would feel like a live progression loop rather than another lifeless spreadsheet.

My first prompt is usually deliberately simple. I describe what I want in ordinary language, inspect the proposed direction, remove unnecessary parts, and then narrow the task through iteration. I do not try to produce a perfect engineering specification before I have seen the first working shape.

Codex was not a magic button that built the entire product for me. It worked more like a technical partner: I set the direction, it proposed an implementation, and I reviewed the result through a designer’s and product owner’s eyes.

I kept product planning and prioritization on my side. That let me spend AI effort on implementation, integration, and exploration while retaining control over the user loop, feature sequence, and definition of quality.

The first layer was a Python Telegram bot built with Aiogram. It accepts receipt photos, banking screenshots, PDFs, and text messages. OpenAI handles OCR and structuring, extracting transaction dates, totals, merchants, line items, and a suggested category before the data is stored in PostgreSQL.

Categorization still needs refinement, especially manual correction when the suggested category is wrong. That is a quality-improvement problem rather than an unknown research problem, so it can be improved incrementally with real usage data.

I also added analytical commands for monthly reports, categories, and top expenses. At that point the bot became more than a receipt parser: it formed a usable personal-expense system.

Expense tracking quickly turns into an obligation, and obligations are easy to abandon. I wanted the product to create a reason to return, so I connected scanning to a game loop.

The first mechanic was an endless race: the car moves forward, collects coins, and builds distance, speed, and experience. When it became unclear why a run should stop, the answer became part of the fiction: the car runs out of fuel, reaches a station, and a fight begins.

That produced a coherent synthwave world: drive through a neon landscape, collect currency, enter a battle scene, defeat the opponent, earn progress, and unlock more receipt scans.

An earlier Godot experiment taught me that asking AI to invent every 3D asset from scratch can be expensive and unpredictable. For this project I reused GLB models for the car, coins, and environment, then asked Codex to assemble the Three.js scene around visual references I had generated.

This approach worked well. Codex connected the models, positioned objects, configured lighting and camera movement, and implemented effects without wasting effort on generating geometry that already existed.

The one asset I built manually was a ramp. Available free models were either too heavy or poorly prepared, so I drew a simple ramp directly for the scene. Once the object was clean, Codex could turn it into a reliable gameplay element.

I am not a 3D specialist, but I can describe cinematic intent: zoom toward this object, make the jump feel larger, transition dramatically into the boss fight, or change the camera response after a collision.

Codex translated that language into camera states and transitions surprisingly well. It handled race-to-fight changes, jumps, impacts, object zooms, and more dramatic framing without requiring me to manually calculate every movement.

That changed how I understood the tool. Codex can be more than code completion; it can act as a technical executor for visual direction when the person directing it has a clear picture of the desired experience.

I generated music with Gemini and used Codex to crossfade between two tracks for racing and combat. Hit, impact, victory, and defeat sounds made the fighting scene feel much more physical.

For the characters, GPT generated two visually strong sprite sheets. They looked impressive but failed as production game assets: body parts were clipped, frames were misaligned, and neighboring poses leaked into each other.

I rebuilt the sprite sheet in Figma with a strict grid, consistent frame dimensions, predictable anchors, and simpler poses. Codex then sliced it correctly and implemented idle, walk, attack, hurt, and victory states. The lesson was clear: AI can generate attractive imagery quickly, but interactive assets still need design discipline.

A statistics screen opened from the XP indicator and showed average speed, total distance, zen distance, previous runs, and battle history. This made the game feel like a persistent system instead of a disposable demo.

Coins and experience connect driving, boss battles, and receipt scanning. The next layer is an economy where players can upgrade the car and character, unlock skins and effects, and experiment with different fighting styles.

Future work also includes better expense categorization, manual corrections, clearer analytics, Google Sheets export, Telegram Stars, and a small experiment with blockchain-based currency.

The stack was selected for speed, clarity, and the ability to keep iterating without building unnecessary infrastructure.

Codex did not replace product thinking. It gave me enough technical leverage to test ideas in working code: libraries, APIs, scenes, states, animations, music transitions, databases, and bot commands.

The product frame remained my responsibility: why the user should care, where motivation comes from, how progress works, and how the bot and game reinforce each other. Visual quality also required direct design work when generated assets were not production-ready.

The final MVP combines expense tracking and an arcade game in one loop. A user sends a receipt, the bot converts it into structured data, and the game makes the habit easier to continue. The system already has a working architecture, a recognizable visual world, and a clear direction for further development.