I Built a Full Stack App for $0.50 - Here's What That Taught Me About AI
I'm not a traditional developer. I don't have a CS degree. I learned to code at 13 on Visual Basic 3.0, spent 9 years in the U.S. Army including 3 combat deployments to Iraq, came home, spent 15+ years as an automotive technician, and somewhere in between all of that never stopped learning technology.
I run a homelab that would have been considered enterprise infrastructure in the late 90s, It's amazing what's changed in 26 years. Self-hosted git, SSO, secrets management, a zero-trust network architecture, local LLMs, workflow automation. I built all of it myself. I am not telling you this to brag. I'm telling you this so you understand where I'm coming from when I talk about AI.
The Problem
I needed an invoicing application for my side business as a home mechanic. There are plenty of automotive invoicing solutions out there — Mitchell1, Shop-Ware, Tekmetric — but they're built for full shops with full shop budgets. Subscriptions running $100-300+ a month for a guy doing side work out of his garage doesn't make a lot of sense.
Beyond the cost though, there's a principle at stake. I self-host everything. My password manager, my git repos, my search engine, my AI. Why would I hand my customer data, my vehicle history, and my business financials to a SaaS platform I don't control, for a small home business that doesn't need enterprise features?
So I built exactly what I needed. Nothing more, nothing less.
But not just a simple "create invoice, send invoice" app. I needed something that actually understood how a mechanic's business works:
- Parts have a cost and a sell price — the markup matters
- Labor is billed by hours × shop rate — not a flat fee
- Tax applies to parts only — not labor
- A job starts as a Quote before it becomes an Invoice
- I need to look up a customer by phone number while standing in the garage with greasy hands on a phone or tablet
- I need VIN decoding so I'm not manually typing vehicle information
- I need to track time per job internally — not to bill by the clock, but to monitor my own efficiency and ensure I'm staying sharp at the work
These aren't features you find in generic invoicing software. They're features that only make sense if you've actually done the work.
What I Built
The result is a full-stack Flask/Python application with:
- A complete Quote → Invoice → Paid lifecycle with status locking and voiding
- An automatic pricing engine — labor calculated from hours × configurable shop rate, parts auto-priced from cost × configurable markup percentage, tax applied to parts only
- VIN decoding via the NHTSA API with per-customer vehicle history
- Auto-learned customer profiles from phone number lookup — enter a phone number and it fills in the customer, their vehicles, and their history
- PDF generation via WeasyPrint with emailable quotes and invoices via SMTP — quotes and invoices correctly labeled and formatted distinctly
- A canned service library for quick-filling common jobs
- Internal time tracking per line item — purely for my own reporting, never shown to customers
- A mobile-responsive UI built with Bulma CSS, accessible from any device on the LAN — designed for real shop floor usage on a phone or ablet
- Fully configurable business settings — hourly rate, parts markup, tax rate, SMTP configuration
- Dockerized with persistent named volumes for easy deployment
Stack: Python 3.12, Flask, SQLite (WAL mode), Jinja2, Bulma CSS,
WeasyPrint.
I did not write a single line of code.
I spent $0.50 in API tokens using opencode with a custom provider, stated what I wanted, made sure my agents.md was appropriate for the project, had the AI plan the architecture, then build it.
Total cost: $0.50.
Total time: One day.
What I Actually Did
Here's where I expect some people to roll their eyes.
"You didn't build that. The AI built that."
And I'd push back on that — hard.
What I did was:
- Identified a real problem that needed solving
- Understood the domain deeply — 15+ years as a mechanic means I knew exactly what an automotive invoicing app needs to do, down to how markup on parts works and why tax only applies to parts and not labor
- Architected the approach — chose the right stack for the job
- Wrote effective agent instructions — knowing what to ask for requires understanding what you need
- Reviewed, validated, and directed every step of the build
- Caught mistakes — and there were some, because there always are
That last point is critical. AI makes mistakes. Sometimes subtle ones. Sometimes confidently wrong ones. If you don't have the domain knowledge to catch them you'll ship broken software and not know it.
The mobile-responsive layout wasn't just a nice-to-have. I specified it because I know what it's like to stand in a garage trying to look something up on a phone. The internal time tracking that never shows on customer invoices — because as a mechanic you're always working against book labor times. A brake job
might book at 1.2 hours. Am I actually hitting that? Beating it? Where am I losing time? That's data I need for myself, not something a customer ever needs to see on their invoice.
The parts-first sorting on printed invoices — because a customer shouldn't have to read through a jumbled mix of parts and labor line items. Parts grouped together, labor grouped together, clean and readable.
None of that comes from a prompt. That comes from experience.
The AI was the hammer. I knew what needed to be built.
The Philosophy
The industry is having an identity crisis about AI right now and I understand why. AI is ingesting human knowledge at an unprecedented scale and automating things that used to require years of skill development. That's genuinely disruptive and the anxiety around it is legitimate.
But here's what I keep coming back to:
The calculator didn't replace mathematicians. It elevated what mathematicians could accomplish. The people who refused to adapt didn't win — they just fell behind.
AI is the same inflection point.
The people who will thrive are not the ones who ignore it. They're not the ones who blindly depend on it either — pumping out slop and calling it productivity. They're the ones who understand it deeply enough to direct it, validate it, and know when it's wrong.
That requires real knowledge. Real experience. Real judgment.
Responsible Use
I want to be transparent about something.
I run an automated "This Day in Tech History" blog on my personal website. The posts are AI generated. I use n8n workflows and locally hosted LLMs to draft them automatically.
Every single post sits in draft until I manually review and publish it.
The internet is already drowning in AI slop. I'm not interested in adding to it. The automation handles the drafting. The judgment is still mine.
I apply the same standard to my projects. My DOSBox Launcher — a GTK3 desktop app for managing DOS games on Linux — has the AI authorship breakdown documented directly in the README:
| Lines | Percentage | |
|---|---|---|
| Original (core app, UI, docs) | ~4,589 | ~68% |
| Added by AI assistant | ~2,195 | ~32% |
| Total | ~6,784 | 100% |
That's the line I try to walk with all of this. AI as a tool. AI as an assistant. Not AI as a replacement for thinking.
What $0.50 Actually Means
To put that number in perspective — a freelance developer would charge anywhere from $3,000 to $10,000+ for an application like this. A SaaS alternative would run $50-100/month indefinitely.
I spent fifty cents and an afternoon.
That's not a party trick. That's a fundamental shift in what a single person with domain knowledge and the right tools can accomplish.
I'm a 45 year old self-taught infrastructure engineer, army veteran, and automotive technician from Texas. I don't have a degree. I don't have a fancy job title. I have 32 years of continuous self-directed learning, a homelab that saves me an estimated $26,000 a year in SaaS costs, and an invoicing application that cost me fifty cents and actually understands
how a mechanic's business works.
AI didn't replace my knowledge. It gave my knowledge a power tool.
That's the correct way to use it.
Top comments (0)