This company installs treatment plants wherever the client is — a town in Querétaro, a site outside La Paz. The crew travels, works for days, and comes back. Until they did, the office had no idea how the job was actually going. Progress was whatever the crew reported when someone called.
I built the app the crew uses on site. Every activity gets timed from a phone: start it, work it, close it. Closing requires evidence, so a finished task always has a photo attached to it. The office sees target versus actual as it happens, not after the fact.
Two things in it matter more than the timer.
The first is that work stops for reasons that aren't failures. Lunch, end of day, waiting on a part. So there's a general pause that turns the whole header amber — the clock stops, and nobody has to pretend the crew was working through it. Time you don't measure honestly is time you can't quote from later.
The second is obstacles. A blocked task isn't a late task, and treating them the same is how field estimates rot. An obstacle gets logged with its type and its scope — the whole project or one activity — and resolving it requires evidence too. Resolve the one blocking a given task and that task unblocks.
Everything runs on the crew's own phone, offline-tolerant, over a stack deliberately kept light: React and Vite on Vercel, with Google Sheets as the backing store the office already knew how to read.
The link below is a working recreation of the installer view. Fictional company and projects; site key is 1234. Time runs at 60× so the clock is visible.
https://claude.ai/code/artifact/4f29fd37-552b-49ab-acc6-c3dcd226e5db?via=auto_preview
1
4
When several partners share the revenue and the costs of a fleet, the monthly closing is the moment where trust either holds or doesn't. The numbers were living in spreadsheets, and every closing was rebuilt by hand.
I built the system that runs it. Income and expenses per unit, shared costs split by rule, per-partner withholdings, and a partner statement with a running balance — paid and projected side by side.
The hard part isn't the arithmetic. It's what happens after a closing is saved and the underlying data moves. A customer pays an invoice three weeks late. Someone corrects an expense that was off by a couple hundred pesos. Most systems handle this by locking the period, which means the correction never makes it in, or by silently recalculating, which means nobody knows what changed.
This one does neither. A saved closing that no longer matches its source data gets flagged as out of date. Open it and you get a comparison by unit, then a hierarchical diff of what actually moved — new entries, deleted ones, modified ones with the old value struck through next to the new. You see the delta before you accept it, and recalculating is one deliberate action.
That's the whole design principle: when money is split between people, the system's job isn't to be right. It's to show its work.
The link below is a working recreation of the closing flow with fictional company and data. Try the closing flagged out of date and walk the diff.
https://claude.ai/code/artifact/c212bbe9-7c89-44ce-a80a-50c174d7b9ae?via=auto_preview
1
7
The plant ran on spreadsheets, printed sheets, and a whiteboard on the production floor. Orders moved by hand and by conversation, and the general manager walked the length of the building several times a day to find out where anything stood.
I built the system that replaced all of it: order intake, planning with batch approval, a five-stage production pipeline — assembly, welding, cleaning, painting, warehouse — inventory that separates committed stock from free stock, and dispatch by customer order rather than by batch.
The part worth touching is the operator app. Shop floor staff don't have email, so login is a four-digit PIN against the personnel table, and each station gets one screen instead of a menu.
It also holds the design decision I'm most sure about. Originally a station couldn't register pieces the previous station hadn't passed forward — clean data, clean sequence. Then welding logged 5 while the cleaning operator had already cleaned 6, and the app told her the piece on her table didn't exist. I took the lock out. What replaced it: a queue tab for batches that haven't formally arrived, the ability to claim a batch forward if you physically have it, and a soft confirmation instead of a hard block, so the gap stays visible rather than punishing the faster station. One rule survives untouched — never more than the batch total.
The link below is a working recreation of the operator screen. PIN is 1234. Company, operators and data are fictional; the real system belongs to a client. Only the cleaning station is enabled.
https://claude.ai/code/artifact/129b1eb1-33cb-4637-a66f-9c0a79c49ea0?via=auto_preview
1
11
Guadalajara's urban tree census lists more than 1,300 species. When it's time to plant, almost nobody opens it. The street just repeats whatever is already on the street.
Arabor turns that census into a decision you can defend. You enter the real constraints of the site, and the engine does three things in order: it eliminates what physically doesn't fit — mature height against overhead cabling, canopy against sidewalk width, water demand against available irrigation — then scores what survives across seven weighted criteria, then explains why each species landed where it did.
The weights shift with the site, not with the preference of whoever is filling the form. A narrow sidewalk weights root behavior at 25%. A park weights native origin at 25%.
And every result carries its own warnings: aggressive roots, problematic fruit in public space, allergenic potential, maintenance above budget. They're stated, not buried. A recommendation with no downsides attached is a recommendation nobody should trust.
Co-founded and built with a partner in Guadalajara. The real product runs on Next.js, React and TypeScript over a local SQLite catalog, and works fully offline — the engine is deterministic and calls no AI at all.
The link below is a standalone recreation of the recommender view, with the same scoring engine ported to JavaScript. There's an ES/EN toggle in the corner. Try setting irrigation to rainfall only and watch Ficus, Eucalyptus and Ahuehuete drop out before scoring even begins.
https://claude.ai/code/artifact/a1d90ffe-37c5-4fe8-9915-9871f85c0795?via=auto_preview
1
14