Building a fintech product from scratch. Every decision documented.
Paylio took twelve weeks from problem definition to a live, interactive product. This is the process: what worked, what was rebuilt, and why.
9
Marketing pages
5
App screens
40+
Components
1
Codebase
The process
Four phases, twelve weeks.
01
Problem definition
2 weeksStarted by mapping the failure modes of existing Nigerian banking apps. Three consistent problems emerged: transfer delays with no feedback, zero spending visibility, and card management locked behind bank branches. These became the product brief.
Key insight
Ran informal interviews with 20 people across Lagos. Common pain: "I send money and I do not know if it went." The anxiety of uncertainty was as damaging as actual delays.
02
Design system
3 weeksBuilt a dark, premium design system before touching a single screen. Navy palette, teal accent at exactly #14B8A6, Plus Jakarta Sans typeface. Established spacing, radius, shadow, and motion tokens. Then froze them.
Key insight
The constraint of a locked design system forced every later decision to be deliberate. No one-off colours, no ad-hoc sizing. This is why the finished product feels visually consistent across every screen.
03
App screens
4 weeksFive screens: Home, Transfer, Insights, Security, Cards. Each treated as a separate design and engineering problem. The transfer flow went through six iterations before the three-step model (recipient, amount, confirm) was settled.
Key insight
The spending donut chart on Insights was rebuilt three times. The first two versions were accurate but did not communicate meaning at a glance. The third version added percentage labels and colour-coded legend, and that passed.
04
Marketing site
3 weeksNine-page full-width marketing site built after the app was complete. The brief: sell the product clearly, show the product honestly, never mislead about what Paylio actually is as a portfolio piece.
Key insight
The phone mockups on the marketing site render the actual app components, not screenshots. This was a deliberate choice: the marketing site and the demo share one codebase, so they never go out of sync.
Tech stack
One codebase, two experiences.
The marketing site and the demo app live in the same Next.js project, separated by route groups. The app components are used directly inside the marketing mockups, so the two never go out of sync visually.
Route group (marketing) handles the nine full-width pages. Route group demo/(app) constrains the mobile UI to a 430px shell with its own layout and bottom nav. Both share one design system and one globals.css.
Framework
Next.js 16 App Router
Language
TypeScript
Styling
Tailwind CSS v3.4
Runtime
React 19
Build
Turbopack
Routing
Route groups (marketing), (app)
Deploy target
Vercel
Custom tokens
navy, teal, shadow-teal
Design decisions
Three choices that defined the result.
Dark-first, always
Nigerian mobile users skew heavily toward AMOLED screens. A dark UI saves battery, reduces eye strain at night, and allowed the teal accent to carry significantly more visual weight than it would on light backgrounds.
Tabular numerals on all monetary figures
Numbers in financial interfaces shift horizontally when they change value, which creates visual instability. Setting fontVariantNumeric to tabular-nums on every monetary display keeps columns aligned and eliminates jitter.
Phone mockup renders real app components
On the landing page and features page, the phone mockup is not a static screenshot. It renders actual TSX components from the app. This meant one fewer artifact to maintain and zero risk of the marketing site showing an outdated UI.
See the finished product.
The demo is live. Every screen, every interaction, fully built.