Featured
Current
Projects
Tech talks
How I work
I start with the README, not the code
Before I open the editor I write what the product is supposed to do, wireframe it, diagram it, and run unit economics. If the math doesn't close for the segment I'm trying to solve, not a line gets written. Emails and feedback requests come after that — code is the consequence of a decision already made, not the place where you make it.
Serverless by default, us-east-1, DynamoDB first
My default stack is serverless on AWS in us-east-1. I start with DynamoDB and migrate to PostgreSQL when the access patterns justify it. Serverless wins when the service is core and has real demand; low traffic, ultra-low latency, or sustained throughput can argue otherwise — but that's the exception, not the rule.
I cut UI polish, I never duct-tape architecture
Under deadline, the first things to go are UI micro-interactions and non-critical features. What I never negotiate is a one-line patch that quietly rewrites the flow or the architecture. Every improvised patch lives longer than it should, and the debt it creates is the most expensive kind.
Build the core, buy everything else
If it's core to the product, I build it. If it isn't, I buy it — after comparing the price against the real cost of building it, maintenance included (not just the first sprint). The rule is easy; the discipline is holding it when building-for-fun starts looking tempting.
Unit and integration always, except in throwaway MVPs
Unit and integration tests are the floor, not the ceiling. They're what keeps you from discovering bugs in production. The only exception is an experimental MVP where the thing being validated is the hypothesis, not the code — and if I'm doing TDD there, the tests stay.
Async and collaborative — but it always ends in an RFC or diagram
I work in PRs, async but collaborative. For things that don't fit a Slack or email thread, a short call on Discord or Meet, and then the outcome lands in an RFC or diagram. A conversation without an artifact is lost in two weeks; the RFC outlives the team.
LLM → go train → come back with sharper questions
When I get stuck, I first use an LLM to order the problem. If I'm still stuck, I stop and go train. I come back with the problem solved or with better questions than I started with. The body in motion resolves what a stationary head can't.
Observability beats picking the language of the month
The Rust vs Go vs TypeScript debate is overrated. Most production bugs get fixed with structured logs, distributed traces, and well-chosen metrics — not by picking whatever language the latest paper recommends. Teams that invest in observability early age well.
Library
Tech Stack
Serverless & Cloud
AWS Lambda
SQS
EventBridge
API Gateway
S3
CloudFront
CloudFormation
AWS IAM
AWS Secrets Manager
Vercel
Cloudflare
Platform & DevOps
Kubernetes
Docker
Lens
HashiCorp Vault
GitLab CI
BPMN (Camunda)
Data
PostgreSQL
Aurora Serverless
DynamoDB
Redis
Kafka
Snowflake
Languages & Frameworks
TypeScript
Node.js
React
Next.js
Tailwind CSS
shadcn/ui- WebSocket
Socket.io
AI
OpenAI
Claude
Mistral
Llama
Qwen
Whisper
AWS Bedrock
Observability
Datadog
Sentry
CloudWatch
PostHog
Payments & Auth
Stripe
MercadoPago
Commet.co
Clerk
Auth0
Certifications
PCI-DSS ComplianceNaranjaX / Nave NegociosOngoing
Card data security · Payment compliance
Architecting on AWSAmazon Web Services (AWS)Aug 2023
Amazon API Gateway for Serverless ApplicationsAmazon Web Services (AWS)Apr 2022
AWS Lambda FoundationsAmazon Web Services (AWS)Apr 2022

HackerRank2022be3b24005a01






















