AirOS

user and password for testing
you can choose your index of the site with any type of deseing
sell panel
Index of the site
Dashboard with all the data
products administrator

Inspiration

In Argentina, every business that sells anything is legally required to issue electronic invoices through ARCA, the national tax authority. There is no opt-out. A hardware store with two employees faces the same compliance surface as a company with two hundred.

The software that solves this properly is enterprise ERP: expensive, subscription-based, priced in a currency these shops don't earn in. So what actually happens is a spreadsheet, a notebook, and someone staying late to type supplier invoices into a government web form one line at a time. I know this because my grandfather built his own version of this workaround back in 1989.

The second problem is connectivity. In Argentina, internet drops. A point of sale that stops working when the connection does isn't a point of sale — it's a liability during the busiest hour of the day.

What it does

AirOS is a business management system for small Argentine retailers. It handles the full operating loop: catalog, sales, point of sale, customer accounts, supplier purchases, installment plans, expenses, and ARCA-compliant electronic invoicing.

Three things make it different from a generic ERP:

It works offline. The point of sale and the field-sales module are progressive web apps with a service worker and local persistence. A shop can keep selling through an outage, and the system reconciles automatically when the connection returns.

It adapts to the vertical. The same core runs a pet shop, a hardware store, a wine shop, and a bicycle workshop, each with its own storefront and its own domain modules — grooming appointments, pet boarding, workshop service tickets. Onboarding a new vertical doesn't mean a new codebase.

Supplier invoices load themselves. This is where Gemini runs the business. A shop owner photographs a supplier invoice. Gemini extracts the full document — issuer, tax ID, line items, VAT brackets, totals — and then makes the call: the extraction is validated against the arithmetic and the tax rules, and if it holds up, the invoice posts to the ledger with no human in the loop. If it doesn't, the system routes it to review and states exactly which check failed. The AI isn't summarizing anything for a human to approve — it's deciding whether a financial record enters the books.

How we built it

The core is PHP and MySQL, deliberately — plain PHP with no framework, no Composer, no central router. Each of the 57 REST endpoints in api/ is its own file. Old-school, but explicit, and it runs on the cheapest shared hosting available in Argentina, which is what these businesses can actually pay for.

ARCA fiscal integration over SOAP — WSAA for the access-ticket exchange with X.509 certificate signing, WSFE for invoice authorization against the production WSDL. This is the least forgiving part of the system. Offline-first PWA — a service worker, local (IndexedDB) persistence, offline shells for both the point of sale and the field-sales app, and a dedicated sync endpoint that reconciles state once the connection returns. Two LLMs in production, doing different jobs. Gemini (via generateContent with a structured output schema, temperature zero) reads supplier price lists and product photos and makes the auto-post decision on invoices. Claude reads incoming supplier invoices end-to-end (PDF or photo) for the "AI invoice reception" flow. Every call is logged with model, latency, token usage, and outcome. Payments and messaging — MercadoPago and a Postnet card-terminal integration for point-of-sale payments, a self-hosted SMTP mailer, and Google integrations for reviews and product-image sourcing. A Python service (Flask, deployed separately) for ARCA/tax reconciliation and for parsing supplier price lists that arrive as PDFs from specific wholesalers — that's how wholesale pricing actually moves in this market. Multi-vertical by design, not by copy-paste — dedicated modules for daycare, grooming, and bicycle-shop service tickets sit on top of the same core, plus built-in i18n (Spanish/English) and a visual storefront editor with image hotspots. Challenges we ran into

ARCA does not forgive. The fiscal web services reject anything malformed and the error messages are terse. Getting WSAA token signing correct against the production environment took the better part of a month and taught me more about X.509 than I wanted to know.

Offline reconciliation is a distributed-systems problem in disguise. Two devices selling the same stock during an outage will disagree when they come back online. Deciding what wins — and making that decision legible to a shop owner who doesn't care about vector clocks — was harder than building the offline mode itself.

Structured extraction had to be boring. Early invoice extraction was plausible and wrong — numbers that looked right and didn't sum. The fix was constraining the model with an explicit response schema, setting temperature to zero, and refusing to trust any extraction that fails arithmetic validation. Confidence had to be earned by the check, not claimed by the model.

And the hardest part wasn't technical at all: convincing people to abandon a system they've used for years — a notebook, a spreadsheet — for something completely new, built on unfamiliar technology.

Accomplishments that we're proud of

Getting a real, paying customer to trust a brand-new system with their actual invoicing and stock during the hackathon window. Getting ARCA's production fiscal web services to work at all, on the first try, without an integrator. Running two different LLMs live in production for two different jobs — not as a demo, but wired into real business decisions (auto-posting invoices, reading photographed price lists) — and catching and fixing real bugs in that pipeline live, in front of real usage. And building an offline-first POS that a shop owner can trust during an outage, which is the exact moment a point of sale actually needs to work.

What we learned

Most people don't know what this technology can actually do for them, and that's a bigger obstacle than any technical problem. Explaining what AI-assisted invoicing means to someone who's never trusted software with their books, and getting them to actually use it, was consistently harder than any integration in this list.

What's next for AirOS

Extending the AI decisioning to more of the operating loop — not just invoice intake, but purchasing suggestions and pricing — and onboarding more shops across more verticals on the existing multi-tenant core.

Prior work disclosure

AirOS was built from zero during the Hackathon Submission Period (May 19 – August 17, 2026). No pre-existing generic template, framework, or boilerplate was used for the core platform. Some personal utility code (small helper snippets, not tied to any prior business or product) was reused, as is common practice — nothing that constitutes a pre-existing business resource.

Traction

Revenue, expenses, and profit for the Hackathon period are reported in detail in the Revenue/Expenses section of this submission ($1,000 total revenue from one arms-length customer, Equinobike, for a one-time system-implementation fee; $20 in expenses; $980 profit) — see that section for evidence.

Separately, as a measure of real production usage: the AirOS admin dashboard for our live customer (Equinobike) shows active daily operation — 24 orders today and $13,584,405.07 ARS in sales processed through the platform this month. This reflects Equinobike's own retail sales running through AirOS, not revenue earned by AirOS itself; it's included here as evidence the system is genuinely in production use, not a demo environment.