HomeAboutExperienceProjectsArchitectureEngineeringArticlesResumeLet's Talk
Architecture

How I designsystems

Before writing code, I map users, workflows, data, and failure points. These are the recurring patterns behind the platforms I build — the decisions that let one team ship several products without the architecture collapsing under its own weight.

01Multi-Tenant SaaS

One platform, many products

Rather than building each product from scratch, I design around a shared platform core. Identity, organizations, billing, and notifications live once and are reused by every product — so a new product is mostly new domain logic, not new plumbing.

Row-level, organization-scoped isolation keeps tenants separate without a database per customer.
The core is versioned and shared, so improvements land across every product at once.
New products inherit auth, roles, and billing on day one.
NyumbaZatuHospitalityCoderHiveEducationMoyoCare / GariFlowHealth · FleetShared Platform Coreone codebase · one identity model · reused across every productIdentity & AuthOrganizationsBillingNotificationsTenant-scoped datarow-level isolation per organization
02Identity & Access

Organizations, roles, and permissions

Access is modeled around the organization as the tenant boundary. Users join organizations through memberships, roles bundle permissions, and the access token carries exactly the claims a request needs — so authorization checks stay cheap and consistent.

Permissions are the unit of truth; roles are just named bundles of them.
Membership is explicit, so the same person can hold different roles in different organizations.
Tokens carry scoped claims to avoid a database lookup on every authorization check.
Organizationthe tenant boundaryMembershipuser ↔ orgUserRolePermissionAccess tokenJWT / Sanctum
03API & Request Lifecycle

How a request actually flows

Web and mobile clients talk to a single versioned Laravel API. Every request passes a predictable middleware stack — authentication, validation, rate limiting — before hitting domain services. Slow or side-effect work is pushed onto queues and handled by workers, keeping responses fast.

One API serves both web and mobile, so business rules never fork between platforms.
Validation and authorization sit in middleware, not scattered through controllers.
Anything slow — email, push, heavy processing — is queued and retried, not done inline.
Web · Next.jsMobile · ExpoLaravel APIAuth · ValidationRate limit · VersioningDomain servicesDatabasePostgreSQL / MySQLQueue → Workersjobs, retries, asyncNotificationsemail · push
04AI Architecture

MIKE — an agent that runs other agents

MIKE is designed as an orchestration layer. A lead agent plans a task, dispatches it to specialized agents, gives them tools and shared memory, then aggregates the results and reports back to me like a chief of staff. The value is in the coordination, not any single model call.

A single lead agent owns planning and delegation so behavior stays predictable.
Specialized agents keep prompts focused and tools scoped to their job.
Shared memory lets agents build on each other instead of starting cold.
OperatorElijahMIKElead agent · plannerResearch agentOps agentComms agentToolsAPIs · memory

Want the deeper version?

I can walk through any of these systems in detail — data models, trade-offs, and the parts that got hard — against real production code.

Talk architecture