ESTOYAI
The NGO does the work. EstoyAi writes it down.
Voice-based field reporting for NGOs working on the ground: the promoter dictates the visit, local AI generates a .docx report, and coordination sees it prioritized by criticality. Offline-first. No data leaves the office.
From a visit's audio to a filable report, in about 5 minutes.
TL;DR
The thesis: between a nutrition NGO and a substance-use treatment NGO, the only thing that changes is the data schema. You're not building a solution for one NGO, you're building infrastructure for the sector.
01. Problem
NGOs in the field record in notebooks, WhatsApp, and Excel. Someone has to transcribe it all by hand. It takes hours, and even then it's nearly impossible to see which case needs attention first.
02. Insight
The bottleneck isn't the intervention, it's the recording: it happens where there's no signal, and the urgent gets buried. Solving capture unlocks everything else.
03. Solution
Offline-first voice reporting: the promoter dictates, local AI transcribes and generates a .docx, and coordination sees it prioritized by criticality. Everything runs on the office PC.
04. Status
Working MVP, designed and built solo after the hackathon. I validated the problem with the NGO's leadership, not the full flow with a promoter on a real workday. Not validated in real use yet: that's the next step, not something I already have.
Where it comes from
The starting point was Halketon (Jun 2026), a hackathon organized by Paisanos, Crecimiento, Querido Lunes, and Fardo to build real tools for Argentine social organizations.
The organizers interviewed 16 NGOs and grouped the findings into three tracks. 13 of those 16 fell under Track 3 (impact and reporting). They can't record their fieldwork systematically, and the pattern was always the same (notebooks, WhatsApp, spreadsheets). While the information lives on paper, coordination has no way to see what happened in the field or catch an urgent case in time.
The pilot: Pequeños Pasos
From there came Pequeños Pasos as the pilot case: an NGO with field promoters, several family follow-up programs, and real administrative load. The constraint that defines everything else is that they work in areas with no signal. I validated the problem with its director during the event, and that conversation confirmed the pain and set the technical limits.
To be precise about scope: at Halketon I led product and coordination in a team of four that built a 12-hour prototype. The installable, multi-tenant, offline-first system you see here I designed and built solo after the event. It was a full rebuild, not an iteration of the prototype. That leap is the core of the case.
16
NGOs interviewed in the Halketon research
13 de 16
surfaced the Track 3 problem: unsystematized field recording
< 5 min
design goal: from visit audio to .docx (estimate, not measured)
$0
free and open source (MIT), no licenses or cloud
Source: Halketon research (Paisanos · Crecimiento · Querido Lunes · Fardo) across 16 Argentine NGOs, Apr–May 2026. The project took Track 3 (impact & reporting) with Pequeños Pasos.
The real problem
The bottleneck for field NGOs isn't the intervention, it's recording what they do. Four recurring frictions:
Recording happens where there's no signal
A promoter visiting a family in a vulnerable area can't open an online form. What isn't noted in the moment is reconstructed later from memory, with bias and omissions.
The beneficiary's history is fragmented
One person can have data in a notebook, a WhatsApp group, and a spreadsheet no one has updated in months. Tracking their evolution over time is impossible.
Digitizing fieldwork takes hours
Transcribing paper notes into a computer is manual work by someone who wasn't at the visit. Hours spent transcribing instead of accompanying.
The urgent gets buried
Even when the information is loaded, finding the case that needs immediate attention among dozens of records is slow and depends on someone remembering. Coordination finds out too late.
The result: teams spending hours transcribing instead of accompanying, and a coordination with no visibility of what happens in the field until it's already too late.
How it works
From the field to the office without anyone digitizing anything by hand. The audio travels, local AI processes it, and fieldwork becomes a decision.
Dictates 2 min
Phone, no signal
Queues up
IndexedDB → uploads on network
Whisper + Ollama
Transcribes and extracts fields
Report generated
Fixed structure, editable
Triage
Criticality + action points
All processing (transcription, AI, and storage) runs on the office PC. No external APIs, no cloud, no GPU.
In action
The real flow running, with the Pequeños Pasos configuration and sample data. From dictation on the phone to the prioritized report at the office.
- 1
Dictate the visit
about two minutes of voice, no signal, with a live waveform
- 2
Offline queue
the audio queues and uploads on its own once networked
- 3
The .docx report
ready to review and send to coordination
Real UI running locally. The final .docx and transcription use the full stack at the office.
The promoter's three screens, on the phone. The board coordination sees comes further down.
Prioritization by criticality
The system doesn't stop at generating the .docx. The AI assigns each report a criticality level and extracts the reason and pending actions. That's the step that turns a pile of reports into a decision: what to attend to first.
The criteria
Emergency or imminent risk
Requires same-day action and triggers a protocol. The axis isn't severity in the abstract but time-to-act: acute health risk to life, signs of violence or abuse, a minor with no responsible adult present.
Follow-up in the coming days
Needs prompt handling but isn't an emergency: overdue health checks, school absenteeism, risk of dropping out of the program. It leaves a near-term pending action, not a protocol.
Routine, expected progress
Regular follow-up with good progress and no pending actions. It still enters the system: the history is built from everything, not only the urgent. But it doesn't compete for the team's attention.
A safety net over the AI
The AI runs locally and the model is small: it can miss something. So criticality doesn't rely on the model alone. A keyword safety net forces ALTA on explicit risk terms (violence, blows, self-harm, a minor left alone). The principle, transferable to any AI product: when the model decides something with real consequences, the design needs a floor that doesn't depend on the model.
Known limit: if the model misses an ALTA that matches no keyword, it can slip through. That's why the full transcript is always available and the promoter reviews and adjusts the priority before sending to coordination. The final priority call always stays with a person.
The AI proposes, a person confirms
Before sending to coordination, the promoter opens the review screen: they can fix the priority (High / Medium / Low), the reason, the summary, and the action points, see the full transcript, and choose which sections go into the .docx. The criticality the model assigned is an editable starting point, not an automatic decision without human control.
The coordination board
Coordination opens the board from the office desktop PC, the same machine that runs Docker. Reports are grouped by criticality, and at the top “needs attention today” separates two things that aren't the same: clinical criticality (ALTA) from technical pipeline errors. Calling a family isn't the same as retrying a failed report. The goal is knowing in 10 seconds what to attend to first.
This is where the two moments of human control close: by the time coordination opens the board, every case's priority has already been through a person. Nobody is looking at a triage the model decided on its own.
Who sees and who edits
The two roles share neither screen nor permissions. The promoter works from the phone, in the field. Coordination (admin staff and leadership) works from the office desktop PC. Sending to coordination is the boundary between the two worlds.
- My records · their drafts. They edit and delete them, but only up until they send them.
- Team reports · they can see them, not touch them. No editing or deleting, not even their own.
- My records · no access. Other people's drafts don't exist for coordination.
- Team reports · they edit and delete them. It's the only role that can.
The draft is private on purpose: while a record is half-reviewed it belongs to the promoter and nobody else, and coordination never sees intermediate versions. Sending is the point of no return, which is why the review screen comes before it and not after.
Choosing the model was a product decision
The real tension wasn't “which model is smartest”, but what classification quality can be sustained on the hardware an office actually has. I evaluated the models against a rubric of 9 transcripts (one per priority × program), and the failure was in the model, not the prompt:
| Model | Rubric | Verdict |
|---|---|---|
| gemma3:1b | 4/9 | Discarded, missed serious cases (e.g. child abuse) |
| gemma3:4b | 8/9 | Chosen, production default. ~16 GB RAM, no GPU |
| gemma3:12b | 9/9 | Better quality, but needs a powerful PC (≥ 24 GB) |
gemma3:4b is the default. It's the quality floor and runs on a desktop PC with ~16 GB of RAM, no GPU or cloud. On 8 GB it's too tight and the model stalls the machine. The 12b (9/9) performs better but needs a more powerful box (≥24 GB). On more limited hardware it drops to a lighter model (gemma3:1b / qwen3:1.7b), with a real precision cost cushioned by the keyword net. It's a small eval (9 transcripts) and not yet run on a real office's hardware, so I treat it as a decision criterion, not a closed benchmark.
Why these decisions
EstoyAi was designed from the constraints of field NGOs, not in spite of them. Each decision answers a concrete reality of the field.
Why offline-first
Promoters visit areas with no signal. A form that needs internet in the moment goes unused. The audio records and uploads on its own once connected. The promoter does nothing else.
Why Word and not a custom app
Coordinators and social workers already use Word. No training, no new screen. The .docx is editable, printable, and auditable by anyone. A custom app would add a dependency and exclude those who prefer paper.
Why not a CRM
NGOs already tried Asana, Notion, Salesforce, Trello, and dropped them. The bottleneck isn't coordination, it's field recording. If data doesn't enter easily, the CRM stays empty anyway. EstoyAi solves capture, the rest is each NGO's call.
Why local SQLite and not a cloud backend
A Supabase would put beneficiary data on someone else's server, the opposite of the model. SQLite keeps everything in a file on the office PC, no external service or credentials. For a single office it's plenty, and adds no network dependency you don't need.
Install, data, and integrations
Three smaller build decisions, same logic: each one comes from a constraint of the office, not a technical preference.
An installer, not a deployment
A guided installer (Inno Setup) brings up the whole stack on Windows, no command line. The office installs and uses it, doesn't administer it.
Backup to a disk, not the cloud
Backup goes to an external disk. I considered an R2 bucket, but the free tier filled up with the audio and uploading sensitive data contradicts the model. Google Drive, same.
Optional Podio integration
For NGOs already on Podio there's an endpoint that pushes the .docx via n8n. Optional: no one switches tools.
Data never leaves the office
The differentiator isn't only technical: it's an ethical stance. Beneficiary data, often minors and vulnerable families, is the most sensitive thing an NGO handles. EstoyAi treats it accordingly.
Local processing
Whisper, Ollama, and storage run on the NGO's PC. No audio or data passes through external servers.
Auditable because it's open
The code is public (MIT): for an NGO that isn't cosmetic, it's security. Any trusted technical person can verify that data isn't copied or sent anywhere. Privacy isn't a promise, it's inspectable.
No cloud dependencies
No subscriptions to AI or transcription APIs. If the PC turns off, the system turns off: the office has full control (and it's also a single point of failure, see limits at the end).
Designed around Law 25.326
I used Argentina's personal data protection law and the rights of data subjects as the framework for the data model and controls. It's a documented design decision, not a compliance certification.
ALL ON THE OFFICE PC · DOCKER
Phones
PWA offline
app-pwa
PWA + API
n8n
orchestration
faster-whisper
transcription
Ollama · gemma3:4b
AI extraction
SQLite + .docx
data & report
Audio enters the office through the tunnel. Transcription, AI, database, and .docx generation all happen on the same machine, inside Docker. Nothing leaves. It installs with a guided installer, no command line.
One system, many NGOs
EstoyAi isn't tied to one type of intervention. It's multi-tenant by subdomain: each organization runs its own configuration on the same code. The reference pilot is Pequeños Pasos, and I built a deliberately opposite second configuration to put the hypothesis to the test.
The opening hypothesis didn't stay in the pitch, it defined where the line runs through the code. Programs, report fields, and extraction schema live in a per-tenant config file. Voice capture, the offline queue, the local pipeline, and criticality triage are shared core and stay untouched.
Adding a new organization means writing a config file and standing up a subdomain. It isn't a fork or a branch per client, which is where systems like this usually end up.
Pequeños Pasos
PILOTTerritorial-intervention NGO · pequenospasos.estoyai.com
The organization the system was designed with, running three family follow-up programs.
DTC Villa Tranquila
PROOF OF CONCEPTSEDRONAR model for substance-use treatment
It isn't a second NGO on board. It's the test of the hypothesis: I built the configuration for an intervention at the opposite end from a nutrition visit and checked it against my own experience working with the SEDRONAR substance-use treatment model. The core held without touching a line.
The same screen and the same code across both tenants. Only the programs and report fields change, through configuration.
How a new NGO gets in
I designed a public landing so an organization can evaluate the system without talking to me first. It's the front door of the adoption model: if the thesis is that it serves many NGOs, it has to reach them without me in the middle.
Each office then uses the app through its own subdomain (pequenospasos.estoyai.com, dtcvillatranquila.estoyai.com) and logs in with a password held only by its team.
Status and what's next
Today EstoyAi is a working MVP, designed and built solo after the hackathon. I validated the problem with the leadership of Pequeños Pasos, but no one from an NGO has yet used the full flow on a real workday. The system is available for any organization that wants to adopt it.
Known limits
- I validated the problem with coordination, not the behavior with a promoter: the whole product depends on them actually dictating 2 min after the visit, and I haven't observed that with anyone yet.
- Field transcription quality: phone audio, noise, and Rioplatense accent are the biggest technical risk. It's an open front to measure with real audio.
- Availability vs. durability. If the office PC dies, the service goes down: that's the price of nothing leaving the office, not something you can “mitigate” without betraying the model. The data, however, is covered by a manual backup to an external disk. Not auto-sending it to the cloud is a deliberate choice: the R2 endpoints exist in the code but stay out of the product, for the same privacy reason.
Real next step
Put the full flow in the hands of a promoter and a coordinator during a real workday, and measure the only thing that validates the product: is it used without me next to it? is the .docx what the funder asks for? how much time does it really save versus the notebook?
What I'd do differently: get to that session with the NGO sooner, without waiting to “have it all”. The lesson of this project is that the validator isn't a final exam you show up ready for, it's a dependency of the roadmap.
No signal, no budget, no technical team, with data that can't leave. Designing from those constraints wasn't a limitation. It was the product.
