Chapter ONE.txt

Chapter ONE
INTRODUCTION
	BACKGROUND OF THE STUDY
In Nigeria, the informal economy remains a critical engine of employment and livelihood, particularly for the low-income earners and micro-entrepreneurs. Within this space the transportation sector stands out as one of the most vibrant and accessible avenues for economic participation. Vehicles such as tricycles (Keke) and minibuses serve as indispensable tools for the daily commuting in both urban and semi-urban centers.
However, the high cost of acquiring these vehicles outright places them beyond the financial reach of many aspiring drivers and small-scale transport operators.
To bridge this gap, the hire-purchase system has emerged as a widely adopted financing model. Under this arrangement, a vehicle owner (often referred to as the “Oga”) allows a driver to operate the vehicle in exchange for an initial deposit and daily or weekly installment payments over a fixed period. At the end of the payment term, ownership of the vehicle is transferred to the driver. This system has empowered thousands of Nigerians to enter the transport business without upfront capital, thereby reducing unemployment and fostering economic resilience at the grassroots level.
Despite its socio-economic importance, the current hire-purchase model is plagued with inefficiencies rooted in its manual, paper-based, and largely informal nature. Transactions are typically recorded in notebooks, agreements are verbal or loosely documented, and there is minimal oversight or accountability. This lack of structure creates fertile ground for disputes, drivers may lie about making payments, owners may manipulate records, and neither party has a verifiable proof to fall back on. The absence of standardized contracts, payment tracking, and performance analytics further compounds the problem, leading to high default rates, strained relationships and lost investments.
Moreover, the current system offers no credit history or financial footprint for the drivers. Even after years of consistent payments, drivers remain financially invisible to formal lending institutions, locking them out of opportunities for business expansion, asset acquisition, or access to microloans. Similarly, vehicle owners lack tools to assess risk, track performance, or scale their operations efficiently.
	STATEMENT OF PROBLEM
	Poor driver vetting and high investment risk: 
We want a hire-purchase system where vehicle owners can make safe and informed investment decisions based on transparent, objective and data-driven assessments of drivers, reducing defaults and building a long-term trust between both parties.
Vehicle owners rely on informal recommendations and judgement due to absence of standard driver evaluation criteria. This exposes them to high financial risks, frequent driver defaults and unreliable partnerships. If we ignore this problem, investment losses will continue to rise and hire-purchase model will remain unstable and unscalable.
We will design a structured, data-driven driver assessment framework supported by automated risk-assessment algorithms to provide objective evaluations and reduce investments risks.
	Manual and inefficient record keeping:
We want a fully digital, transparent and tamper-proof record keeping system where all payment activities are accurately tracked, securely stored and easily accessible, eliminating disputes and administrative stress.
Today, payment records are kept manually in exercise books, making them vulnerable to errors, manipulation, loss, and damage. This creates frequent payment disputes and administrative burdens for both owners and drivers. If we ignore this problem, inefficiencies will grow, disputes will escalate, and accountability will remain weak.






	AIM AND OBJECTIVES OF THE STUDY
The primary aim of this study is to design and implement a data-driven platform for managing hire purchase system in the Nigerian transportation sector.
Objectives:
	To design a comprehensive web-based platform architecture for managing hire purchase transactions.
	To develop a predictive risk assessment model using logistic regression for driver evaluation.
	To implement the data-driven platform using modern web technologies.
	To evaluate the system performance.
1.4 SCOPE OF THE STUDY
To make sure this project is achievable within the timeframe of a final year project, I am setting clear boundaries. What this project will cover:
	A web portal for vehicle owners to manage their fleet and driver applications.
	A web portal for drivers to apply for vehicles.
	A backend built with Django that handles all the business logic.
	A database using PostgreSQL to securely store all the information.
	Core features: user registration, adding vehicles, tracking payments, and a prototype risk-scoring model based on sample data.





1.5 SIGNIFICANCE OF THE STUDY
This study is significant because it addresses a long-standing issue in Nigeria’s transportation financing ecosystem and provides practical solutions that benefit multiple stakeholders. 
For vehicle owners and investors, the research offers a digital framework that enhances decision-making through reliable risk-assessment tools while reducing administrative burden through automated, tamper-proof record-keeping. These improvements help safeguard investments, minimize fraud and reduce the likelihood of payment defaults.
Commercial vehicle drivers also stand to benefit, as the platform introduces fairness and transparency into the hire-purchase process. The accurate tracking of payment obligations and progress eliminates disputes and enables drivers to build verifiable credit histories that can support better financial opportunities in the future.
The study is equally important to the broader transportation sector because a more transparent and efficient hire-purchase model can strengthen trust, attract increased investment in commercial vehicles, and potentially expand transport services, thereby creating more employment opportunities. 
Finally, the research contributes to the academic and research community by providing insight into the application of information systems and predictive analytics within developing economies. It offers a practical case study that can inspire further studies on fintech-driven solutions for informal economic structures.







1.6 LIMITATION OF THE STUDY
It's important to be realistic about what this project can achieve and the challenges it faces.
	The Data Challenge: The risk model will be built using a sample or hypothetical dataset. To make it truly accurate in the real world, it would need a lot more historical data, which is difficult to get.
	Internet Access: The solution depends on users having a smartphone or computer and a decent internet connection, which can still be a barrier for some people.
	Changing Habits: Convincing people to switch from a system they've used for years (even with its flaws) to a new digital app is a major challenge that goes beyond just building the software.
	Time Constraints: As this is a student project, only the most important features will be built. Other good features will have to be left for future updates.
1.7 Definition of Terms
Informal Economy: The informal economy (also called the informal sector or shadow economy) refers to economic activities that are not regulated or protected by the government. They do not provide workers with social protections (like pensions, health insurance, or paid leave)
Data-Driven Platform: A software system that uses collected and analyzed data to inform decision-making processes, automate operations, and provide insights to users.
Hire-Purchase System: A financial arrangement where an asset is acquired through an initial deposit followed by regular installment payments until full ownership is transferred to the purchaser.
Risk Assessment Model: A statistical algorithm that evaluates the probability of payment default or other adverse outcomes based on available applicant information.
Oga: A colloquial Nigerian term referring to a boss, owner, or investor; in this context, specifically referring to vehicle owners who provide vehicles through hire-purchase arrangements.
Keke/Tricycle: A three-wheeled commercial passenger vehicle commonly used for short-distance transportation in Nigerian urban and semi-urban areas.
Stakeholders: All parties with direct or indirect interest in the hire-purchase system, including vehicle owners, drivers, passengers, transport unions, and regulatory authorities.
Credit History: A record of an individual's past borrowing and repayment behavior that indicates their reliability in meeting financial obligations.
Predictive Analytics: The use of statistical algorithms and machine learning techniques to identify future outcomes based on historical data patterns.
















Chapter TWO
Literature review
This chapter presents a comprehensive review of existing literature relevant to the design and implementation of data-driven platforms for managing hire-purchase systems in the transportation sector. The review examines theoretical foundations, technological frameworks and empirical studies that inform the development of digital solutions for informal financial arrangements. The chapter is structured to provide theoretical background, review related works, identify research gaps, and establish the conceptual framework for this study.
2.1 Theoretical Background
To properly understand the challenges and design a good solution, we can use some established theories as tools to guide our thinking. These ideas come from economics, information systems, and computer science.
2.1.1 The Concepts
These concepts help us understand the human and economic reasons behind the problems in the hire-purchase system.
Information Asymmetry Theory
Akerlof (1970) introduced the concept of information asymmetry in his seminal work "The Market for Lemons," demonstrating how information imbalances between parties can lead to market inefficiencies and adverse selection problems. In the context of hire-purchase arrangements within Nigeria's transportation sector, vehicle owners face significant information deficits regarding potential drivers' reliability, financial discipline, and character (Stiglitz, 2000). This asymmetry creates substantial investment risks and contributes to high default rates in informal vehicle financing arrangements.
The theory suggests that markets with severe information asymmetries may experience market failure or operate at suboptimal efficiency levels (Rothschild & Stiglitz, 1976). Digital platforms can potentially address information asymmetry by creating standardized data collection mechanisms, establishing transparent evaluation criteria, and maintaining comprehensive transaction histories that benefit both parties in hire-purchase agreements.
Agency Theory
Jensen and Meckling (1976) developed agency theory to examine relationships between principals and agents in situations where the agent acts on behalf of the principal. In hire-purchase arrangements, conflicts of interest may arise when drivers' objectives diverge from owners' interests, particularly regarding vehicle maintenance, usage patterns, and payment obligations (Eisenhardt, 1989).
The theory suggests that effective monitoring mechanisms and aligned incentive structures can mitigate agency problems (Fama, 1980). Digital platforms can serve as monitoring tools by tracking payment behaviors, providing transparent communication channels, and creating accountability mechanisms that align the interests of both parties in hire-purchase agreements.
Technology Acceptance Model
Davis (1989) proposed the Technology Acceptance Model to explain user adoption of information systems based on perceived usefulness and perceived ease of use. Venkatesh and Davis (2000) further refined the model, emphasizing that for data-driven platforms managing hire-purchase systems to succeed in Nigeria's transportation sector, users must perceive the technology as beneficial to their operations and sufficiently user-friendly to justify the transition from traditional manual methods.
The model emphasizes the importance of interface design, functionality clarity, and demonstrated value proposition in driving technology adoption among vehicle owners and drivers who may have limited digital literacy or previous exposure to similar platforms (Venkatesh et al., 2003).
Financial Inclusion Theory
Sarma (2008) defined financial inclusion as the delivery of financial services to underserved populations at affordable costs. Nigeria's transportation sector exemplifies the challenges faced by informal economy participants who lack access to traditional banking services and formal credit mechanisms (Demirgüç-Kunt & Klapper, 2013).
Digital platforms for hire-purchase management can contribute to financial inclusion by creating alternative credit assessment methods, establishing formal transaction records, and providing pathways for traditionally excluded populations to access vehicle financing opportunities (Beck et al., 2007).
2.1.2 The Technology
This subsection presents an in-depth examination and discussion of the existing underlying technology of the project.
Web-based Platform Architecture
Modern web applications utilize client-server architecture patterns that separate presentation logic from business logic and data storage (Fielding, 2000). The implementation of hire-purchase management systems requires robust backend frameworks capable of handling complex business rules, user authentication, and data persistence (Gamma et al., 1995).
Django framework, based on Python programming language, provides a comprehensive toolkit for developing secure, scalable web applications with built-in authentication, database abstraction, and security features (Holovaty & Kaplan-Moss, 2009). The framework follows the Model-View-Template architectural pattern, promoting code organization and maintainability essential for complex financial management systems.
Database Management Systems
PostgreSQL represents an advanced open-source relational database management system that provides ACID compliance, complex queries, and data integrity features crucial for financial applications (Stonebraker & Rowe, 1986). The system's ability to handle concurrent transactions and maintain data consistency makes it suitable for hire-purchase management platforms where multiple users access and modify payment records simultaneously.
Risk Assessment Technologies
Machine learning algorithms, particularly logistic regression models, provide effective tools for binary classification problems such as predicting driver reliability in hire-purchase arrangements (Hosmer & Lemeshow, 2000). These statistical models can analyze multiple variables simultaneously to generate probability scores that inform investment decisions (James et al., 2013).
Frontend Development Technologies
React.js and Next.js frameworks enable the development of responsive, interactive user interfaces that provide optimal user experience across different devices and screen sizes (Gackenheimer, 2015). These technologies support the creation of dynamic web applications with real-time data updates and intuitive navigation patterns essential for user adoption in the transportation sector.
2.2 Review of Related Literature
Beck et al. (2007) conducted foundational research on financial inclusion barriers in developing economies, identifying key constraints that prevent informal sector participants from accessing traditional banking services. Their comprehensive analysis of 99 countries revealed that regulatory barriers, high transaction costs, and inadequate infrastructure significantly limit financial service penetration among low-income populations. The study emphasized the need for innovative delivery mechanisms to reach underserved markets, particularly in sub-Saharan Africa. While their research provided crucial insights into financial exclusion patterns, it predated the widespread adoption of mobile technology and digital platforms that have since transformed financial service delivery.
Demirgüç-Kunt and Klapper (2013) expanded on earlier financial inclusion research by conducting the first Global Findex survey, establishing baseline measurements of financial service usage across 148 countries. Their findings revealed that 2.5 billion adults worldwide remained unbanked, with particularly high exclusion rates in Nigeria and other developing economies. The study identified account ownership barriers including lack of documentation, geographic distance to financial institutions, and insufficient income as primary obstacles to financial inclusion. However, their research focused on traditional banking metrics rather than alternative financial arrangements like hire-purchase systems prevalent in informal transportation sectors.
Jack and Suri (2014) conducted a groundbreaking study on M-Pesa's economic impacts in Kenya, demonstrating how mobile money services could successfully serve previously unbanked populations. Their randomized controlled trial revealed significant improvements in consumption smoothing and risk-sharing among households with access to mobile money services. The research showed that simple, accessible technology design could drive rapid adoption in informal economic sectors. While their findings provided valuable insights into successful fintech implementation in East Africa, the study focused on person-to-person transfers rather than structured financing arrangements like vehicle hire-purchase systems.
Blumenstock et al. (2015) pioneered the use of mobile phone metadata for financial assessment in developing economies, demonstrating how call detail records could predict wealth levels and creditworthiness in Rwanda. Their machine learning approach showed that digital behavioral data could effectively substitute for traditional credit information in data-scarce environments. The study revealed strong correlations between communication patterns and economic status, suggesting viable pathways for alternative credit scoring. However, their research addressed general poverty assessment rather than specific applications to vehicle financing or transportation sector risk evaluation.
Suri and Jack (2016) provided long-term analysis of mobile money impacts, extending their earlier research to examine sustained effects over a five-year period. Their study demonstrated that mobile money access led to measurable poverty reduction, particularly among female-headed households in rural areas. The research revealed that digital financial platforms could create lasting economic benefits when properly designed for local contexts and needs. While their findings reinforced the potential for technology-driven financial inclusion, the study did not address specialized applications for industry-specific financing arrangements.
Parker et al. (2016) analyzed successful platform business models across various industries, establishing key design principles for multi-sided markets that connect different user groups. Their research emphasized the importance of network effects, trust mechanisms, and value creation for all platform participants. The study provided comprehensive frameworks for understanding platform dynamics and competitive strategies in digital markets. However, their analysis focused primarily on developed economy contexts and did not address the specific challenges of implementing platforms in informal economic sectors.
Okafor et al. (2017) examined mobile banking adoption patterns among Nigerian consumers, revealing significant correlations between educational attainment, income levels, and technology acceptance. Their study identified trust, security perceptions, and user interface design as critical factors influencing fintech adoption in Nigeria. The research highlighted the need for extensive user education and support mechanisms to drive technology acceptance among Nigerian populations. While their findings provided valuable insights into local adoption patterns, the study focused on urban, banked consumers rather than informal transportation sector participants.
Adepoju and Alao (2018) investigated factors influencing fintech adoption among small and medium enterprises in Lagos, Nigeria. Their research identified perceived usefulness, ease of use, and trust as primary determinants of technology acceptance among Nigerian business owners. The study demonstrated the critical importance of user-centered design and demonstrated value proposition in driving adoption. However, their research focused on formally registered businesses with existing banking relationships rather than informal hire-purchase arrangements common in the transportation sector.
Beck et al. (2018) examined the role of financial technology in promoting inclusive growth, identifying key success factors for fintech implementations in developing economies. Their research emphasized the importance of regulatory support, infrastructure development, and user-centered design in driving successful financial inclusion initiatives. The study provided comprehensive policy recommendations for leveraging technology to expand financial access. While their findings offered valuable guidance for fintech implementation, the research did not address specific applications for transportation sector financing or hire-purchase management systems.
Kumar and Srinivasan (2019) analyzed digital transformation impacts on commercial vehicle operations in India, focusing on fleet management systems and driver performance monitoring. Their research demonstrated significant improvements in operational efficiency and reduced disputes through automated tracking and reporting systems. The study showed how technology could streamline transportation sector operations and improve stakeholder relationships. However, their research concentrated on large fleet operators rather than small-scale hire-purchase arrangements prevalent in Nigeria's transportation sector.
Nwankwo and Eze (2020) examined technology adoption challenges among commercial vehicle operators in southeastern Nigeria, identifying infrastructural limitations and digital literacy barriers as primary obstacles to technology adoption. Their research provided valuable context for understanding the operating environment for digital platform implementation in Nigeria's transportation sector. The study highlighted the need for appropriate technology design that accounts for local constraints and user capabilities. While their research identified relevant adoption barriers, it did not propose specific technological solutions for hire-purchase financing arrangements.
Björkegren and Grissen (2020) developed sophisticated alternative credit scoring methods using mobile phone data in developing economies, demonstrating how non-traditional data sources could effectively predict loan repayment behavior. Their research showed that call detail records and mobile money transaction patterns provided valuable indicators of creditworthiness among populations lacking formal financial histories. The study presented advanced methodological approaches for credit risk assessment in data-scarce environments. However, their research focused on short-term microloans rather than longer-term vehicle financing arrangements typical of hire-purchase systems.
2.3 Research Literature Gap
The review of existing literature reveals several significant gaps that this study addresses:
Platform Integration: While separate solutions exist for payment processing, fleet management, and credit assessment, no comprehensive platform integrates these functions specifically for hire-purchase management in Nigeria's transportation sector.
Risk Assessment Methodology: Current research lacks empirical studies on predictive modeling approaches specifically designed for driver reliability assessment in hire-purchase contexts using available data sources.
Stakeholder Perspective: Existing studies typically focus on single stakeholder perspectives rather than examining the multi-party dynamics inherent in hire-purchase arrangements between vehicle owners, drivers, and platform administrators.





CHAPTER THREE
SYSTEM ANALYSIS AND DESIGN
3.0 Introduction
The previous chapters highlighted the importance of this project and the concepts that form its foundation. This chapter focuses on the methodology applied in determining the system requirements and in designing the technical framework of the "Oga Driver" platform. It explains the step-by-step process used to identify the essential features of the application, informed by research and stakeholder engagement within the transportation sector in Enugu and Anambra States. Furthermore, it presents the system design blueprints, which serve as a guide for implementation before any coding or development takes place.
3.1 Research Methodology
In system development, various methodologies guide the analysis, design, and implementation of software solutions. Common methodologies include:
	Structured System Analysis and Design Method (SSADM): A rigorous, document-driven approach often used in large-scale government or enterprise systems. It emphasizes detailed planning, data flow diagrams, and logical modeling but can be time-consuming and less flexible for agile or user-centered projects.
	Prototyping: An iterative approach where a working model of the system is developed early to gather user feedback. It is useful when user requirements are unclear or evolving, but it may lead to scope creep or premature focus on interface over architecture.
	Object-Oriented Analysis and Design Methodology (OOADM): A modern, modular approach that models the system as a set of interacting objects, each encapsulating data and behavior. It aligns well with contemporary programming paradigms (e.g., Python, Java) and supports reusability, scalability, and clear representation of real-world entities.
For this project, Object-Oreiented Analysis and Design Methodology (OOADM) was selected as the most appropriate methodology. This choice is justified by the nature of the problem domain, which involves distinct real-world entities (vehicle owner, Driver, vehicle) that naturally map to software objects with attributes and behaviors.
OOADM was deployed throughout the system development lifecycle as follows: 
	Requirement Gathering and Modeling:
Real-world actors (e.g., drivers and owners) and their interactions were identified through field observations and informal interviews in transport hubs in Enugu State. These insights informed the identification of core system objects and their relationships. 
	Object Identification and Class Modeling:
Using Unified Modeling Language (UML), key classes such as User, Vehicle, DriverApplication, and Payment were defined, along with their attributes (e.g., vehicle_cost, payment_date). This formed the foundation for the database schema and application logic. 
	Behavioral Modeling:
UML diagrams including use case, sequence, and activity diagrams were used to model dynamic interactions. For instance, the sequence diagram illustrated how a driver’s application triggers the risk assessment model and notifies the vehicle owner, ensuring a clear flow of control and data. 
	Alignment with Technology Stack:
The chosen stack Django (Python) for the backend and PostgreSQL for the database natively supports object-relational mapping (ORM), making OOADM a seamless fit. Django models directly represent the identified classes, ensuring consistency between design and code. 
3.2 Description of the Existing System
Let's look at how things are done right now, without any app. It’s a system based completely on trust, word-of-mouth, and simple notebooks.
The process usually goes like this: An investor ("Oga") buys a Keke and then needs to find a driver. They'll ask friends or union members for recommendations. The vetting process is just a gut feeling. If they agree, it’s often just a handshake deal on the price and payment schedule. The driver gets a small exercise book to track his payments. The owner has his own master copy. Every day or week, the driver pays in cash, and the owner ticks it off in the book. If there's a problem, like a missed payment or an argument over the balance, it's settled by involving elders or transport union leaders.
3.2.1 Weaknesses of the Existing System
It doesn't take long to see the problems with this old way of doing things:
	Notebooks Get Lost or Damaged: An exercise book is not a professional ledger. A simple drink spill, a misplaced book, or damage from the rain can wipe out months of important financial records.
	It’s Based on Guesswork: Owners have no real way of knowing if a driver will be reliable before handing over an asset worth over a million Naira. It’s a huge gamble every single time.
	Constant Arguments ("He Said, She Said"): Without one central, undeniable record, it’s very easy to have arguments about how much has been paid. This is where trust breaks down and relationships get spoiled.
	It’s Inefficient: Owners waste so much time and energy manually chasing payments, checking books, and trying to figure out who has paid what, instead of focusing on growing their business.
3.3 Analysis of the Proposed System
So, how does our proposed "Oga Driver" platform fix these headaches? The idea is to build a centralized web application that handles everything automatically and transparently.
The proposed system is a client-server application that provides different interfaces for each user. It's made up of several key parts:
	The Owner's Dashboard: This is the control center for the "Oga." From here, they can add their vehicles, see all their drivers, track who has paid and who is overdue, and view applications from new drivers.
	The Smart Vetting Tool: Instead of guessing, the app will have a feature that gives a simple risk score for each new applicant. This score is based on the information the driver provides, helping the owner make a much smarter, data-driven decision.
	Automated Record-Keeping: Every payment made through the platform is logged automatically, with a date and time stamp. This creates a single source of truth that both the owner and driver can see, eliminating arguments.
	The Admin Panel: There will also be a separate, secure area for the platform administrator to oversee the whole system, help users who have issues, and ensure everything is running smoothly.
The main advantage is simple: it brings professionalism and modern tools to an industry that desperately needs them.
3.4 Design of the Proposed System
To plan the app properly before coding, I used a standard method called Object-Oriented Analysis and Design (OOADM). It's just a structured way of thinking about the system in terms of real-world "objects" (like a User, a Vehicle) and then drawing diagrams to show how they work together. We use UML (Unified Modeling Language), which is like a universal language for drawing these software blueprints.
3.4.1 Use Case Diagram
The first question to answer is: who will use the system and what can they do? The Use Case diagram gives us a clear, high-level picture of this. It shows the "actors" and their interactions with the system.

 
Figure 3.1: Use Case Diagram for the Oga Driver System.
As the diagram shows, the Vehicle Owner is focused on managing their fleet and applications. The Driver's main actions are applying for vehicles and managing their payments. The Admin has oversight abilities to manage users and the platform.
3.4.2 Class Diagram
The next question is: what are the main "things" or objects in our system and how do they relate to each other? The Class Diagram shows this. It’s the blueprint for our database.
 
Figure 3.2: Class Diagram for the Oga Driver System.
The diagram shows our four main classes: User, Vehicle, Driver Application, and Payment. It details the information each class holds (its attributes) and how they are linked, for example, showing one User (Owner) can have many Vehicles.
3.4.3 Sequence Diagram
This diagram answers the question: how do the system's objects interact in a specific order to get something done? We'll look at the "Driver Application" process as an example.
 

 Figure 3.3: Sequence Diagram for the Driver Application Approval Process.
This diagram shows the step-by-step messages sent through the system, from a driver clicking "Apply" on the website, to the system calculating the risk, saving the application, and notifying the owner to make a decision.
3.4.4 Activity Diagram (What is the Step-by-Step Workflow?)
This diagram is like a flowchart that maps out a process from start to finish. We'll use it to map out the "Make Payment" workflow.
 Figure 3.4: Activity Diagram for the Make Payment Process.
This flowchart shows the journey: the driver starts the payment, the system communicates with the payment gateway, and then a decision is made. If the payment is successful, the system does several things at once (updates records, sends notifications) before the process ends.
	Instantiation of the model
The core of the driver credit scoring system is a logistic regression model. This model serves as a predictive risk assessment tool that evaluates the likelihood of a driver reliably fulfilling hire-purchase obligations. It is not trained on historical default data in this prototype phase but is instead configured with domain-informed coefficients to simulate a realistic, data-driven decision-making process.
Model structure
The model follows a standard logistic regression formulation:

z = β_0  + ∑_(i=1)^n▒〖βi⋅xi〗 

p = 1/(1+ e^(-z) )

Credit Score= (300+p×550), clamped to [300, 850]
Where: 
	β0 is the intercept,
	βi are feature coefficients,
	xi are scaled input features derived from KYC, payment history, and vehicle data,
	p is the predicted probability of being a reliable driver,
	The final credit score is mapped to the conventional 300–850 range used in financial risk contexts.
3.4.5 Database Design
Finally, all this planning leads to our database design. The Class Diagram (Figure 3.2) gives us the perfect map for this. We will have a table for Users, one for Vehicles, one for Applications, and one for Payments in our PostgreSQL database. The relationships (like one-to-many) will be enforced using Primary and Foreign Keys to keep the data consistent and reliable. We will use specific data types, like Decimal Field for money, to avoid any calculation errors.

 
Table 3.1. The data dictionary for user table
 
Table 3.2 The data dictionary for vehicle table
 
Table 3.1. The data dictionary for payment table

 
Table 3.1. The data dictionary for driver application table
3.4.6 User Interface (UI) Design
The User Interface is the bridge between the user and the powerful logic of the "Oga Driver" system. A good UI is crucial for success; as the Technology Acceptance Model (TAM) suggests, if the platform is not perceived as easy to use and useful, it will not be adopted, no matter how functional it is. The design philosophy for the UI is therefore centered on clarity, simplicity, and trust. The interface will be clean, intuitive, and responsive, ensuring it works well on both computers and smartphones, which is vital for users who are often on the move. The goal is to create a professional and trustworthy experience that encourages both vehicle owners and drivers to move away from the old notebook system.




3.4.6.1 Input Design
Input design focuses on making data entry as simple and error-free as possible. The "Oga Driver" platform will use a combination of standard web components to capture information accurately.
	Forms: Well-structured forms will be used for all major data entry tasks, such as user registration, kyc submission, adding new vehicles, and driver applications. Each form field will have a clear label, placeholder text for guidance, and real-time validation to prevent common errors (e.g., ensuring an email address is in the correct format or that a monetary value is entered correctly).
	Buttons and Controls: Clear, consistently-labeled buttons (e.g., "Submit Application," "Add Vehicle," "Confirm Payment") will be used for all primary actions. For choices with a limited set of options, such as vehicle type (Keke, Bus, Car) or application status (Pending, Approved, Rejected), dropdown menus will be used to reduce typing and ensure data consistency.
 
Figure 3.5: Wireframe of the Driver Application Input Form.




3.4.6.2 Output Design
Output design determines how the system presents information back to the user. The goal is to make data easy to understand at a glance, helping users make informed decisions.
	Dashboards: The primary output for logged-in users will be a personalized dashboard. For a vehicle owner, the dashboard will display key metrics like total investment value, monthly income, number of overdue drivers, and a list of pending applications needing review. For a driver, the dashboard will clearly show their total amount paid, the outstanding balance, and their next payment date.
	Tables and Lists: Information such as a list of vehicles, payment histories, or driver applications will be presented in clear, sortable tables. This allows an owner with multiple vehicles to easily find the information they need.
	Notifications and Alerts: The system will use simple, direct messages to provide feedback. For example, after a driver submits a payment, a clear "Payment Successful" message will be displayed. This immediate confirmation builds trust and reduces uncertainty.
	The Risk Score: A critical piece of output is the driver's risk score. This will be presented in a simple, visual way (e.g., a color-coded score from Low to High) on the application review page, allowing the owner to quickly assess an applicant's potential reliability without needing to interpret complex data

 
Figure 3.6: Wireframe of the Owner's Dashboard Output Design.











3.4.6.3 Home Page Design
The home page is the first impression of the "Oga Driver" platform for new visitors. Its design is focused on quickly explaining the value of the service and guiding users to the right actions.
	Clarity and Purpose: Above the fold, a clear headline (e.g., "Manage Your Hire-Purchase Business the Smart Way") will immediately communicate the platform's purpose. A short paragraph will explain the problem of manual tracking and how Oga Driver solves it.
	Call to Action (CTA): The page will feature prominent "Sign Up" and "Login" buttons. It will also have distinct sections and CTAs for the two main user types: "For Vehicle Owners" and "For Drivers," guiding each to a page that explains the specific benefits for them.
	Building Trust: The design will be professional and modern, featuring testimonials (hypothetical for the prototype) and a clear explanation of the key features, such as automated payment tracking and smart driver vetting, to build credibility and encourage sign-ups.














CHAPTER 4
SYSTEM IMPLEMENTATION
4.0 Introduction
This chapter transitions from the planning phase to the practical implementation of the "Oga Driver" system. This section details the building process, outlining the specific tools, technologies, and architectural decisions made to bring the software blueprints to life.
4.1 Choice of Development Environment
The selection of appropriate development tools and technologies is crucial for successful system implementation. Several factors influenced the choice of development environment for the Oga Driver platform, including scalability requirements, security considerations, development efficiency, and long-term maintenance capabilities.
	Backend Framework: Python (Django)
The server-side logic was built using Python with the Django framework. Think of Django as a professional-grade toolkit for building web apps. It comes with a lot of pre-built, secure components, which meant we could build powerful features quickly without having to start from scratch. This helped create a strong and safe system for handling things like applications and payments.
	Frontend Framework: Next.js (React)
The user interface (the client-side) was developed using Next.js, a popular framework built on React. Next.js was selected for its capability to create fast, interactive, and user-friendly web applications. Its features, such as server-side rendering and static site generation, contribute to better performance and a smoother user experience, which is crucial for technology adoption.
	Database Management System: PostgreSQL
When you're dealing with people's money and payment histories, you can't afford any mistakes. That’s the reason for using PostgreSQL as the database. It’s like a digital Fort Knox it's famous for being extremely reliable and for keeping data safe and consistent. This was the perfect choice to make sure that every payment is recorded accurately and the numbers always add up
	Version Control: Git
All source code for the project was managed using Git, a distributed version control system. This allowed for systematic tracking of changes, collaboration, and maintaining a complete history of the project's development, which is essential for good software engineering practice.
	Code Editor: Visual Studio Code (VS Code)
VS Code was the primary integrated development environment (IDE) used for writing code. Its extensive library of extensions for Python, JavaScript, and database management streamlined the development process.
4.2 Implementation Architecture
This section presents the architecture of the implemented “Oga driver” platform, including its deployment platform, system components, and interconnections between modules. The architecture follows a three-tier structure: the presentation tier, middle tier, and data tier.
4.2.1 System Architecture
The platform was developed using a 3-tier architecture (figure 4.1) consisting of the following layers:
	Presentation tier: This layer represents the user interface (UI) of the system where users interact with the application. It was designed using Nextjs (React), which generates dynamic HTML content. It allows vehicle owners, drivers and administrators to access the platform through any web browser.
	Middle Tier: the middle tier serves as the business logic layer. It connects the frontend with the database, processes user requests, applies business rules (risk scoring and validation), and returns the results to the client. This layer was developed using python’s Django framework, which provides secure, scalable, and efficient server-side functionality.
	Data Tier: The data tier handles persistent data storage and retrieval operations. The PostgreSQL database management system was used for data handling, storing details such as user accounts, vehicle records, payment transactions and application data. It ensures data accuracy, security, and reliability.







Figure 4.1 Systems architecture
4.2.2 Program Modules
The platform consists of several program modules that interact to achieve the system objectives. The major modules include:
	User management module: handles registration, authentication, and role-based access (driver, owner, admin).
	Vehicle management module: enables owners to add and manage their vehicles.
	Driver application module: allows drivers to apply for vehicles, view application status, and receive approval/rejection.
	Payment tracking module: records and monitors all hire-purchase payments, automatically updating balances.
	Risk assessment module: uses a simple logistic model to calculate and displays a driver’s credit score
	Admin module: allows administrators to oversee the system, verify data integrity and manage users

4.2.3 Input and output format
This section describes the structure of the data that enters the “Oga driver” platform and the information produced by it. The illustrations represent symbolic or graphical forms of input and output.
Input formats
The input formats represent the data users enter into the system through the web interface. Each user category interacts with specific input fields.
User type	Input data	Purpose
Driver	Name, phone number, address, bank statement	To apply for a hire-purchase vehicle
Oga	Vehicle details (type, model name, registration number, cost, repayment duration, vehicle photos)	To register vehicles and manage contracts




 
Figure 4. driver application wireframe
Output formats
The system outputs are the processed results of the stored data, displayed through dashboards, tables and notifications.
Output type 	Description	Displayed to
Dashboard 	Displays totals (e.g, number of vehicles, applications, payments)	Oga
Recent activity 	Displays recent activity in the platform	Oga and drivers
Risk Score	Displays applicant reliability score	Oga

 
Figure 4. dashboard output
These outputs ensure transparency and allow easy monitoring of the system’s operations.

4.2.4 Product flow and information flow
Product flow
In the platform, the product is a digital hire-purchase contract, a managed relationship between a vehicle owner (Oga) and a driver through the web system.
	product: hire purchase contract
	produced by: the Oga driver platform (through digital forms and record automation)
	where it s used/sold: accessed online by registered users (owners, drivers and admins)
unlike a physical product, the platform produces a digital service that can be used anywhere in Nigeria with internet access.

Information flow
The “Oga Driver” platform facilitates continuous information exchange between users and the server. The flow of information ensures smooth management of hire-purchase transactions
Information type	From	To	Purpose
Application details	Driver	Vehicle owner (Oga)	To apply for a hire-purchase vehicle
Approval decision	Vehicle owner (Oga)	Driver	To communicate acceptance or rejection
Risk score data	System algorithm	Vehicle owner (Oga)	To 
Payment details	Driver	Platform database	To record weekly payment




Manager-by-manager matrix (information copies)
Manger/role	Information required	No. of copies	Medium
Admin manager	System analytics, total users, performance logs	1	Dashboard
Oga	Vehicle status, payment summaries, driver applications	1	Dashboard 
Driver	Payment receipts, balance updates	1	Dashboard
System database	All transactional data	1 (master)	PostgreSQL

 
 
4.2.4 Overall data flow diagram
The overall system operation is represented in the data flow diagram shown in figure SB. The diagram illustrates the flow of data among the main entities (driver, Oga, Admin) and the internal processes of the Oga drive system
 

4.3 Software Testing
To ensure the "Oga Driver" platform is reliable and functions as designed, a multi-layered testing strategy was implemented. The goal was to identify and fix bugs early in the development process.
	Unit Testing: Individual functions and components of the application were tested in isolation. For example, the Python function responsible for calculating the risk score of the driver to ensure its calculations were always accurate.
	Integration Testing: This phase focused on testing how different parts of the system work together. For instance, we tested the full workflow of a driver submitting an application through the Next.js frontend to ensure the data was correctly received by the Django backend and stored properly in the PostgreSQL database.
	End-to-End (System) Testing: This involves testing the entire application from a user's perspective. Test scenarios were created to mimic real-world usage, such as a vehicle owner logging in, adding a new vehicle, approving a driver's application for that vehicle, and verifying a payment made by the driver.

 


 

 




 

 

4.4 Documentation
This section presents the data dictionary and the installation/usage guide for the "Oga Driver" platform. The data dictionary clarifies composite variables and their constituent attributes used across the system.

Data Dictionary
- Name: Surname + Middle Name + First Name
- Address: Street + City + State + Country
- User: User ID; Full Name; Phone Number; Email; Role (Owner | Driver | Admin); Address; Password Hash; Date Joined; Status
- Vehicle: Vehicle ID; Owner ID; Type (Keke | Minibus | Car); Model Name; Registration Number; Purchase Cost; Repayment Duration (weeks); Installment Amount (weekly); Start Date; Status
- Driver Application: Application ID; Driver ID; Vehicle ID; Application Date; KYC Details (Name, Phone, Address, Bank Statement Reference); Risk Score; Status (Pending | Approved | Rejected); Decision Date; Reviewer Notes
- Payment: Payment ID; Driver ID; Vehicle ID; Payment Date; Amount; Payment Method; Transaction Reference; Balance After Payment; Period Covered (Week Number); Recorded At
- Dashboard Totals: Total Vehicles; Total Applications; Total Payments; Overdue Count; Monthly Income
- Risk Score Output: Probability; Mapped Credit Score (300–850); Risk Band (Low | Medium | High)

4.4.1 User Manual
This subsection provides the step-by-step procedure for installation and usage.

Prerequisites
- Python 3.11 or later
- Node.js 18+ (or 20+ recommended) and npm
- PostgreSQL 14+ running locally or remotely
- Git

Installation
1. Obtain the source code
   - Download or clone the project into a local folder.
2. Backend setup (Django)
   - Create and activate a virtual environment
     - Windows (PowerShell): `python -m venv .venv` then `.\\.venv\\Scripts\\Activate.ps1`
   - Install dependencies: `pip install -r requirements.txt`
   - Configure database connection
     - Set `DATABASE_URL=postgresql://<user>:<password>@localhost:5432/<database>`
     - Alternatively, set `DB_NAME`, `DB_USER`, `DB_PASSWORD`, `DB_HOST`, `DB_PORT` in environment or `.env` file.
   - Apply migrations: `python manage.py migrate`
   - Create an admin user: `python manage.py createsuperuser`
   - Start the server: `python manage.py runserver` (default `http://localhost:8000/`)
3. Frontend setup (Next.js)
   - Navigate to the frontend folder: `cd frontend`
   - Install dependencies: `npm install`
   - Configure API base URL: create `.env.local` with `NEXT_PUBLIC_API_BASE_URL=http://localhost:8000/api`
   - Start the dev server: `npm run dev` (default `http://localhost:3000/`)

Usage
1. Access the application in a browser: `http://localhost:3000/`
2. Register a new account
   - Choose role (Owner or Driver) and complete the registration form.
3. Owner workflow
   - Log in and open the Owner Dashboard.
   - Add vehicles with type, model, registration number, cost and repayment duration.
   - Review driver applications; check system-generated risk score; approve or reject.
   - Track payments; view balances, overdue items, and monthly income.
4. Driver workflow
   - Log in and submit a driver application for a selected vehicle.
   - View application status notifications (Pending, Approved, Rejected).
   - Make payments through the platform (or record payment as provided) and download receipts.
5. Admin workflow
   - Log in to the Admin panel to manage users, verify data integrity and oversee system metrics.

Notes
- Ensure PostgreSQL is running and the database credentials are correct before migrating.
- If running on separate machines, update `NEXT_PUBLIC_API_BASE_URL` to the backend host.

4.4.2 Source Code Listing (An Appendix)
Put the codes in Appendix A and sample output in Appendix B.
For source code listing and sample outputs see appendices A and B, respectively.