Papyr

A notebook for small businesses that keeps the books for you.

Product · Engineering in active development

The problem

Small businesses in Nigeria keep their daily records in paper notebooks. It’s cheap, natural, and works offline — but paper gets lost, can’t be searched, and never adds itself up. Spreadsheets fix the math but break the habit: they demand typing, layouts, and a mental model of columns most shopkeepers never signed up for.

The product

Papyr is a notebook that happens to be digital. You write in it the way you already write — with a stylus or mouse, cell by cell — and the software does the bookkeeping: running totals, daily summaries, search, and sync across devices. The records stay yours, even when the network doesn’t.

The engineering

Handwriting input on a canvas, with stroke capture and per-cell recognition that turns written entries into numbers and text the ledger can trust. Offline-first storage with a sync queue that reconciles when connectivity returns. Built with low-end Android in mind, where every megabyte and frame matters.

Decisions

Offline-first, always. A ledger that loses a day’s records because the network blinked is worse than paper.
Handwriting stays the primary input. It’s the barrier to entry for the actual user — a trader or shopkeeper, not a spreadsheet person.
Low-end Android first. The people keeping paper ledgers are not on flagship phones.
The product model decides the stack. Recognition accuracy and sync semantics drive the architecture, not the other way around.

The hard parts

Stroke recognition fast and light enough for low-end devices. Per-cell recognition accurate enough that the numbers in a ledger can be trusted. A sync model that resolves offline edits without losing or double-counting money. And a writing experience that feels like pen on paper — not a text box with extra steps.

Status

In active development. Designed, architected, and built by me.

show me the engineering →hide it ←

Architecture

Next.js app with a service-based sync layer; the ledger itself stays local.

Offline-first

All writes land locally first; nothing blocks on the network.

Canvas

Handwriting rendered and captured on an HTML canvas.

Stroke recognition

Strokes captured and interpreted on-device, within a low-end Android budget.

Per-cell recognition

Each written cell is recognised into numbers and text the ledger can trust.

Sync queue

Edits queue locally and reconcile when connectivity returns.

Supabase

Auth, data, and the sync relay when the device is online.

Next.js

App shell, routing, and the web client.

Stack: Next.js · React · Canvas API · Supabase · IndexedDB · PWA

next — Olakz

all work

03

Olakz

A multi-service super-app — one codebase, 10+ services.

Software Engineer · MobileOlakz LogisticsLagos10/2025 – 05/2026

The problem

A super-app has to carry many different services — ride-hailing, food, marketplace, auto wash and mechanic, spare parts, airtime and data, transport hire — inside one app without collapsing into a pile of disconnected screens. Every service has its own flows, states, and data shapes, and it all has to feel like one product.

My role

I led the mobile frontend build. I designed the application architecture, the UI system, and the navigation structure from the ground up, then carried it through to API integrations, maps, authentication, and global state across every service.

The engineering

React Native with TypeScript. A shared component and UI system so new services don’t reinvent the same screens. Redux Toolkit and Zustand for state, React Navigation for structure, Axios against the REST APIs, and Google Maps and AirMap for location flows. Component reuse, code optimization, and strict Git workflows to keep the codebase sane as it grew.

Decisions

One UI system for every service. Consistency is the product — ten services should feel like one app.
Navigation designed to scale. Service entry points added without reworking the structure.
State service-local by default. Global state only where flows genuinely share it.
The frontend and the API negotiate. I worked with backend engineers on endpoint design so the app didn’t fight the interface.

The hard parts

Keeping ten-plus services coherent in a single codebase. Maps and location flows that behave on real devices. Performance on low-end Android. And integration patterns consistent enough that each new service took days, not weeks.

The result

A shipped mobile app for a high-traffic multi-service platform — a production codebase built, structured, and maintained under real engineering workflows.

show me the engineering →hide it ←

Architecture

One shared UI system and component library across every service.

State

Redux Toolkit and Zustand; service state kept local where possible.

Navigation

React Navigation structured to scale as services were added.

API layer

Axios against REST endpoints, consistent patterns per service.

Maps

Google Maps and AirMap for location and ride flows.

Auth

Session and token flows wired across the app.

Performance

Component reuse and optimization for low-end Android devices.

Workflow

Strict Git practices and close pairing with the backend team.

Stack: React Native · TypeScript · Redux Toolkit · Zustand · React Navigation · Axios · Google Maps / AirMap · REST APIs · Git

next — Semicolon

all work

04

Semicolon

Banking, rental, and full-stack engineering.

Software Engineer · BackendSemicolon AfricaYaba, Lagos2024 – 2025

The problem

Banking software runs on trust. Authentication has to be airtight, roles have to be enforced, and money movements have to survive mistakes. I wanted to build systems where that was true by design — not by accident.

My role

Designed and implemented the backend services for three systems: a banking platform, a rental application, and estate management tools.

The engineering

Lite Bank Platform — secure REST APIs for core banking workflows on Node.js, NestJS, and PostgreSQL. Role-based access control, authentication for customers and admins, optimized queries, TDD, and CI/CD.
Rental Application — Java, Spring Boot, and PostgreSQL. JWT authentication, role-based authorization, booking and order management, payments through Paystack, and notifications through Twilio and EmailJS. Unit and integration tests throughout.
Estate Gate Pass and Hotel Management — responsive full-stack applications with secure API integrations.

Decisions

TDD from the start. The API is the contract, and tests are how it stays honest.
Model the data before writing queries. Relational structure that stays fast as tables grow.
Optimization is part of the build. Not a cleanup phase at the end.

The hard parts

Getting auth and role-based access right when the cost of a mistake is someone’s money. Payment flows that must never double-charge. Notifications that actually arrive. And CI/CD pipelines that don’t fail on Friday.

The result

Production-style systems built under real constraints — security, money, notifications, and the discipline to test all of it.

show me the engineering →hide it ←

Auth

JWT flows for customers and administrators.

Authorization

Role-based access control on sensitive operations.

Data

PostgreSQL, structured relational modeling, optimized queries.

Payments

Paystack integration for booking and rental payments.

Notifications

Twilio and EmailJS for transactional communication.

Quality

Unit and integration tests as a non-negotiable.

Delivery

CI/CD pipelines for reliable deployments.

Runtimes

Node.js / NestJS and Java / Spring Boot side by side.

Stack: Node.js · NestJS · Java · Spring Boot · PostgreSQL · MongoDB · JWT · RBAC · Paystack · Twilio · Docker · CI/CD

next — UrbanFix

all work

05

UrbanFix

Service and repair, without the guesswork.

Product in active design

The problem

Getting something fixed in a city is a trust problem. Finding someone competent, agreeing on the work, trusting the price, and knowing the job actually got done — every step has a failure mode. Word of mouth is the only filter most people have.

The product

UrbanFix is a product I’m designing around that problem — a platform that makes finding, booking, and tracking a repair or service straightforward: clear scopes of work, agreed prices, and a paper trail instead of handshakes.

The engineering

I’m working through the product model before the code: which services live on the platform, how a job flows from request to quote to completion, how payments and disputes behave, and what the data model has to hold for all of it. The design decisions come first; the stack follows from what the model actually demands.

Decisions

The product model comes first. A jobs platform stands or falls on its workflow, not its framework.
Trust is the core feature. Verification, transparent quotes, and a clean dispute path are the product.
Keep the scope honest. One clear problem at a time, rather than a platform trying to be everything.

Status

A concept in active design. I’m validating the service model and workflows before committing to a stack — the model is the part that’s actually hard.

show me the engineering →hide it ←

Product model

Service taxonomy and marketplace mechanics designed first.

Workflow

Request → quote → job → payment → review, mapped end to end.

Trust

Provider verification and a transparent dispute path.

Data

Jobs, quotes, payments, and history — the shape the model demands.

Platform

Stack to be decided by what the model actually needs.

Stack: To be decided — the product model comes first.

next — InvestNaija

all work

06

InvestNaija

A Nigerian fintech platform — banking, investments, crypto trading.

Designed & developedReact · TypeScript · Node.js

The problem

Financial services in Nigeria are fragmented across apps — banking here, investments there, trading somewhere else — each with its own signup, its own rules, and its own way of losing track of your money.

My role

Designed and developed the platform. I led the React and TypeScript frontend and integrated it with the Node.js APIs.

The engineering

A fintech frontend covering core banking, investments, and crypto trading — account views, transactions, portfolio positions, and the flows that move money between them. Built in React and TypeScript against Node.js services, with authentication and session handling wired end to end.

Decisions

Security and scalability are features. Treated as part of the build, not an afterthought.
One design system, separate domains. Banking, investments, and trading share a look without tangling their logic.
Validated at scale. Optimized and tested against 500+ simulated users.

The hard parts

Money movement across three financial domains. Keeping auth and sessions secure without slowing real users down. And structuring the frontend so three product areas could be built in parallel without fighting each other.

The result

A working fintech platform, optimized for security and scalability and validated against 500+ simulated users.

live app →

show me the engineering →hide it ←

Frontend

React and TypeScript, one design system across three domains.

APIs

Node.js services behind the banking, investment, and trading flows.

Domains

Core banking, investments, and crypto trading in one platform.

Auth

Secure sessions and authentication wired end to end.

Scalability

Validated against 500+ simulated users.

Security

Hardening treated as a feature, not an afterthought.

Stack: React · TypeScript · Node.js · REST APIs · Auth

next — Splitcore

all work

01

Splitcore

Financial infrastructure for entertainment payments in Nigeria, starting with QR-code digital tipping for nightlife.

Product · Engineering in active development

The problem

Entertainment payments in Nigeria still rely heavily on cash and informal handoffs. A guest should be able to support a DJ, dancer, or performer directly without carrying cash, downloading an app, or knowing anyone’s bank details.

The product

Splitcore is financial infrastructure for entertainment payments in Nigeria, starting with QR-code digital tipping for nightlife venues. Underneath the simple scan is a double-entry ledger, role-based access control, and Paystack-based payouts.

The engineering

The core backend and domain model cover venues, entertainers, QR codes, payment splitting, and payout flows. It is built with NestJS, PostgreSQL and Prisma, Redis and BullMQ, and deployed on Render.

Decisions

The ledger is the source of truth. Payment state and splits need an auditable model rather than scattered transaction updates.
Keep the first interaction frictionless. QR tipping should work without an app download or exposing bank details.
Separate domain roles clearly. Venues, entertainers, and platform operations have different permissions and responsibilities.

Status

In active development — core backend and domain model (venues, entertainers, QR codes, payment splitting) built and deployed; not yet publicly launched.

API docs →

show me the engineering →hide it ←

Backend

NestJS and TypeScript for the API and domain services.

Ledger

Double-entry records for payment splitting and payout history.

Data

PostgreSQL with Prisma for structured relational models.

Queues

Redis and BullMQ for asynchronous payment and payout work.

Payments

Paystack-based payment collection and payouts.

Deployment

Backend services deployed on Render.

Stack: NestJS · TypeScript · PostgreSQL · Prisma · Redis · BullMQ · Paystack · Render

next — Papyr

Quayyum Ariyo

Work

Experience

Things I work on

Backend

Systems

Product

Engineering

About

Contact

The problem

The product

The engineering

Decisions

The hard parts

Status

The problem

My role

The engineering

Decisions

The hard parts

The result

The problem

My role

The engineering

Decisions

The hard parts

The result

The problem

The product

The engineering

Decisions

Status

The problem

My role

The engineering

Decisions

The hard parts

The result

The problem

The product

The engineering

Decisions

Status