About
Software engineer, builder, curious mind.
I'm Paul Ochieng Levi, a software engineer based in Kampala, Uganda. I build digital products from interface to infrastructure: responsive web applications, useful APIs, and the systems that connect them.
I enjoy working across the stack because the best product decisions happen when design, data, and implementation inform one another. I've contributed to AirQo's platform serving air quality data across African communities, and I also build product tools, marketplaces, and developer experiences.
I care about low-bandwidth performance, multi-language support, and software that respects its users' actual conditions. Good technology begins with local constraints, clear communication, and a willingness to make the complex feel straightforward.
Experience
Applied AI & Developer Tools
Exploring local-first developer tools with an emphasis on useful workflows, privacy, and performance on everyday hardware.
AirQo Platform
Contributing to AirQo's frontend and backend, including building and mainly maintaining AirQo Nexus alongside the public website. Internationalization supports 40+ languages, with REST APIs, analysis flows, dashboards, maps, and data visualizations for air-quality monitoring across Africa.
PICSA Apps
Contributing to the PICSA Apps monorepo, a set of tools supporting participatory climate services and agricultural extension. The work brings practical climate information and training resources closer to farmers and extension teams.
Full-Stack Product Development
Building web applications across the stack with TypeScript, React, Next.js, Python, Django, and PostgreSQL, from interface design through production APIs.
Engineering Philosophy
Ship working software, then iterate. A deployed product that helps someone beats a perfect architecture that never launches.
Build for the constraints you actually have. If your users are on 3G connections and mid-range Android devices, your performance budget starts there, not on your development laptop.
Write code that the next developer (including future you) can understand without a walkthrough. Complexity should be justified by the problem, not the solution.