123 Pocket Loans

This was a project for a financial institution specializing in payday loans. Created with ReactDjango REST Framework and PostgreSQL. Hosted on a fancy Kubernetes cluster with Digital Ocean


123 Pocket Loans approached me in need of a software project for their microloans business. The system needed to allow potential clients to apply for loans on the website, allowing them to enter their information and upload any relevant files for their application to be submitted to 123 Pocket Loans. This system also needs to have the ability to  pre-approve loans, manage debit orders and have a record of which debit orders were successful or unsuccessful. This was initially going to be a manual process, but I started envisioning ways to automate all of this functionality.

I submitted a proposal and quotation which was subsequently accepted. 


We started off with some initial planning for what the site needed to do. Having created a basic list of features and done some project planning, I created an initial design of the website, and I created a Digital Ocean server with their application running in Docker on it for demo purposes. This allowed us to stay in sync with where the system is at and how it looks in the early stages of development.
Having a testing environment up and running at an early stage also enabled the client to test the system and provide feedback as we went along, rather than having to sit down with me every week for a demo and not really having a chance to use and experience their own system.
Through a process of consultation, I developed the features required for their system from start to finish and was eventually ready to go live with it, with the client’s satisfaction. 


As this is a financial application, some SOAP integration had to be done. Yes, it felt like coding in the 80’s, but I understood that this would be a requirement for integration with financial services. Other than that, we also integrated with AWS for emails (using SES) and Clickatell for SMS sending. We chose Clickatell’s slightly more expensive SMS service because AWS seemed to have issues sending SMS messages to some South African mobile numbers.. Having used Clickatell before, I knew that they are incredibly reliable and have a great support team.


The project was eventually ready for production with enough features completed and ready for consumer use. The only caviat with this was that the SOAP integration testing environment was not a very good sandbox, so the responses were tested based on mocked responses and unit tests. This meant that we had to hope that the production integration environment would respond the same as the testing one.

Fortunately, everything seemed to work fine. The growing pains were minor.. The integrations needed some tweaking from the service provider’s side, but it was smooth sailing other than that.
For a the production release, I decided to make use of a managed database with DigitalOcean. For the application’s frontend and backend, I opted for Kubernetes to allow the system to scale as and when it needed to. I set up the cluster and got all the services deployed onto the cluster and – with a sigh of relief after a few hours of setup – everything worked the first time. I opted to use Digital Ocean because of the ease of management and the great value for money.  


As with any other application out there, there are minor issues from time to time. I use Sentry to track errors on the frontend and on the backend. It has been instrumental in finding bugs and showing me where in my code they happened, enabling faster fixes. I also make use of LogRocket to replay users’ sessions so that it’s easier for me to reproduce issues on my local development environment. I can then also identify which users had an issues so that the product owners can get in touch with them and help them out if that’s needed.
Since the system runs in Kubernetes, there’s no downtime during deployments, which makes it pretty stress-free. 


I was already pretty well versed in React and Django prior to this project. I learned about multistage builds in Docker to make builds more efficient.
I also learned all about global error handling with React using error boundaries, which makes it really easy to show users a generic error page when something goes wrong. Since the information in this system is sensitive, I chose to go with more vague error messages for general users, opting to show more specific error messages to admins when appropriate and useful.
During the lifecycle of the project, the React team also released Suspense as part of the project, so I started playing around with the idea of code splitting. This has always been something that seemed daunting to me, but it turned out to be easy to do with Suspense.