Senior engineer. Founder. Systems builder.

I build the interfaces, APIs, AI solutions, automations, and data systems behind products that cannot afford to break.

Twenty years of shipping real systems: React at Disney scale, HIPAA-compliant APIs at Hoag Hospital, McKinsey client dashboards, CHOPT's checkout architecture, and two companies I run on the side. I still write the code myself, including AI-native workflows, MCP servers, tool integrations, and production automation. If you need someone who can pick up any stack, own the hard problems, and stay accountable through production, let's find out if I'm the right fit.

Get in touch → Open resume ↗ Resume ↗
GitHub ↗ LinkedIn ↗ Live work ↓ AI Forward ↓ Full history ↓
20+ years building web and software systems
Senior software engineer with full-stack ownership
Any stack React, TypeScript, Node, Python, PHP, SQL, cloud, and more
Production security, compliance, data, real uptime responsibility
Any stack means React, TypeScript, JavaScript, Node.js, Express, Python, MCP servers, LLM APIs, AI tool integrations, agent workflows, PHP, WordPress, SQL, PostgreSQL, MySQL, MariaDB, MongoDB, AWS Lambda, S3, DynamoDB, API Gateway, Azure Functions, Snowflake, D3.js, Plotly Dash, Mapbox, Tableau, DataDog, SonarQube, Jest, Cypress, Mocha, Jenkins, GitHub Actions, Docker, Terraform, Epic, Cloverleaf, Stripe, Braintree, Twilio, Sentry, Storybook, Angular, Aurelia, LAMP, LEMP, Linux, Shell, Git, and more

Before the AI revamp

Want to see the hand-coded version that came first?

Obviously, this version of the site has been AI-revamped, but it is built on the portfolio I hand-coded before AI tooling became part of my workflow. If you want to see the original work and where this site evolved from, open my previous portfolio website.

Click to open old site ↗

How this page works

I built this page the same way I build products.

Each section earns its place: lead with signal, follow with proof, surface the real work, then make the ask simple. Scroll is the navigation, not a wall to fight through.

01

Lead with clarity

Bigger type, more breathing room, one clear action above the fold, and a lede that actually says what I've shipped, not what kind of engineer I "am."

02

Show the receipts

I organized each section so you can scan fast and go deep when something catches. Role history, live previews, an interactive skill graph. Everything has its own room.

03

Make scroll feel intentional

The side dots, progress bar, and nav all track where you are. I built this as a single HTML file with no framework and no build step, because I wanted the craft to be visible.

04

Close with a straight ask

By the time you reach contact, you've seen what I've built, how I think, and what I can own. If it looks like a fit, I'd love to hear about the role.

The short version

Twenty years. Real systems. Real ownership.

Twenty years leaves a paper trail: enterprise data platforms at Disney, HIPAA-compliant healthcare at Hoag, McKinsey client delivery, production checkout flows, military medical systems, and two businesses I run myself. The resume is the visible layer. The real history goes deeper.

PDF resume ↗ Live work ↓ LinkedIn ↗

Live work previews

Open the work without leaving the page.

Saved previews of public-facing work I've shipped, served directly from alext.io. Some sites block embedded browsing, so every card includes an optional interactive view and a direct link to the live site. Enterprise systems, private repos, and healthcare integrations sit behind access controls; I can walk you through those when the conversation is real.

Realtor Studio ↗ DinnerRadar ↗ Creamed ↗ CHOPT checkout ↗ Resume ↗ Dinner app ↗ Learning Lab ↗ Build stories ↓ Full history ↓

The public surfaces are just what I can show without an NDA. Private enterprise systems, healthcare integrations, payment flows, dashboards, automations, and more are all available to walk through when the conversation warrants it.

Inside the build / selected engineering stories

The interesting part is under the hood.

Four different problems. Four very different systems. Here's the part a resume bullet can't fit: why I built them, how the pieces talk to each other, and the decisions that made the software useful.

01 / 04Independent product · Designed and built by meLive product

ALEXT.IO / LEARN

Learning to code should feel like building, not scrolling.

I built a full-stack, interactive learning environment that turns small JavaScript and web-engineering concepts into practice, immediate feedback, and progress you can actually keep.

Explore the app

01 The problem

Most learning tools are good at explaining a concept, then leave you wondering whether you actually understand it. I wanted a tighter loop: learn one thing, try it, get feedback, and remember where you left off.

02 What I built

A browser-based learning lab with short lessons, JavaScript coding exercises, quizzes, contextual hints, an assessment flow, and a progress system with XP and review state. It is a real deployed app, not a static tutorial or a portfolio prototype.

03 The engineering decision

Keep the practice loop fast in the browser, but make progress durable on the server. The learning interface and exercise checks respond immediately; the Node.js application handles authenticated user state, and SQLite persists progress across sessions. The app runs under alext.io/learn on a Node.js-enabled Namecheap deployment.

The interesting part: this is a learning product with real state, real sessions, and an intentionally low-friction user experience, not just a set of exercises.

HOW IT WORKSREQUEST / RESPONSE
01 · EXPERIENCEReact learning interfaceLessons, exercises, hints, feedback
02 · PRACTICEBrowser exercise runnerImmediate validation and assessment steps
03 · APPLICATIONNode.js server + authenticationSessions, APIs, per-user learning state
04 · PERSISTENCESQLite progress storeCompleted lessons, drafts, XP, review history
Conceptual application flow. Public experience: alext.io/learn ↗
TECH STACK
  • React
  • JavaScript
  • Node.js
  • SQLite
  • OAuth
  • REST APIs
  • cPanel / Namecheap
02 / 04Founder-built product · End-to-end engineeringLive product

DINNERRADAR.COM / PRODUCT ENGINEERING

One question. Two ways to answer it. A lot of engineering underneath.

I designed, built, and deployed DinnerRadar to make deciding what to eat feel effortless. One path recommends an independent restaurant after checking its availability. The other turns ingredients already in your kitchen into a recipe. Under both is a full-stack product designed around reliable data, local AI, and responsible operating costs.

Try DinnerRadar
01 / EATING OUT Find one great place.

Discover independently owned restaurants, check opening information, and offer a useful pick instead of endless search results.

02 / DINNER AT HOME Use what's in your fridge.

Turn pantry ingredients into a practical recipe with locally hosted generation and live progress updates.

01 The problem

Choosing dinner shouldn't require scrolling through dozens of listings or trusting stale restaurant data. I wanted a simple, mobile-friendly product that gives one useful answer, whether someone is heading out or cooking with ingredients they already have.

02 Discovery built around evidence

I built a restaurant discovery pipeline using OpenStreetMap and the Overpass API, with background workers that populate and refresh city coverage. Recommendations filter out chains, check local hours and listing evidence, and use available website signals to identify closures. The goal is to validate what the system can know rather than ask an AI model to invent ratings, opening hours, or business facts.

03 Local AI with deliberate guardrails

For at-home meals, the application can generate recipes from a user's pantry through a locally hosted model running with Ollama. A shared generation scheduler uses leases and resource checks to prioritize people requesting recipes over background enrichment. Server-Sent Events stream job progress back to the interface. If the model is unavailable, restaurant discovery remains functional using ordinary application logic and SQLite full-text search.

04 The architecture and cost tradeoffs

The production system runs Next.js, TypeScript, SQLite in WAL mode, background workers, and local inference on a small single-host DigitalOcean deployment. I deliberately chose fewer moving parts over unnecessary managed infrastructure. Durable job queues, retries, heartbeats, and recovery logic help keep slower discovery work separate from user requests.

05 Security, billing, and production delivery

Anonymous visitors can try the product without signing up. Usage is enforced on the server and counted only after a successful recommendation. Passwordless email and Google sign-in support accounts, while Stripe handles subscriptions and billing. CI runs type checking, automated tests, and real-browser checks; versioned releases pass through QA before production with additive database migrations and rollback support.

This is the kind of product I love building: a simple user experience backed by careful data validation, constrained AI, background orchestration, security, and operational discipline. I own the entire journey from concept to live deployment.

HOW IT WORKSTWO PRODUCT PATHS
01 · EXPERIENCENext.js + React + TypeScriptOne-tap restaurant picks and pantry-based recipes
02 · RESTAURANT DATAOpenStreetMap + OverpassCity discovery, independent-business filtering, hours and closure checks
03 · DURABLE STATESQLite WAL + FTS5Catalog, accounts, history, quotas, and background job queues
04 · RECIPE ENGINELocal AI + Server-Sent EventsPantry recipes, foreground-first model scheduling, live progress
05 · OPERATIONSStripe + versioned CI/CDPasswordless accounts, success-based usage, QA and rollback
Conceptual component map, not a literal sequential request path. Eating out and cooking at home are separate workflows that share application infrastructure. No private keys, model prompts, or deployment configuration are shown.
TECH STACK
  • Next.js
  • React
  • TypeScript
  • Node.js
  • SQLite / WAL
  • FTS5
  • OpenStreetMap
  • Overpass API
  • Ollama
  • Server-Sent Events
  • Stripe
  • Vitest
  • Playwright
  • GitHub Actions
  • DigitalOcean
03 / 04The Walt Disney Company · Enterprise engineeringPrivate system

DISNEY / TITAN · ARCHITECTURE + DELIVERY

The POC proved the idea. The architecture made it scalable.

Titan began as an Airtable proof of concept. The larger challenge was designing and delivering a maintainable enterprise product: a MERN application, big-data ETL across multiple teams and incompatible schemas, documented engineering standards, and an AWS Bedrock AI layer connected through custom MCP tools and DAG workflows.

Discuss the architecture

01 One workflow, many source systems

Airtable helped validate business-application intake and attestation. Building the real product meant moving beyond a table-driven POC: large datasets arrived from different teams, Snowflake and ServiceNow held different views of the world, and each source brought its own fields, schema assumptions, identifiers, and ownership. The challenge was to make that data useful without binding the product to any one team's format.

02 Architecture and technical documentation

I worked on the architecture for a MERN platform, separating React workflows from Node.js / Express APIs, MongoDB application state, and the ETL and integration layers. I treated technical documentation as part of the build: recording how components fit together, where responsibilities belong, how schemas map into application contracts, and which decisions would affect maintenance as more teams joined.

03 Big-data ETL across teams and schemas

The data engineering work was about more than moving rows. It involved ingesting and transforming large, differently structured datasets, reconciling fields and identifiers across source schemas, validating data quality, and exposing consistent records to application services. DAG-based orchestration made multi-step processing explicit instead of burying dependencies inside one-off scripts. This gave the product a clearer boundary between source data and user-facing behavior.

04 Coding standards, development flow, and tests

Architecture only holds up if the team can keep shipping against it. I emphasized documented interfaces, clear coding conventions, reviewable changes, and a predictable development flow from implementation through code review, testing, and release. Unit, integration, and regression testing were part of the engineering conversation, especially around schema transformations, API contracts, and the behavior of multi-step workflows.

05 Agile delivery and engineering economics

I approached delivery in manageable, testable increments with ongoing feedback from partner teams and stakeholders. Cost analysis was part of the architectural judgment: weighing the effort of replacing the Airtable POC against the long-term cost of maintaining it, and examining the implications of data-processing volume, storage and query patterns, application hosting, AI model usage, and operational support. The goal was a platform the organization could evolve responsibly, not the flashiest stack on paper.

What I want this work to show: I can turn a quick proof of concept into a well-reasoned engineering platform, document the tradeoffs, align teams working with different schemas, and make architecture, cost, testing, and delivery part of the same conversation.

ARCHITECTURE AT A GLANCEPUBLIC-LEVEL OVERVIEW
01 · SOURCE TEAMSSnowflake + ServiceNowMultiple owners, data contracts, and heterogeneous schemas
02 · BIG-DATA PIPELINEETL + schema normalizationIngestion, field mapping, validation, and DAG dependencies
03 · SERVICE BOUNDARYNode.js / Express + MongoDBStable API contracts, state, and application logic
04 · USER EXPERIENCEReact workflowsBusiness-application views, attestation, and dashboards
05 · AI CAPABILITIESAWS Bedrock + custom MCPControlled model-tool integration and orchestrated processing
Conceptual layers, not a literal request sequence or an internal architecture diagram. DAG orchestration and AI capabilities can span stages. No private schemas, records, endpoints, credentials, or internal cost figures are disclosed.
BEYOND THE TECH STACK

Engineering discipline was part of the product.

01 / DESIGNArchitecture + docs

Service boundaries, data mappings, interface decisions, and maintainability tradeoffs.

02 / ECONOMICSCost analysis

Build-vs-extend decisions, processing and storage needs, model usage, and operational overhead.

03 / QUALITYStandards + tests

Code conventions, reviewable changes, validation, integration tests, and regression thinking.

04 / DELIVERYAgile + cross-team flow

Incremental milestones, source-owner alignment, feedback, and disciplined releases.

TECH STACK + DISCIPLINES
  • MongoDB
  • Express
  • React
  • Node.js
  • AWS Bedrock
  • Custom MCP
  • DAG orchestration
  • Big-data ETL
  • Schema mapping
  • Snowflake
  • ServiceNow
  • Airtable POC
  • Architecture docs
  • Cost analysis
  • Testing
  • Agile delivery
04 / 04Hoag Hospital · Healthcare integrationPrivate system

HOAG / EPIC INTEGRATION

A scheduling experience is only as good as its EHR integration.

I worked on connected scheduling and secure medical-communication experiences for Hoag, integrating modern React / Next.js interfaces and MERN services with Epic through FHIR resources and Cloverleaf HL7 messaging workflows.

Discuss the integration

01 The problem

A polished appointment UI means little if the clinical record cannot understand the appointment, patient context, or attached medical information. Healthcare systems use different integration contracts, and mistakes in identifiers or message routing matter far more than an ordinary form error.

02 What I built

I built features across a React / Next.js frontend and Node.js-based full-stack services for scheduling and secure clinical communication. The integration work connected Epic FHIR patient and scheduling context with HL7 message flows routed through Cloverleaf, including workflows around imaging appointments and clinical documents.

03 The engineering decision

Keep the user-facing experience separate from the clinical integration boundary. FHIR is useful for structured resource lookups and identity context; Cloverleaf handles HL7-style interoperability and downstream messaging. The application layer coordinates validation, API interactions, and safe handling of healthcare data without exposing clinical system details in the browser.

The technical challenge wasn't just building forms. It was making a modern application behave responsibly inside an existing medical integration ecosystem.

HOW IT WORKSINTEROPERABILITY
01 · EXPERIENCEReact / Next.js UIScheduling and secure care workflows
02 · APPLICATIONMERN / Node.js servicesAPI coordination, validation, protected state
03 · INTEGRATION PATHSEpic FHIR + Cloverleaf HL7Resource context and clinical message exchange
04 · CLINICAL SYSTEMSEpic-connected workflowsAppointments, patient identifiers, clinical documents
Conceptual integration boundaries only. No patient information, clinical identifiers, or private infrastructure details.
TECH STACK
  • React
  • Next.js
  • MongoDB
  • Express
  • Node.js
  • Epic FHIR
  • Cloverleaf
  • HL7
  • AWS
  • Healthcare APIs

These stories describe the architecture and engineering lessons at a public level. Internal implementations and clinical records stay private.

AI Engineering

AI Forward

I build AI as an engineering capability, not a demo layer: production AI solutions, MCP servers, tool integrations, structured workflows, and application features that connect models safely to real systems and real business processes.

The real edge is knowing how to turn model capability into reliable software. I use AI daily for architecture, solutioning, implementation, workflow automation, data validation, anomaly detection, reporting, and debugging, while designing the APIs, permissions, schemas, observability, fallbacks, and human review needed to make AI useful in production.

Resume proof ↗ Skill map ↓ Talk AI-native work ↓
01

Architecture acceleration

Compare implementation paths, expose hidden coupling, generate option trees, and cut the time from messy requirement to workable technical plan.

02

Native product integration

Ship AI where it actually belongs: validation, internal tools, workflow automation, support surfaces, reporting dashboards, decision engines, and model-powered product features.

03

Fast-ramp learning loop

Pick up unfamiliar tools quickly by pairing senior fundamentals with AI-assisted exploration, docs review, test scaffolding, and production verification.

04

Human-in-the-loop quality

Stay in charge: review generated code, test the edges, protect data, respect compliance, document the system, and ship maintainable software.

05

MCP servers & tool integrations

Build Model Context Protocol servers that expose APIs, databases, internal services, and business tools to AI clients through typed schemas, authentication, validation, and observable tool calls.

06

Production AI solutions

Turn business workflows into reliable AI systems with retrieval, structured outputs, tool use, approval gates, monitoring, fallback paths, cost controls, and measurable outcomes.

Interactive skill map

Move your mouse near the graph. It pushes back.

Hover a node to see where that language, framework, or platform shows up in my actual work. This isn't a tag cloud. It's a proof map. And the obvious subtext: whatever stack you're running, I can pick it up.

Map to experience ↓ GitHub ↗ Resume ↗

Selected capability

Full stack systems

Move across the map or hover a node. The graph reacts to your cursor and explains where that capability shows up across enterprise, healthcare, agency, product, and military work.

ReactNode.jsPythonSQLAWS
Live previews ↑ GitHub ↗

Delivery history

The receipts speak for themselves.

Each card maps to a real delivery from my resume. Scan the source labels (Disney, Hoag, McKinsey, Military, Founder) and you'll see the range quickly. This is still only what's publicly visible.

PDF resume ↗ Resume ↗ More on request ↓

Let's talk

Ready when you are.

Send the role, the stack, and the real challenge. I'll tell you straight whether I can help. If it looks like a fit, I'm happy to share repo access, architecture notes, and specifics that don't belong on a public resume.

✉ Email Alex→ in LinkedIn↗ { } GitHub↗