I build production software for complex, data-heavy products.

Product

A planning and document editor for architectural site analysis boards: what architecture students pin up at crits and practices make for competitions and early feasibility studies. Users pin a site, draw its boundary, add generated studies to a sheet, edit everything and export.

What I owned

All of it, built independently: product design, the Angular client and canvas editor, the Supabase schema and security, the Geo API, and CI/CD to Cloudflare and Railway through GitLab.

Frontend

• Angular 21 with signals and zoneless change detection; NgRx stores cache data from Supabase and external APIs
• Konva canvas editor on a framework-free core, where every edit is a command with an inverse for undo
• MapLibre site setup with place search, boundary drawing and Turf measurements
• OpenStreetMap and NASA POWER data fetched and summarized in the browser
• Export to PDF, PNG, SVG, DXF and GeoJSON, generated client-side

Backend & data

• Supabase PostgreSQL with Row Level Security on every table and access checks in security-definer functions
• Roles carried in the JWT by a custom access token hook; plan limits enforced by database triggers
• Autosave through one RPC that checks the base revision, so a conflicting save is raised, never silently overwritten
• Geo API (staging build): Fastify and DuckDB over Overture Maps GeoParquet, Supabase JWTs verified against JWKS, per-user rate limits, OpenAPI generated from route schemas, and an automated test suite in CI

Challenges and decisions

• Read only the Overture files that overlap a site, using committed per-release manifests, instead of scanning every file in the release
• Reject oversized areas instead of truncating them, so partial data never looks complete
• One DuckDB connection per query, three at most and cancellable, after a shared connection timed out under concurrent cold requests
• The database, not route guards, is the security boundary

Status

Working today

• Accounts, projects and documents with autosave
• Site setup and ten generated studies
• Canvas editor, templates and export
• Plan limits enforced in the database

In progress

• Overture buildings from the Geo API, in staging
• Roads, places, vegetation, transit and land-use routes, not yet used by the app
• Payment provider, feedback email and legal pages before launch

Product

Property, market and rent data for the U.S. multifamily industry, covering 220K+ properties. Users search it and analyze it by geography: by metro, by state, nationally, or by an area they define themselves.

What I owned

The frontend of these features: the Mapbox to MapLibre migration, the freehand selection tool, multi-market search from proposal to release, and the reporting views. The APIs behind them were built by the backend team.

Frontend

• Freehand geographic selection on the map
• Property search across metro, state and national scopes, and combinations of markets
• Survey and reporting tools around selected properties and markets
• Report charts and report sharing

Backend & data

I integrated these features with the platform’s REST/JSON APIs and data services, which the backend team built.

Challenges and decisions

• MapLibre has no native freehand drawing, so I built it rather than limit users to predefined boundaries
• Preserve existing map behavior through the migration first, then extend it
• Submarket, metro and national series differ in scale and broke the charting library’s scaling, so I normalized them to a common baseline for display without altering the underlying values
• Let users combine markets, rather than choose between one market and a national search

Outcome

• Users draw any area and analyze the properties and rents inside it
• Searches are scoped to the markets needed, instead of falling back to national searches
• Submarket, metro and national trends read on one chart
• The platform’s maps run on MapLibre

Problem

Production builds took more than 15 minutes, which slowed every release. Separately, the application became slower the longer someone used it, and no single screen explained why.

What I owned

The build and CI/CD optimization, the performance investigation and its fix, and the Angular upgrades across major versions.

Frontend architecture

• Simplified the filter, sort and search flows
• Made subscription teardown explicit, with take(1) for one-shot streams
• Corrected lifecycle handling and terminated leftover processes
• Reworked component imports and routing

Build and delivery

• Removed heavy and unnecessary dependencies
• Improved build configuration
• Angular major-version upgrades

Challenges and decisions

• The slowdown had no single cause: it ran through component lifecycles, RxJS subscriptions, routing, and the filtering and search architecture
• Custom directive and routing abstractions (consumer/mountable patterns) caused lifecycle and subscription leaks, so I simplified the filter, sort and search flows and cleaned up routing and subscriptions

Outcome

• Cut build pipeline runtime from 15+ min to ~5 min
• Fixed the subscription and lifecycle leaks behind the long-session slowdown
• Application running on Angular 22

Product

Two kinds of accounts, customers and service providers (Hackas), each with their own experience and permissions, and a way for customers to find, message and book providers.

What I owned

The whole product: architecture, the Angular application, the Firebase backend and Cloud Functions.

Frontend

• Separate customer and provider experiences
• Service search and discovery
• Booking and in-app messaging interfaces

Backend & data

• Firebase Authentication, with each account’s role in custom claims
• Role-based access for the two account types
• Backend business logic and workflows in Cloud Functions

Challenges and decisions

• Carry each account’s role in Firebase custom claims and base role-based access on it
• Run the backend business logic and workflows in Cloud Functions
• Design booking and messaging workflows that involve both sides

Outcome

A complete marketplace covering both sides, from search to messaging and booking. The product has since been discontinued by its owners.

Product

Wizygbe Tours’ platform served customers looking for holidays and tours, visa applications and college admission applications. Customers booked and paid for travel consultation packages online, and the agency managed the orders through its administration dashboards.

What I owned

The Angular frontend, the Node.js and Express backend, the Paystack integration, and the order management and administration workflows.

Frontend

• Consultation package booking and checkout flows
• Authentication
• Blog and announcements with comments, and a gallery

Backend & data

• Node.js and Express API alongside Firebase
• Server-side verification of each Paystack transaction
• Webhook handling that updates orders from Paystack’s events
• Order data behind the administration dashboards

Why it mattered

• Payment status comes from the server: each Paystack transaction is verified server-side rather than trusted from the browser
• Webhook handling lets Paystack report payment events to the backend directly, not through the customer’s browser

Outcome

Customers booked and paid for consultation packages online, and the agency managed the orders from its dashboards.