Inspiration
I have a side project for fleet managers in Turkey. Fuel loss is a very common problem in that market, and managers want to track it. The evidence is usually there, but GPS data and fuel data live in separate systems, so nobody sees it together. I wanted to build a standalone assistant that helps managers with exactly this.
What it does
It takes GPS pings, tank level readings and fuel card transactions, runs three predefined rules on the data, and detects anomalies. Then GPT-5.6 investigates each case: it explains what the data shows, lists other possible causes like a leak or a broken sensor, and suggests the next step. One rule I set from the start: the tool never blames a person. It describes events and gives the manager a starting point. There is also a query box where managers can ask questions in plain language.
How we built it
I prepared a spec first (PROJECT_SPEC.md, it's in the repo) and used it as a guide for Codex. For each milestone Codex proposed a design, I reviewed and pushed back where needed, then it implemented and we verified against the data. Everything was built in one continuous Codex session.
Challenges we ran into
It was my first time using Codex, but it wasn't hard to get used to. The real challenges were in the details: Codex caught a flaw in my seed data that would have caused false alarms in one rule. Later I noticed all trucks showed identical kilometers. Synthetic data that looks fake is a real problem for a demo. There was also a React Strict Mode race that silently dropped finished investigations, and deploying SQLite to Vercel's read-only filesystem needed a different approach (I ship the pre-investigated database with the build).
Accomplishments that we're proud of
I now have a working fuel intelligence engine that I can use in my side project. And when the API key was missing, Codex refused to fake model results, the whole build stayed honest, which satisfies me as much as the features.
What we learned
I learned how to build intelligence on top of system data: deterministic rules find the problem, the model explains it. I also learned that with a spec-driven workflow, my job becomes reviewing and verifying instead of typing code.
What's next for TankGuard
Make it work with real data, streamed GPS and fuel feeds instead of seeded data, and detection running as a scheduled job.
Built With
- codex
- function-call
- gpt
- leaflet.js
- nextjs
- openai-api
- openi
- react
- recharts
- sqlite
- structured-outputs
- tailwindcss
- typescript
- vercel
Log in or sign up for Devpost to join the conversation.