who am i

Muiz Oyebowale

It started with curiosity, like most things do. I wanted to know how things worked. Not the surface, but the mechanism underneath. I started with C, which isn't the friendliest place to begin, but it taught me the fundamentals properly. The questions never really stopped.

Backend engineering felt like a natural home. I like the parts nobody sees: the performance work, the data modelling, the failure modes, the 3am alerts that teach you more about a system than a week of reading docs. If you did it right, nobody knows you were there.

People who know me call me muizzy. You're welcome to too. Now I'm pointing the same obsession at AI and ML. The intersection of systems and intelligence is the most interesting problem space I've found, and I'm still early in it. I'm paying attention.

muizzyranking

What I do

What I do, end to end.

Backend first. But I follow a feature all the way out the door.

Backend development

The spine of the product: data, auth, integrations, the parts users never see.

AI integration

Models and providers wired into real flows, where latency, cost and reliability decide.

API design

Contracts that are pleasant to consume and stable to depend on.

End to end

Schema to shipped service. I own the API, the jobs, the deploy and the 3am alert.

Payments & financial systems

Money moves exactly once. Ledgers, wallets, settlement, reconciliation.

Reliability & performance

Caching, queues, async, backpressure. It holds when it matters.

Infrastructure & deployment

Docker, Linux, Nginx, CI/CD. Repeatable deploys, boring on purpose.

Developer tooling & automation

The terminal workflow that survives a fresh install.

How I think

Core operating principle

I understand the problem before I build the solution.

I don't write code until I understand the problem underneath it. The root cause. The actual reason a decision was made. The constraint that nobody documented but everyone assumed.

It makes the start slower. It makes the work better, always. And once in a while, understanding the problem first reveals that we're solving the wrong one entirely, which is the most valuable discovery you can make before you've written any code.

// apologies in advance to my future Product Managers.

Working style

I listen, actually

Not the kind of listening where you're composing your reply. The kind where you catch the thing behind the thing they said. Details most people scroll past.

Slow to start, thorough to finish

I dig into the problem before the architecture is decided, not after. It feels slow at the start, and it saves time in the long run.

I write code for the next person

That person is often me, six months later. So: clear naming, honest comments, no clever tricks that only make sense at 2am.

I push back. I also change my mind.

If something doesn't add up, I'll say so, the way I'd want someone to for me. And when a better argument comes along, I take it. Ideas win because they're right, not because they were mine.

How I work

Principles I build by.

Performance first

Latency is a feature. I optimize the hot path before decorating the page.

Simple over clever

The simplest solution that works today, and still works in six months.

Reliability matters

Systems must survive failure. Idempotency, retries, and graceful degradation are defaults, not afterthoughts.

Design for maintenance

Code is read far more than it's written. I optimize for the next engineer, including future me.

Measure before optimizing

No guesswork. Profile, benchmark, then decide.

Problems I enjoy

The work I'd sign up for again.

Backend work, mostly, where correctness is the feature. A short list of the problems that keep me awake in the good way.

Reliability

Systems that must not fall over. Retries, timeouts, backpressure, graceful degradation. The boring failures are the interesting ones.

Payments and ledgers

Money moves exactly once. Idempotency, reconciliation, double-entry discipline. You get one deployment to get it right.

Queues and async work

Splitting work so nothing blocks and nothing gets lost. Where delivery and ordering guarantees actually matter.

Auth and access

Sessions, tokens, scopes, roles. Boundaries you can reason about, not hope about.

APIs at scale

Contracts that stay stable while the implementation underneath keeps changing.

Stack

What I use to do the above.

Not a boast, a working inventory. Grouped the way I think about a system, from the language down to the shell.

Languages

What I reach for first.

PythonTypeScriptHTMLJavaScriptBashCLuaGoRust

Frameworks

Backend first. A frontend when one is involved.

DjangoFastAPIDjango NinjaNext.jsDjango REST FrameworkFlaskReact

Data

Postgres for everything until there is a real reason not to.

PostgreSQLMySQLRedisSQLAlchemyDjango ORMSQLite

Infrastructure

Repeatable deploys: a server, a container, a workflow.

LinuxDockerCeleryNginxUvicorn / GunicornGitHub Actions

Tooling

The setup that survives a fresh install.

NeovimGitTmuxZshfzfripgreplazygit

productioncomfortableexploring

Currently learning

Working through the parts of ML that go beyond API wrappers: RAG, fine-tuning, model serving, experiment tracking.

// And Rust, slowly, because it keeps teaching me things about my own code.

The human side

Not just a résumé

Watching

Marvel. DC. Animations. Sci-fi. Any superhero film that exists.

I watch everything: live action, animated, sequels that probably shouldn't exist. I have opinions about which Spider-Man was objectively the best. They are correct.

MCUDCEUInto the Spider-VerseArcaneInvincibleStudio Ghibli

Editor of choice

Neovim

Still. :wq survivor.
Config: I'm done this time, I promise.
Regrets: zero.

$ nvim .
# home. sweet. home.

Good conversation topics

I'm bad at small talk. I'm very good at the kind of conversation that starts with “wait, but why does that work?” and ends ninety minutes later with everyone slightly smarter.

Distributed systemsHistory of computingHow things failWhy anything works at allThe philosophy of debuggingBad dad jokes

What's next

If you got here, you read enough.

Three doors. Pick one.

[ 01 ] The work

Projects that shipped.

Things I built. The interesting decisions behind them.

all projects→

[ 02 ] The toolbox

What I reach for.

Languages, tools, the setup that survives a fresh install.

the stack→

[ 03 ] Say hi

Backend roles. AI/ML work. Interesting problems.

Bonus points if it doesn't start with “circling back.”

email me→·résumé↗