Brian Ndung'u builds the part of the system you can't see, and makes it reliable.

Problem

Drivers in Kenyan towns lose time circling for parking, and operators have no live picture of which bays are free. Most people pay with M-Pesa, so payment has to work on a phone, over an unreliable network.

What I built

• A live map of bays across Nairobi and other towns, with nearest-bay search from the driver's location (Haversine distance), an occupancy heatmap, and turn-by-turn routes from OSRM.
• Bookings that reserve a bay for 15 minutes, and sensor entry/exit events that keep each bay's status accurate.
• Live updates: every status change is broadcast over STOMP WebSockets, so every open map changes at once without refreshing.
• An admin console for occupancy, bookings and users.

Engineering decisions

• Payments that settle once. Safaricom can deliver the same M-Pesa callback more than once. A payment only moves from PENDING, so a repeat is ignored, and the amount paid is checked against the booking's price before it is accepted.
• An authenticated webhook. The callback has to be public, because Safaricom sends no token, so it is verified with a shared secret or Safaricom's IP ranges instead.
• Access control in two layers: stateless JWT with DRIVER and ADMIN roles in the security filter chain, plus @PreAuthorize on admin operations. The WebSocket channel checks the token too.
• A versioned schema: eight Flyway migrations own the database structure, so any environment can be rebuilt from scratch.
• Protection from abuse: a request rate-limiting filter, CORS rules, and every credential read from the environment.

Delivery

Dockerfiles and docker-compose for the whole stack, with Nginx proxying /api and /ws. Unit tests cover the distance calculations and the slot service.

Problem

Clinicians in busy Kenyan facilities often work without a colleague to sanity-check a diagnosis. General AI chat tools answer in free text, ignore the local disease burden, and are hard to build on reliably.

How it works

Engineering decisions

• Structured output, not chat. The system prompt fixes a strict JSON schema: a green, amber or red consistency rating, red flags, 2–3 differential diagnoses, 3–5 tests, and one follow-up question.
• Reliable parsing. The service strips stray Markdown fences and parses the reply into typed Java objects. Failures come back as a structured error field instead of a crash.
• Consistency: temperature 0.2, so similar cases get similar answers.
• Local context and tone. The prompt covers malaria, typhoid, TB, HIV, brucellosis and meningitis, and phrases disagreement the way a supportive colleague would.

What I built

• Accounts: passwords hashed with BCrypt, and a signed JWT on login that a request filter validates on every later call.
• Catalogue and orders: full product CRUD, seeded on first start, and orders that move through pending → processing → shipped → delivered.
• M-Pesa checkout: STK Push to the customer's phone, accepting 07…, 01…, +254… and 254… number formats, plus Safaricom's callback.
• Storefront: search, wishlist, a cart that survives reloads, and an admin page.

Next steps

The repository lists its roadmap openly: lock management endpoints to admins, record payment status on the order from the callback, cache the Daraja token, and add integration tests. ParkNairobi's payment and access-control design is where these were carried further.

What I built

• Day-to-day school records: students, teachers, subjects, grades, attendance filtered by date, and fee payments.
• Secure sign-in: BCrypt at cost 12, with admin and teacher roles.
• A database that sets itself up: tables are created on first launch and a default admin account is seeded.

Design

Every screen follows FXML view → controller → DAO → PostgreSQL, so the interface, the logic and the SQL stay separate and can be tested on their own. JUnit tests cover the student data-access layer, and CI builds every push.