Technical decisions for a mission-driven operations app

One of the most interesting parts of working on the Watts of Love app has been figuring out what kind of technical decisions actually matter early.

The project, which we call Helios, is meant to support real operational work: field distributions, monitoring and evaluation surveys, role-based workflows, mapping, training, administration, and eventually mobile-first execution in environments where connectivity cannot be taken for granted.

My connection to the work is personal too. Last year, I went with Watts of Love to Nsanje, Malawi, and that trip was where we first started seriously talking about the app idea. Seeing the mission up close shaped how I thought about the software from the beginning. It was never just an abstract operations tool. It was a system meant to support real people, real logistics, and real follow-through in the field.

That immediately changes the tone of the architecture conversation.

When you are building for a mission-driven organization, the right question is usually not, “What is the most impressive stack?” It is, “What gives this team the clearest path to something dependable, understandable, and extensible?”

For Helios, that meant favoring a TypeScript monorepo with a straightforward split between backend, web, and mobile surfaces.

The current structure is simple on purpose:

• an Express API in TypeScript for backend workflows
• a React web app for operations and administration
• an Expo-based mobile app for the field-oriented future of the product
• PostgreSQL as the operational data backbone

That combination is not flashy, but it gives us a few important advantages.

First, it keeps the mental model clean. There is one language across the stack, which lowers the cost of moving between layers and makes the system easier to reason about while requirements are still evolving.

Second, it respects the reality that not every workflow belongs in the same client.

The requirements make that pretty clear. There is a web-facing administration surface for staff and managers, but there is also a separate mobile-first field reality: offline capture, barcode or QR scanning, GPS collection, attachments, and distribution work happening in low-connectivity environments. Trying to flatten those into one interface too early would create more confusion than value.

Third, it lets us separate what is already proven from what is intentionally staged.

One thing I like about the current Helios shape is that it already supports meaningful operational workflows without pretending everything is done. Distribution management, recipient management, team and lighthouse administration, role foundations, and a meaningful portion of the monitoring and evaluation workflow are already in place. At the same time, the project is honest about what still needs deeper investment: full CRM integration, richer survey logic, light and box scanning, household-level GPS capture, and offline-first mobile execution.

That matters because good technical decision-making is not about building the entire future on day one. It is about building enough of the right foundation that the future has somewhere stable to land.

The more I work on this app, the more I believe that architecture is really an exercise in stewardship.

You are not only choosing tools. You are choosing what will be easy for the next person to understand, what will be durable under operational pressure, and what will still make sense when the product grows into requirements you cannot fully see yet.

For a mission-driven app, that mindset feels especially important.

The goal is not technical elegance for its own sake. The goal is to create systems that are clear, resilient, and useful enough to support real work in the field. If the architecture helps the organization operate better, learn faster, and extend the product responsibly, then it is doing its job.

If you want to learn more about the mission itself, visit wattsoflove.org.