Skip to content

Ebitimi Ebelike / Full-Stack Developer

I build software that holds up in real time (see the Ping case study), offline (see the LearnTogether case study), and in production (see the SolarHouse NG case study).

I'm Ebitimi, a full-stack developer who leans backend. I design systems in Java and Spring Boot, and build the React and Next.js interfaces that sit on top of them.

01Introduction

Full-stack by practice. Backend by focus.

Portrait of Ebitimi Ebelike wearing a navy suit and glasses.
Ebitimi Ebelike, Lagos

Most of what I build sits on both sides of an API. On the server I work in Java and Spring Boot: authentication, access control, data and real-time messaging. On the client I use React and Next.js to turn that into something people can use.

The projects I've chosen to show keep coming back to the same questions. How does data move? Who is allowed to touch it? What happens when the network drops?

Where I'm heading: deeper into backend engineering, while still owning features all the way to the screen.

Context

Jul 2026 – now

Frontend Developer, Deexon Solutions

Built the production website for SolarHouse NG end to end. I now own its maintenance and new features.

In progress

Ping

A real-time messaging platform on Spring Boot, MongoDB and WebSocket/STOMP, with a Next.js client.

Until Apr 2027

Software Engineering Program, NIIT

Semester 3. Current focus: enterprise development with Java and Spring Boot.

02Selected work

Four projects, chosen for what they prove.

A real-time backend, an offline-first app, production client work and a full MERN build. Each one opens up to show the decisions behind it.

Ping: how a message moves

Client

Next.js

TypeScript

REST + JWTrequest / response
WebSocket + STOMPmessages, presence, read receipts

Server

Spring Boot

Java

Persistence

Data

MongoDB

  • Access control fails closed
  • Hardened media uploads
  • 26 JUnit tests
The product
A full-stack messaging app with live chat, presence and read receipts.
The problem
Chat only feels real if messages, presence and receipts arrive instantly. A messaging app also holds private conversations and user-uploaded files, so access has to be airtight.
My role
Full stack: Spring Boot and MongoDB on the backend, Next.js and TypeScript on the client.

Built with: Java · Spring Boot · MongoDB · WebSocket / STOMP · JWT · Next.js · TypeScript · JUnit

Decisions and details for Ping

Key decisions

  • JWT-secured REST APIs for request/response work.
  • WebSocket with STOMP for everything that has to be live: messages, presence and read receipts.
  • Access controls that fail closed. If access can't be confirmed, the request is refused.
  • A security-hardened pipeline for media uploads.
  • 26 JUnit tests covering the upload pipeline and access rules.

The hard part

File uploads are one of the easiest ways into an application. The upload pipeline was hardened and the access rules fail closed, with tests behind both.

02

LearnTogether

Offline-first accessible learning app

Live
LearnTogether: working without a network

Learner

Finger tracing

Touch input

Strokescustom tracing engine

App

Next.js 16

TypeScript

Persist stateon the device

Storage

IndexedDB

  • Precached by a Serwist service worker
  • Works offline
  • 340+ Vitest tests
The product
An accessible learning PWA built around a real learner with cerebral palsy.
The problem
Generic learning tools assume a generic learner. This one had to fit one specific person, and be ready whenever they are, whether there's a connection or not.
My role
Designed and built the app, including a finger-tracing engine written from scratch in TypeScript.

Built with: Next.js 16 · TypeScript · IndexedDB · Serwist · Vitest

Decisions and details for LearnTogether

Key decisions

  • Offline by default: a Serwist service worker precaches the app.
  • App state persists in IndexedDB on the device.
  • A custom finger-tracing engine, written from scratch in TypeScript.
  • 340+ tests across the app, written with Vitest.

The hard part

Designing for one real learner instead of an imagined average user. That's what led to building the tracing engine from scratch.

03

SolarHouse NG

Production website for a client

Live · client workDeexon Solutions · 2026
SolarHouse NG: from brief to live site

Brief

Social media only

No design files

Design + buildend to end

Site

Next.js 16

React 19, Tailwind CSS v4

Quote requeststhrough Drizzle ORM

Data

PostgreSQL

  • Shop page with WhatsApp ordering
  • Live in production
  • Maintained after launch
The product
The production marketing website for SolarHouse NG, with a shop and a quote request system.
The problem
The client needed a real web presence but had no design files. The only brief was their social media.
My role
Frontend Developer at Deexon Solutions. Built it end to end, and now own maintenance and new features on the live site.

Built with: Next.js 16 · React 19 · TypeScript · Tailwind CSS v4 · PostgreSQL · Drizzle ORM

Decisions and details for SolarHouse NG

Key decisions

  • Built on Next.js 16, React 19, TypeScript and Tailwind CSS v4.
  • A shop page with WhatsApp-based ordering.
  • A quote request system backed by PostgreSQL through Drizzle ORM.
  • Ongoing ownership after launch: maintenance and feature work on the live site.

The hard part

No design files. The visual direction had to come from the client's social media alone.

Apex Home Furnishings storefront showing a Featured Collections grid of sofas and chairs with prices in naira.
The product
A furniture e-commerce store built on the MERN stack.
The problem
A store only works if the unglamorous parts do: accounts, a cart that keeps its state, and products someone can actually manage.
My role
Full stack: REST API with Node.js, Express and MongoDB, and a React interface.

Built with: MongoDB · Express · React · Node.js · REST

Decisions and details for Apex Home Stores

Key decisions

  • RESTful APIs for products and the cart.
  • Authentication and product management.
  • Responsive UI, deployed to Vercel.

Also shipped

Smaller builds, all live.

03How I think

How I think about building software.

Anyone can list technologies. These are the habits behind the projects above, and each one points to where it actually happened.

  1. 01Security

    Fail closed.

    If the system can't confirm that someone is allowed to do something, the answer is no. Ping's access controls deny by default, its media upload pipeline is hardened, and JUnit tests cover both.

    Seen in

  2. 02Architecture

    Match the tool to the job.

    Ping uses JWT-secured REST for request/response work and WebSocket/STOMP for anything live. Data goes where it fits: MongoDB for Ping, PostgreSQL through Drizzle for SolarHouse's quote requests, and IndexedDB on the device for LearnTogether.

  3. 03Resilience

    Treat the network as optional.

    LearnTogether precaches itself with a service worker and keeps its state in IndexedDB, so it keeps working without a connection. That matters anywhere connectivity is unreliable.

  4. 04Testing

    Prove it with tests.

    LearnTogether has more than 340 tests. Ping has 26 JUnit tests on its security-critical paths. Tests are how I know a change didn't quietly break something I can't see.

  5. 05Product

    Build for the real user.

    LearnTogether was built around one real learner with cerebral palsy, not an imagined average user. Designing for them meant writing a finger-tracing engine from scratch.

  6. 06Delivery

    Own it after it ships.

    I built SolarHouse NG from nothing but the client's social media, then kept going: a shop with WhatsApp ordering, a PostgreSQL-backed quote system, and ongoing work on the live site.

04Stack

The stack, mapped to the work.

Grouped by layer, and tied to the projects that use it. Pick a project to see exactly what it's made of.

Show what a project uses

Used in a project on this page In my toolkit, not shown here

Backend

Where most of my current focus is.

  • Java, used in 1 project
  • Spring Boot, used in 1 project
  • REST API design, used in 3 projects
  • WebSocket / STOMP, used in 1 project
  • JWT authentication, used in 1 project
  • JPA / Hibernate, not shown in a project here
  • Node.js, used in 1 project
  • Express, used in 1 project
  • Go, used in 1 project

Frontend

The interfaces on top of the systems.

  • TypeScript, used in 4 projects
  • React, used in 6 projects
  • Next.js, used in 5 projects
  • Tailwind CSS, used in 3 projects
  • JavaScript, used in 2 projects
  • React Native, not shown in a project here

Data

Server-side and on the device.

  • MongoDB, used in 3 projects
  • PostgreSQL, used in 1 project
  • Drizzle ORM, used in 1 project
  • IndexedDB, used in 1 project
  • SQL, used in 1 project
  • MySQL, not shown in a project here

Quality & delivery

Testing, offline support, shipping.

  • JUnit, used in 1 project
  • Vitest, used in 1 project
  • Service workers (Serwist), used in 1 project
  • Vercel, used in 3 projects
  • Render, used in 1 project
  • Railway, not shown in a project here
  • Cloudflare R2, not shown in a project here
  • Git & GitHub, not shown in a project here

05Track record

No inflated numbers. Just what exists.

Everything I've built that's on this page, where it stands, and where you can check it.

Live projects you can open right now
7
Production client site I maintain
1
Tests on LearnTogether
340+
JUnit tests on Ping's security paths
26

The ledger

Full history in my resume (PDF)GitHub profile (opens in a new tab)

06Contact

If you need software that holds up, let's talk.

I'm open to internships, freelance projects and engineering roles, especially backend and full-stack work. Email is the fastest way to reach me.