Why I Build Tech for Impact: Software Engineering as a Calling, Not Just a Career
There are easier paths in software than building systems for healthcare, agriculture, and education in contexts with real constraints. Here is why I choose this work.
Why I Build Tech for Impact: Software Engineering as a Calling, Not Just a Career
Most software engineers I know became engineers because they love building things. The craft of it — the problem solving, the creativity, the satisfaction of making something work. That is why I started.
What kept me here, and what drives the work I choose, is something different: the belief that well-built software changes lives in concrete, measurable ways.
The Moment It Clicked
I was building a school management system as one of my earliest serious projects. A teacher mentioned, offhandedly, that she used to spend two hours every Friday manually calculating student attendance percentages. With the system, it took thirty seconds.
Two hours every Friday is 100 hours a year. She used those hours for lesson planning, student feedback, and actually resting before the weekend. The software was not glamorous — no interesting technology, no clever algorithms. It was a CRUD application with a few calculations. And it gave a teacher 100 hours of her life back every year.
That is when I understood that impact does not require sophisticated technology. It requires understanding a real problem and solving it completely.
The Problems I Care About
I am drawn to problems in domains where software has historically been underinvested: healthcare in resource-limited settings, agriculture and rural livelihoods, education access, civic participation.
These are not the most lucrative domains. They are often the most constrained — users with intermittent connectivity, devices with limited processing power, budgets that do not allow for expensive cloud infrastructure. The constraints make the engineering more interesting, not less.
The hospital queue management system I built was not a complex technical problem. The technical solution was straightforward. The interesting challenge was understanding the clinical workflow well enough to design a system that nurses would actually use under time pressure, that patients could understand without training, and that administrators could use to make staffing decisions in real time.
Agroconnect — the agricultural marketplace connecting farmers to buyers — required understanding how rural agricultural markets actually work, which is different from how urban commerce works. Seasonal inventory, perishable goods, trust between strangers, intermittent connectivity. The PHP NexGen framework I used was technically unremarkable. The domain understanding that made it useful was not.