Marcos Defendi

Backend engineer. 10 years building distributed systems. This is where I write.

Staff Software Engineer / Architect

I've spent most of my career deep in backend infrastructure — distributed systems, real-time messaging, API design, and the architectural decisions that quietly determine whether a system holds up or falls apart. This site is where I think out loud.

About

Engineer, occasional tech lead, failed founder. Still learning, still building.

I've led backend teams, done system-wide architectural analyses presented to engineering leadership, and most recently spent six months building a compliance platform from scratch as a solo founder — from architecture to production. It didn't find the market fit I was looking for, but I learned a lot about building alone and shipping under uncertainty.

I'm interested in systems that scale without becoming incomprehensible, teams that ship without losing coherence, and writing that makes technical decisions visible to the people who have to live with them.

Principles

Six things I keep coming back to after 10 years of building backend systems.

  1. Complexity has a cost, but so does avoiding it

    A Repository pattern isn't over-engineering — it's the right complexity that buys time to decide with more data. Simplicity disguised as shortcuts is just debt with interest.

  2. Implicit coupling is the silent killer

    Invisible, hard to diagnose, and it destroys systems and teams even when everyone has good intentions. It's the kind of problem that can sink a company before anyone names it.

  3. When you make an architectural decision, name what you gave up

    Every choice closes doors. If you don't make that explicit, someone will discover it the hard way, at the worst possible moment.

  4. Knowledge silos are an architecture problem

    When one or two people become untouchable, they become bottlenecks. Concentrated knowledge is both a technical and organizational risk.

  5. Freedom with guardrails, not freedom without structure

    The team helps decide the foundations, but the critical parts have explicit protection everyone understands. Freedom without structure in the wrong places is just distributed chaos.

  6. Writing a decision down is how you find its holes

    Putting it in text forces linearity. The gaps that survive conversation and code reviews tend to surface the moment you have to explain the reasoning from beginning to end.

Experience

10 years across open-source platforms, product companies, and a solo founder stint.

Solo founder (2025–2026)

Built a Slack-first compliance evidence platform from scratch — architecture, RAG pipeline, audit reporting, production deployment. Validated with CISOs. Shut down after finding the pain existed but lacked buyer urgency.

Staff engineer & backend tech lead (2022–2025)

Led a backend org of ~15 engineers. Designed a federated messaging bridge based on the Matrix protocol. Conducted a system-wide architectural analysis and presented findings and remediation roadmap to CTO and CPO.

Senior engineer (2020–2022)

Re-architected an over-engineered scheduling platform. Led backend foundation for a creator economy product on AWS serverless — structured it so two junior engineers could build on top and ship to production.

Software engineer (2016–2020)

Contributed to core APIs of a large-scale open-source messaging platform (TypeScript/Node.js, MongoDB). Participated in major refactoring efforts toward modularity. Earlier, built an e-learning platform that cut storage costs by 30%.

Writing

Technical writing on the things I'm building, breaking, and figuring out.

Contact

If you want to talk about something I wrote, or just say hi.

Whether it's about something on this site, a problem you're thinking through, or just a conversation worth having — feel free to reach out.