I didn't begin my journey into software development because I dreamed of becoming a programmer.
I started because I was frustrated.
For years, I worked around the financial technology and lending space. I saw a recurring problem: many lending institutions needed software that actually understood how they operated.
They needed more than a simple loan calculator or a basic management system.
They needed systems that could handle:
• Customer and member management
• Loan origination and approvals
• Savings and deposits
• Loan repayments and collections
• M-Pesa and payment integrations
• SMS notifications
• USSD services
• Teller and cash management
• Guarantors and group lending
• Real-time reconciliation
• Reporting and analytics
• Role-based access and approval workflows
The frustrating part was that finding the right solution was difficult.
Some systems were too expensive.
Others were too rigid.
Some required multiple third-party platforms to work together.
And sometimes, a solution looked perfect during a demonstration but became a completely different story once you tried adapting it to real-world lending operations.
Eventually, I asked myself a question that changed my career:
What if I stopped looking for the perfect solution and started learning how to build one?
So, I Started Learning to Code
That decision was intimidating.
Software development initially felt like entering an entirely different world.
There were programming languages, frameworks, APIs, databases, servers, authentication, deployments, Git, Docker and a seemingly endless number of technologies.
And then there were the errors.
So many errors. 😅
I would solve one problem and create three new ones.
Sometimes I would spend hours debugging something that eventually turned out to be a missing configuration variable, an incorrect API endpoint, or even a simple typo.
But something interesting happened.
The more problems I solved, the more I realized that software development wasn't simply about writing code.
It was about breaking down complex problems into smaller solvable problems.
That was something I already understood from business and finance.
I just needed to learn how to translate those problems into software.
Building With Real-World Domain Knowledge
I believe one of my biggest advantages was that I wasn't starting with technology alone.
I already understood the problems I wanted to solve.
I understood lending workflows.
I understood the frustrations of financial institutions.
I understood that money movement requires more than a beautiful user interface.
You have to think about things like:
• What happens when a payment fails?
• What happens when a transaction is duplicated?
• How do you reconcile mobile money transactions?
• Who should approve a loan?
• What happens when an employee makes a mistake?
• How do you maintain an audit trail?
• How do you prevent unauthorized access?
• How do you design a system that works for one institution but can also serve many?
Those questions pushed me deeper into software development.
Eventually, I moved from simply building features to thinking more seriously about systems architecture, scalability, integrations, security and multi-tenancy.
From Frustration to a Live SaaS Platform
Today, that journey that started in July 2025 has resulted in something I am incredibly proud of.
I have built an all-in-one SaaS core banking platform called Loanspur CBS.
The platform is designed for financial institutions and lending organizations, bringing together lending, customer management, payments, reporting and other operational tools into one ecosystem. The platform currently supports more than 22 non-bank financial institutions, according to my own operational records, while the product continues to evolve. (Loanspur)
And honestly, I don't consider it "finished."
I don't think software like this is ever truly finished.
Every client introduces a new challenge.
Every integration reveals another edge case.
Every production issue teaches you something that no tutorial ever could.
That is probably the most important lesson I have learned so far.
Learning by Building Is Different
There is a lot of discussion about the best way to learn software development.
Should you:
• Complete online courses?
• Get a computer science degree?
• Learn algorithms first?
• Master one programming language?
• Build projects immediately?
My experience has been simple:
Building a real product for real users forces you to learn things you may never learn from tutorials alone.
When your application has actual users, "good enough" changes.
A broken button is no longer just a broken button.
A failed payment might affect someone's business.
A database mistake might affect financial records.
An API outage might stop an entire workflow.
Suddenly, you start caring about:
• Logging
• Monitoring
• Backups
• Error handling
• Security
• Testing
• Database performance
• Deployment strategies
• User permissions
• Audit trails
Real users are incredibly effective teachers. 😂
The Rise of AI Has Made This Journey Even More Interesting
I am also building during a fascinating period in software development.
AI coding assistants have dramatically changed how people can approach development.
Tools can now help developers:
• Understand unfamiliar codebases
• Debug errors
• Generate boilerplate
• Explain documentation
• Refactor code
• Write tests
• Explore unfamiliar technologies
But I have also learned something important:
AI can generate code, but understanding the problem remains a human responsibility.
You still need to know what you are building.
You still need to understand your users.
You still need to recognize when an AI-generated solution is wrong.
And in financial technology, where mistakes can have serious consequences, blindly copying generated code is definitely not an option.
My Biggest Question for the DEV Community
This brings me to why I wanted to write my first post here.
I am curious about something.
There are probably many people who, like me, entered software development because they had a problem they desperately wanted to solve.
So I would love to hear from you:
What brought you into software development?
Was it:
• A passion for technology?
• A career change?
• Curiosity?
• Frustration with an existing product?
• A business problem you wanted to solve?
• Or did you accidentally become a developer while trying to build something else?
And for experienced developers:
What is one lesson you wish you had learned before building your first serious production application?
I'm looking forward to learning from this community and sharing more about my journey building software for the financial services industry.
This is my first post here.
Hopefully, it is the beginning of many conversations.
Top comments (0)