Server-Side
Backend & APIs
Node.jsNest.jsStripeTypeScriptJavaScriptREST API DesignWebSocketssocket.io
// HIGHLIGHTED ARE THE HEADLINERS
What I reach for first
Nine years of hands-on work, organized by category. Highlighted are the headliners in each stack. The “familiar with” card is everything else.
AWS Certified
Cloud & Architecture
AWS Solutions ArchitectEC2ECS / FargateLambdaAPI GatewayRDSS3SQS / SNSDynamoDB
AI-Augmented
AI & Intelligent Tooling
RAGVoyage AIClaude CodeMCPs & SkillsClaude APIOpenAI APIAWS ML Services
Data Layer
Databases & ORMs
PostgreSQLMySQLAuroraRedisOpenSearchSequelize
Client-Side
Frontend Expertise
VueNuxtReactNext.js
Delivery Pipeline
DevOps, Testing & Tools
DockerGitHub ActionsDataDogGrafanaJestCypressPlaywrightJIRAConfluence
Industry Knowledge
Domain Expertise
Investments (Public & Private)Field ServiceBlockchainBitcoin & LightningLiquid NetworkAI Integrations
Additional Experience
Familiar With
PythonFlaskMongoDBTypeORMPrismaTailwindGitLab RunnerCC++C#JavaGoArduino
// WHERE THE STACK ISN'T THE BOTTLENECK
How does a senior project actually go sideways?
Not at the keyboard. In the room before it. Five places where the work isn't visible in the stack list.
Agile delivery
What planning is for, and what retros are for.
Sprints with real planning at the start and a real retro at the end. The retro is where the team actually changes shape: kudos for what went well, honest names on what went wrong, one or two specific things to change next sprint.
- Sprint planning ties scope to capacity, not optimism
- Retros end with a change someone owns, not a list of complaints
- Kudos go on the record so quiet work gets seen
Mentoring
Technical mentoring without communication mentoring stalls.
Engineers usually learn how to write the code. They rarely learn how to ask the question that saves the day. I mentor both, so the team's choices are loud enough to be challenged before they ship.
- Code reviews paired with the question the change should have asked
- Naming the unspoken: surfacing concerns that would have stayed in DMs
- Decisions logged so the next engineer inherits the reasoning
Stakeholder comms
Curious first. Opinionated second.
Most stakeholder calls get run as one-way: requirements in, estimates out. I run them as negotiations. Ask, label, filter, propose, push back when the answer would burn the project.
- Calibrated questions before commitments
- Push back early, not after the contract is signed
- Filter the asks: not every requirement is the real requirement
Pre-sales
Pre-sales is the negotiation. Treat it that way.
Pre-sales doesn't start at the proposal. It starts at the first message. Tone, pace, what gets named and what gets left for the call. Done well, the contract is mostly a formality.
- Every message is a move; the cadence sets the deal's tempo
- Architecture pitched to constraints, not to wishlists
- Walked away from deals with the wrong framing, won the next one
Client work
Warm up. Then talk about the thing actually paying for the call.
Client meetings without warm-up are interviews. Client meetings without the real thing are theatre. The first three minutes are about people, the next forty are about the business.
- Open with what's changed since last time, not a status report
- Name the trade-off the client is avoiding before the contract names it
- Leave the call with one decision and one open question for next time
Almost thereThe contact page is the actual close.
If you've read this far, you already know whether you'll click.