Tools
Tools
Grouped by the problem they solve, not by popularity. A CTO is not sold with forty logos.
Architecture
- Microservicios
- Monolito modular
- Clean Code
- API REST
Backend
- PHP
- Laravel
- Node.js
- TypeScript
- Python
- Java
- C#
- Spring Boot
Frontend
- React
- Next.js
- Vue.js
- Angular
- Astro
- Tailwind CSS
- Ionic
Data
- PostgreSQL
- MySQL
- SQL Server
- MongoDB
- Redis
- Drizzle
Cloud & infrastructure
- AWS
- S3
- CloudFormation
- Docker
- Nginx
- GitHub Actions
- CI/CD
Payments
- Stripe
- PaymentIntents
- Stripe Connect
- Webhooks
- SPEI
- CFDI
Mobile
- Flutter
- Ionic
- Telnyx WebRTC
- Android
How I work
Four things I do believe in
- 01
Concepts come before code
A framework takes two weeks to learn and is forgotten when the next one ships. Patterns, data modelling and system boundaries last you a career.
- 02
What can be proven by absence should be proven by absence
A negative guarantee written in a README never fails. A script that checks it does. I prefer the second, even when it costs more to write.
- 03
Failure modes are decided by the type, not by review
If something must not be able to happen, let the type system or the database forbid it. Asking people for discipline is a strategy with an expiry date.
- 04
Abstraction earns its place
One interface per class is ceremony. Putting the project’s only interface exactly at the external boundary — where it lets you test without a third party — is judgement.
Tools without evidence are worth nothing. Every one of these appears in the case studies, with the problem it solved and what was rejected.