Michael Onizuka
The layer it all sits on.
Navy veteran. Servers, infrastructure, deployment, and where the data actually lives. Building on the DNN platform since 2004, with contributions in the community codebase. Checkable, not claimed.
Somebody has to know whether it can actually be built.
Most audits stop at the recommendation. The reason ours does not is that the person writing the technical half has spent twenty-two years finding out what happens when a plausible idea meets a real system, and a real deployment window.
United States Navy
Systems you do not get to reboot casually, checklists that exist because somebody learned the hard way, and a standard of "working" that means working when it matters, not working on the demo.
Nobody in the Navy is impressed that it ran fine yesterday.
DNN v4, and QA on TurboCAD
Building on DNN from version 4 inside a commercial software company, and running quality assurance on TurboCAD. Enterprise scale, real users, and an environment where a bad release is somebody else’s very bad day.
Years of professional QA is where the useful habit came from: he does not test whether something works. He tests what happens when somebody does the thing nobody planned for.
You learn what production means when it is not your own site that goes down.
A kid, and a decision
Our son was born in 2012. A year later we took the expertise to the open market rather than keeping it inside one company, and Onizuka Studio started in 2013.
Family operated is not a marketing line on our site. It is the actual reason the business exists.
Into the DNN community
Working alongside people on the DNN core team, including Daniel Valadas, and contributing into the platform community rather than just building on top of it.
That is where the network came from. The developers we call when a build outgrows two people are mostly people from this decade of the work.
Contributing to a platform teaches you its limits faster than using it ever does.
Infrastructure & Platform Architect
Servers, deployment, databases, and the movement of data between systems. On every audit, the feasibility read: whether the API exposes the object the fix needs, whether “they integrate” means anything, whether the proposed automation survives real data volume.
Half of what makes a recommendation good is knowing it will still be true in production.
Give him something and he will break it, usually within a minute.
Every team should have one person who cannot look at a system without immediately trying the input nobody sanitised. On this one, that is Michael, and it is not a party trick. It is years of professional QA pointed at whatever is in front of him.
He does the thing you least expect, in the order you did not account for, and the failure surfaces in seconds rather than eighteen months later in front of a customer. On an audit that matters more than it sounds, because a recommendation that has not been stress-tested is a guess with formatting.
Anybody can confirm a system works. Finding the exact input that breaks it is a different skill, and it is the one that protects you.
It is also why the audit says what not to automate. Knowing where something will fail under load, under an edge case, or under a user doing something reasonable but unanticipated is the difference between an automation that saves you a day a week and one that quietly corrupts records for a quarter before anyone notices.
The part of your business you never see until it stops.
Two layers, one exam.
Michelle reads the layer people use: workflows, software, and the screens where work stalls. I read the layer it runs on. Between the two, nothing in a business falls outside the audit, and neither of us has to guess about the other half.
Repair, connect, automate, build. Only what the audit found.
Zoho and Deluge, MCP, Make and Power Automate, Microsoft 365, custom applications, and a fair amount of software written from scratch because what the business needed did not exist for sale.