I'm Mathias Nyola, known personally as Smosz, a software engineer, systems builder and technology problem-solver from Uganda. I design and build digital systems, products and intelligent solutions for people, businesses and organizations. My work spans software systems, PWAs, automation, AI integration and locally relevant technology. I care about understanding the problem behind the request, choosing technology deliberately, and building solutions that work in the environments they are actually meant for.
Where it started
Long before I built systems, I was interested in understanding them.
I was the kid who wanted to know what was inside things, how they worked, and whether I could make them work again.
That curiosity eventually took me from chess and taking apart machines to software engineering, building businesses and asking a bigger question: what can technology make possible for the people and organizations around me?
Before software
Chess taught me how to think through a problem.
Chess was one of my earliest ways of learning how to think. I enjoyed looking at a problem, breaking it down, seeing possibilities and trying to find a way forward.
That way of thinking stayed with me when technology caught my attention. I started opening DVD players, experimenting with broken chargers and wires, exploring computers and trying to understand what was happening inside the machines around me.
I did not have manuals or formal technical knowledge. Sometimes I broke things. Sometimes I fixed them. Either way, I learned.
Discovering software
Hardware showed me what machines were made of. Software showed me what they could become.
I started experimenting with websites, discovered WordPress and local development, learned how websites worked, tried MySQL, hosted my first live site and gradually started working alongside other developers.
That experience mattered because I realized I did not just want to use systems. I wanted to understand how they were built.
So I went deeper into programming, databases, networking, system architecture and the practical pieces I needed to turn ideas into working systems.
Theory met experience
Formal education gave structure to things I had already been exploring.
At secondary school, that curiosity translated into strong academic performance. I became one of the strongest performers in my IT class and often found myself helping classmates understand what we were learning.
I was not only learning for examinations. I was constantly trying to connect classroom ideas to the websites, databases, devices and systems I had already been experimenting with.
I later studied Software Engineering across two universities over five years. My academic journey was not a straight line, but it became an important layer in how I learned to think as an engineer.
Experience had taught me how to explore and build. Education gave me the theory to understand why things worked: architecture, algorithms, databases, software design, engineering principles and systems thinking.
The two forms of learning complemented each other. I brought practical curiosity into the classroom, and I took theoretical knowledge back into the systems I was building.
Neither replaced the other; together they shaped how I approach technology today.
What changed
Technology is ultimately about people, systems and problems.
The system is bigger than the software
One experience that changed my understanding of technology was working near an existing organizational system. I did not own the source code, so I could not simply change the software whenever I wanted.
Instead, I had to understand how the organization actually worked, how staff used the system, where they struggled, what happened when the network failed and what made the system feel useful or frustrating.
That taught me something coding alone could not: a system is not successful because it works technically. It is successful when it works for the people and organization that depend on it.
TselevPOS changed the way I build
TselevPOS began in 2020 as something much simpler: an experiment to test what I could build while learning software development.
Because I was close to the business environment it was being developed around, I could see the problems firsthand: manual records, inventory challenges, disconnected processes and business information spread across too many places.
It was difficult. There were periods when I stopped and times I questioned whether I was wasting my time or whether I was good enough to finish what I had started.
But I kept coming back to it. Eventually, that experiment became TselevPOS, a production system that has continued evolving through real users, real businesses and real requirements.
That was the point where building software stopped being an exercise and became responsibility.
I had to learn to listen
One of the biggest lessons software development taught me had little to do with code. Earlier in my journey, I sometimes argued with users and clients because I believed my technical idea was better than what they were asking for.
Experience changed that. I learned that the person experiencing a problem has knowledge the developer does not have.
That does not mean every requested feature is the right solution. It means the developer has to listen before deciding.
Five chapters
01
Curiosity
Chess, problem-solving and taking machines apart just to understand what was inside.
02
Understanding the machine
Hardware experimentation led me toward software and the realization that software gives machines much of their behavior and usefulness.
03
Learning to build
Websites, WordPress, programming, collaboration, self-learning and formal Software Engineering education across two universities.
04
Building for people
Working with real organizations, understanding workflows and developing TselevPOS taught me that technology only matters when people can actually use it.
05
Building what comes next
AI, African languages, local infrastructure, intelligent systems and technology built around African realities.
What I believe
The principles behind the work.
1
Curiosity
Ask why before accepting how.
2
Practicality
A solution has to work in the real world, not only in a demonstration.
3
Persistence
Some things take much longer than expected. Keep learning and keep moving.
4
User empathy
The person using the system knows things the builder does not.
5
Responsibility
Technology carries responsibilities around security, privacy, ownership and consequences.
6
Local relevance
Technology should account for language, connectivity, devices and economic realities.
7
Continuous learning
Every project, mistake and conversation can teach something useful.
8
Service through technology
Technology is most meaningful to me when it makes something genuinely better for someone.
What I am building toward
An Africa that does not only consume technology, but creates, shapes and owns it.
I want to become someone that individuals, startups, businesses and organizations can come to when they are trying to understand how technology can move them forward.
Not simply: build me an app. More like: here is a problem. Help me understand it, rethink it and figure out what technology can do about it.
Starting in Uganda, I want my work to grow across Africa through useful digital products, business systems, AI, African-language technology, locally relevant infrastructure and tools designed around the realities of the people who will actually use them.