Danilo Velasquez
Staff Engineer at Adevinta
In this kickoff episode of Señors @ Scale, host Neciu Dan sits down with Danilo Velasquez — Staff Engineer at Adevinta and longtime frontend performance obsessive.
Main Takeaways from my conversation with Danilo:
Tracking performance manually doesn’t scale. Danilo initially spent 4–5 hours each week gathering Lighthouse scores for dozens of pages. Automating that process with the Lighthouse Node API cut the task to 15 minutes and opened the door to real-time Prometheus integration. The result? A living dashboard that made performance a continuous conversation—not a one-time audit.
💡 Page ownership should align with team ownership. Danilo saw firsthand how abstract “domain boundaries” broke down when multiple teams had partial responsibility for the same pages. His solution: make each team responsible for its own application and page set. When ownership changes, move the code. It’s painful, but clear.
💡 Micro frontends led to micro-messes. In one system, they had 50+ frontend services powering a single feature. It looked modular on paper, but was impossible to maintain. Danilo now recommends grouping apps by team instead of slicing purely by domain—favoring practical boundaries over architectural purity.
💡 Old dependencies are a form of technical debt. Danilo advocates for building as close to the platform as possible—favoring native web components over frameworks when feasible. A five-year-old web component still runs today, but a five-year-old React app might be a minefield of outdated packages.
💡 Platform engineering is a force multiplier. Rather than shipping features directly, Danilo found more leverage in improving CI pipelines, optimizing DX, and standardizing tooling. Helping 10 teams ship better beats building a single product faster. It’s the clearest example of “scaling through others” in engineering.
💡 End-to-end tests are flaky for a reason—and it’s not just the tooling. Danilo points out that many e2e failures reflect real user bugs: delayed renders, missing elements, or race conditions. If your tests fail often, it might be telling you your frontend is too complex, not that Cypress is broken.
💡 Performance regressions should trigger incidents. In Danilo’s org, if a Web Vitals metric turns red, it’s treated like a production outage. That means war rooms, halted deployments, and dedicated fixes. It's a cultural shift: performance isn’t a “nice-to-have”—it’s infrastructure.
💡 Core Web Vitals data needs business context. Most teams track Web Vitals separately from conversion metrics—but that’s a missed opportunity. Danilo recommends wiring performance data into tools like Google Analytics to see if faster LCP actually improves sales, signups, or retention. Without that, you’re optimizing in a vacuum.
💡 Fonts can kill your LCP. One project had 12 separate font files for various weights and styles, all blocking the render. Switching to system fonts massively improved performance with zero user complaints. If users can’t tell the difference—but your metrics can—it’s worth rethinking your stack.
💡 The consent banner might be your LCP—and that’s okay. For EU users, the cookie/consent UI is often the first required interaction. Trying to hide or defer it might break compliance. Instead, Danilo suggests embracing it: load it early, strip down fonts, and make it snappy.
💡 Lighthouse results depend heavily on where and how you run them. Danilo discovered huge swings in scores when Lighthouse ran on shared cloud infrastructure vs. isolated VPS machines. To reduce variability, consider running it on dedicated, stable environments—especially if you’re gating PRs with performance checks.
💡 Long tasks? Try setTimeout(0). If your TTI or FID is struggling, Danilo recommends identifying heavy JS operations and wrapping them in a microtask with setTimeout. It’s a surgical fix—but it can yield major gains by unblocking the main thread faster.
💡 Mentorship isn’t about knowledge transfer—it’s about presence. Danilo believes the best mentors don’t just answer questions—they stick around, ask “why,” and help mentees think for themselves. That kind of leadership builds long-term capability, not short-term productivity.
Episode Length: 57 minutes of pure value
💡 More Recent Takeaways
Señors @ Scale host Neciu Dan sits down with Carson Gross, creator of HTMX, principal at Big Sky Software, and computer science professor at Montana State University. Carson has been programming for more than 30 years, from HyperCard on a family Mac to Excel macros for an industrial engineering firm, a JVM language called Gosu, a Rails startup, and the 2012 library Intercooler.js that he rewrote without jQuery during COVID and released as HTMX. His argument is that the web was built as a hypermedia system, that links and forms are control logic living inside the document, and that most of what we call REST today fails the one constraint Roy Fielding cared about. He also covers which apps HTMX is wrong for, what changed in HTMX 4 and why 3 was skipped, and why his students now sit pencil and paper exams. It is a conversation about using the browser as the hypermedia client it was built to be.
Señors @ Scale host Neciu Dan sits down with Ryan Townsend, Principal Product Manager for Performance at Cloudflare, where he owns real user monitoring and the wider performance measurement remit. Ryan has over 20 years in web technology and a decade as a CTO: he co-founded Shift Commerce, the first enterprise scale headless SaaS, and was CTO of Matalan Direct after the business he built came second in Shopify's Build a Business competition with only three months of trading. We cover why the 'Rails doesn't scale' story was always a myth, the resume driven development he kept finding as a fractional CTO, the personalization script that claimed zero performance impact and cost seconds at P90, and how Shift ran over 99% cache hit ratios by splitting the anonymous page from the basket.
Señors @ Scale host Neciu Dan sits down with Szymon Chudy, Software Engineer at Netflix on the Hawkins team, which builds the design system behind thousands of internal applications used to produce the shows you watch. Before Netflix, Szymon spent two and a half years at Lokalise, growing from senior to staff frontend engineer and leading frontend direction across teams, and before that he toured Poland as a reggae guitarist while freelancing as a web developer in the off season. From why the source of truth for a design system lives in code, to Hawkins Consumer versus Hawkins Professional, to the UI paved road that changes what freedom and responsibility mean at Netflix, to measuring the team on adoption rate and shipping codemods and agent skills for every breaking change, to what being an informed captain who farms for dissent means in practice, this is the design system conversation for anyone maintaining a platform other engineers have to choose to use.
Señors @ Scale host Neciu Dan sits down with Vilva Athiban, Lead AI Engineer at Omio, one of Europe's leading travel platforms, where he architects and ships agentic AI systems in production. Vilva designed and delivered Omio AI, along with the MCP integrations that connect AI agents to the company's systems. He never set out to switch from JavaScript to AI: in June 2024 Omio picked two people to start an AI team reporting to the CEO and CTO, and he learned on the job, from his first API call to an LLM up to a consumer-facing agent whose backend runs on nothing but MCP. From why a bigger model with medium thinking came out cheaper than the mini, to capping tool calls because LLMs are built for token maxing, to the whale hunting request that showed his team guardrails are subjective, this is a conversation about what production agentic systems look like once the tutorials run out.
📻 Never Miss New Takeaways
Get notified when new episodes drop. Join our community of senior developers learning from real scaling stories.
💬 Share These Takeaways
Want More Insights Like This?
Subscribe to Señors @ Scale and never miss conversations with senior engineers sharing their scaling stories.