Model the service request first
The marketplace is designed around service requests and their lifecycle, rather than assuming every request already belongs to a provider. This supports a more flexible matching workflow.
Independent project // Case study 01
DoLocal.
Exploring how people in Botswana could discover and arrange local services through one structured marketplace.
Botswana-focusedUnder developmentIndependent project
Role
Independent developer
Focus
Product and application engineering
Status
Under development
01 · Context
The problem space
Finding a suitable local service can involve scattered recommendations, unclear availability, and conversations spread across different channels. DoLocal explores a more organised way for customers to request services and for providers to manage the resulting work.
The initial market focus is Botswana. The product remains in development; this is a product direction, not a claim that the marketplace has launched or reached paying customers.
02 · Design
Decisions that shape the system
Keep roles and ownership explicit
Provider identity, account roles, and resource ownership are treated as distinct concerns. Access rules help ensure that users interact only with resources they are permitted to access.
Represent order outcomes clearly
The order lifecycle distinguishes different outcomes and financial states. Payment-related architecture remains separate from any claim that real payments have been processed.
02b · Lifecycle
How a request becomes an outcome
Service request
A customer describes a needed service. Requests exist independently of any provider.
Provider matching
The design goal is a flexible workflow that matches a request to a suitable provider rather than pre assigning one.
Order
The workflow can progress from a service request to an order with an explicit owner and permitted actors.
Outcome
The order lifecycle distinguishes different outcomes and financial states.
Access control throughout
Provider identity, account roles, and resource ownership stay distinct; access rules apply at every stage.
Simulated payments only
Payment related work uses architecture and simulated provider flows. No real customer payments processed.
DoLocal is under development. This diagram shows design direction, not a launched marketplace; implemented functionality and planned work are described in 03 / Scope below.
03 · Scope
What the project covers
Built so far: marketplace workflows, service request and order lifecycles, provider screens, access control, API design, and data modelling. Payments are architecture and simulated flows only: no real customer charges.
Features listed here are built and checked; roadmap items are not claimed as done.
04 · Reflection
Building beyond the interface
This project gives me a place to think about the relationships between product requirements, domain rules, data models, permissions, and user workflows. It also reinforces the need to validate each change rather than treating a planned feature as evidence that it works.
Next · Case study 02
See the work in a team environment
My internship at Gabs Eats gives me experience contributing to an existing platform alongside other developers.