Bitwyse Projects is a monthly cloud-engineering logbook. Every month I design, build, break and harden a production-shaped project on AWS — then write the full field notes so you can follow every decision, trade-off and fix.
A deliberate progression — each month builds on the last. It starts by securing the account itself, then puts the first real workload on the internet. Open any project for the full field notes.
Before deploying a single server, I turn a raw AWS account into a governed one — locking down root, enforcing MFA, designing least-privilege access, wiring an audit trail with CloudTrail and setting hard billing guardrails.
Standing on that foundation, I put the first workload online — a custom VPC, a hardened EC2 host running Nginx, a real domain through Route 53, and a proper HTTPS padlock, all validated with security checks.
// more builds land here every month — this logbook grows in public.
These aren't tutorials copied line-for-line. Each project is a self-set brief, worked end to end and written up the same honest way — decisions, dead-ends and all.
Every project starts with a brief and an architecture diagram. I decide which services, why, and what "done" looks like — so the build has a target, not a vibe.
No cloud sandbox make-believe. Real accounts, real DNS, real bills. I favour the CLI and config over the console so the work is repeatable and reviewable.
I test failure paths, capture the evidence, and record the metrics. If I can't show it works — and how it behaves when it doesn't — it isn't finished.
Open any project and you'll find the same six-part essay — a story you can actually follow, not a wall of screenshots.
What I set out to build and why it matters — the real-world problem the project stands in for, and the success criteria I'll be judged against.
The architecture diagram plus the reasoning behind every service choice — and the trade-offs I consciously accepted.
A narrative walkthrough of the actual work, with the commands and config that mattered — written so you could rebuild it yourself.
The things that broke, the confusing errors, and exactly how I diagnosed and fixed them. The part most write-ups quietly delete.
Validation, tests and metrics — what I measured to be confident it holds up, including how it behaves under failure.
What I'd do differently, what it cost, and how it sets up next month's build.
I'm Bolarinwa David — a cloud engineer who believes the best way to prove you can run infrastructure is to run it: publicly, repeatedly, and with the receipts.
Bitwyse Projects is my accountability engine. One AWS build a month, no month skipped, each one harder than the last and written up so anyone can learn from — or poke holes in — my work. It doubles as a portfolio you can actually read, not just skim.
# bitwyse ~ whoami name = "Bolarinwa David" role = "Cloud / DevOps Engineer" focus = "AWS · security · automation" method = "build → break → document" cadence = "one project / month" toolbelt = ["aws-cli", "nginx", "bash", "linux"] principle = "if I can't show it, it isn't done."
I post every new project there first — the wins, the curveballs and the lessons. If you're hiring for cloud, collaborating, or just into building in public, come say hi.
