From MBA to Engineer: Building Production Apps

In 2024, the work was getting Already Handled — my own practice — off the ground, backed by a Johns Hopkins MBA and a business background. The pull was always to build the thing directly rather than just advise on it.

So the build started.

The Pivot

The shift toward building was gradual, not abrupt. Internal tools came first — automated deliverables, generated reports, dashboards for client presentations. Each project pushed deeper into the stack. First React. Then Node. Then databases. Coding hours overtook consulting hours, and consulting clients started asking for the software itself rather than just an opinion on it.

The first real project was a website for a wellness practice. Simple scope: marketing site, contact form, maybe a blog. It got overengineered spectacularly — multi-brand architecture, CMS integration, spring-physics animations, SHA256 build verification. The client just wanted a nice website. But that overengineering taught more about production software than any tutorial could.

The Learning Curve

The hardest part was not learning syntax or frameworks. The MBA had already trained the muscle for learning fast and synthesizing across domains. The hard part was taste — knowing the difference between code that works and code that is well-architected.

Early on, a feature would ship, then take twice as long to refactor once the original approach revealed itself as wrong. A classic example: the first version of the EyeBrowse admin dashboard was a single 3,000-line component. It worked perfectly. It was also unmaintainable. Breaking it into 26 focused tabs with shared state management took a week, but the codebase moved from "single-author territory" to "any developer could pick this up."

That refactoring instinct — the willingness to throw away working code in favor of better-structured code — is something often missing in self-taught developers. The MBA background actually helped here. Strategy consulting drills the habit of constantly re-evaluating the approach itself: "This analysis is correct, but is it the right analysis?" Translated to code: "This implementation works, but is it the right implementation?"

The System

In that time, a set of real product systems shipped: some live in daily operations, some built for clients, all shaped by actual business constraints rather than tutorial scope.

EyeBrowse started as "build an eyewear website" and became a full e-commerce platform with browser-based AR try-on. When existing AR solutions all required native apps or expensive SDKs, a custom pipeline was built on MediaPipe and Three.js. The virtual try-on processes 468 face landmarks per frame to position 3D glasses models in real-time. It also has a kiosk mode with encrypted offline ordering for retail locations, because retail WiFi is never reliable.

CareFlow is the clearest example of software having to respect real operational risk. It is a confidential healthcare operations platform used by a live medical practice, so the public case study is intentionally constrained: no patient data, no raw screenshots, no practice details. The engineering story is role-based workflow design, Supabase RLS, MFA, audit-oriented controls, realtime collaboration, and AI guardrails that block medical-advice prompts before a model call.

What the MBA Gives You

People assume the MBA is irrelevant to engineering. It is not. Here is what transfers directly:

Stakeholder communication. Translating between business requirements and technical implementation without losing fidelity in either direction. When a client says "I want AI," the right move is figuring out what they actually need and whether AI is even the right solution.

Scope management. The number one skill in both consulting and engineering is knowing what NOT to build. Every feature has a cost — not just development time, but maintenance burden, cognitive complexity, and potential failure surface. The MBA trains the ROI evaluation instinct.

System thinking. Strategy frameworks are basically architecture patterns for businesses. Porter's Five Forces is a dependency analysis. SWOT is a risk assessment. The mental models transfer surprisingly well to thinking about software architecture — where the bottlenecks are, what the failure modes are, where complexity concentrates.

What It Doesn't Give You

The MBA does not teach how to debug a WebGL context loss on iOS Safari at midnight. It does not teach that IndexedDB transactions auto-commit when the event loop yields. It does not teach that MediaPipe's face mesh detector can stall silently and needs a watchdog timer.

That knowledge only comes from shipping production software and dealing with the consequences when things break in ways nobody anticipated. Every bug fixed, every architectural decision revisited, every 2am production issue debugged — that is the real education.

The Frame

Not a traditional engineering hire. A self-taught engineer with a Hopkins MBA and a background in business operations, who architected and led the build of EyeBrowse — an AI commerce platform with AR try-on, in-store kiosks, AI prescription analysis, and a 135k+ product catalog, built and production-ready — alongside CareFlow, a confidential healthcare operations platform live and used daily by a medical practice. The strongest work is built for real data, real users, and real money — and CareFlow runs all three today.

What this profile brings is the combination: architect a system, implement it, and explain to a VP why it is built the way it is and what the tradeoffs cost. Estimate scope, manage complexity, and make pragmatic decisions about what to build, what to defer, and what to cut.

That is the profile for a founding or early-stage engineer, a full-stack product engineer, or a solutions / forward-deployed engineer — someone who owns both the technical build and the business communication. The strongest systems are live or demoable, the code is real, and the work holds up to inspection. That is the resume.