Luis Montoya

Legacy Ruby on Rails applications don’t fail because of Rails. They fail because of how we treat them. Over the past few years, I’ve worked on multiple Rails applications that were 5–10+ years old. Some had massive technical debt, slow performance, and onboarding nightmares. The common reaction was always the same: "We need to rewrite this." But here’s what I’ve learned — most legacy Rails apps don’t need rewrites. They need leadership, discipline, and strategy. A legacy Rails application is not a liability. It’s a system that has survived real users, real scale, and real business pressure. The real problems usually look like this: • Business logic scattered across controllers, models, and callbacks • God models that do everything • Fear of touching code because nothing has tests • Performance bottlenecks hidden behind years of patches • Developers adding quick fixes instead of long-term solutions And over time, complexity compounds. But here’s the truth most people miss: Legacy Rails apps can become high-performing, scalable systems without rewrites. What actually works: • Introducing service objects to isolate business logic • Adding tests around critical workflows first (not chasing 100% coverage) • Gradually refactoring instead of rewriting • Improving database indexing and query efficiency • Removing magic and making the system more explicit • Improving developer experience so teams can move faster with confidence Rails itself is rarely the bottleneck. Lack of structure is. Some of the fastest-growing companies still run on Rails. Not because it’s trendy, but because it’s productive, stable, and battle-tested. The goal is not to avoid legacy. The goal is to evolve it. Because a well-maintained Rails application can scale for a decade or more. And the engineers who know how to transform legacy systems into scalable architecture are the ones who create the most impact. Curious to hear from others — what’s the biggest challenge you’ve faced with legacy Rails applications? 🤨 #ruby #rubyonrails #legacysystems

31

1 Comment

Senior engineers in LATAM are being recruited aggressively by US companies. The offer is simple: Work on their products. Join their teams. Same timezone. Better compensation than local. If you're a CTO, you've probably felt this. Your best people get LinkedIn messages daily. Offers keep climbing. You can't match Silicon Valley salaries. If you're a senior engineer, you know this too. The opportunities are real. But most of them treat you like "offshore staff," not a real team member. Here's what's changing: The best setups now are hybrid. Engineers in LATAM working directly with US product teams. Integrated. Not outsourced. Same standups. Same Slack. Same ownership. For CTOs: You can access this talent without losing control or culture. For engineers: You can work on world-class products without being treated as second-tier. If either of these resonates, let's explore what's possible. #EngineeringTalent #TechHiring #LatamEngineers #RemoteTeams

2

🚀 Meta just announced their Llama API at the first-ever LlamaCon developer conference! This new API will let developers build applications powered by Meta's Llama AI models, starting with Llama 3.3 8B. They're promising they won't use customer data to train their own models, and you can transfer any models you build to another host. For those working with the new Llama 4 models, they're offering special options through partnerships with Cerebras and Groq to help with prototyping. Meta's clearly making moves to stay ahead in the open model space where they've already seen over a billion downloads of Llama models! 🔥 Who's excited to start building with this? Access is limited now but will expand "in coming weeks and months." Any developers here planning to try it out?

6

If you’re a technical founder, you already have leverage. If you’re not, learning some code closes more gaps than most hires. Listen to Rodrigo de la Garza on YouTube, Spotify and all your favorite podcast platforms.

3

1 Comment

I’ve been catching up on some incredible content lately and wanted to share a few shoutouts that have genuinely shaped how I think about GTM, talent, and scaling across regions. First — the work Enzo Cavalie is doing with Startupeable is absolutely brutal (in the best way). I love his podcasts — practical, founder-first, and grounded in real operational experience. If you haven’t tuned in yet, it’s worth your time. Second — I want to put a spotlight on Javier Ramírez Lugo (Cuota), a partner we work closely with at Timbi and someone I highly recommend personally. The perspective he brings — especially around expanding B2B sales in different regional markets — is rare and super valuable. In particular, here are three things that stood out from his recent piece (link below): 1️⃣ How he broke down selling in Latin America vs. the US — not just culturally, but strategically, structurally, and in terms of motion design. This is the kind of thinking that separates good GTM from great. 2️⃣ Real playbooks for building predictable sales engines in early-stage and scale-up environments — grounded in examples from multiple unicorn contexts. 3️⃣ The emphasis on talent and team design — how the right hires, at the right time and with the right incentives, completely shift velocity. Working alongside Javier has been a real pleasure — not just because he is smart, but because he gets operator-led execution in a way that aligns with how we think about talent and growth. If you’re building in #LatAm or #scaling into the region (or just expanding commercially overall), here’s to more content that actually moves the needle 🚀: https://lnkd.in/e7P2RXXM

11

1 Comment

𝗕𝗲𝗶𝗻𝗴 "𝗮 𝗴𝗼𝗼𝗱 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿" 𝘄𝗼𝗻'𝘁 𝗴𝗲𝘁 𝘆𝗼𝘂 𝗮 𝗴𝗹𝗼𝗯𝗮𝗹 𝗷𝗼𝗯 𝗶𝗻 𝟮𝟬𝟮𝟱. 𝗛𝗲𝗿𝗲'𝘀 𝘄𝗵𝗮𝘁 𝘄𝗶𝗹𝗹. I see it every day: brilliant LATAM developers sitting on the sidelines, waiting for their "big break." Meanwhile, less technically skilled devs are landing $80K+ remote roles. The difference? It's not code quality. Here's what actually gets you hired: ✅ 𝗘𝗻𝗴𝗹𝗶𝘀𝗵 𝘁𝗵𝗮𝘁 𝗱𝗼𝗲𝘀𝗻'𝘁 𝗺𝗮𝗸𝗲 𝗖𝗧𝗢𝘀 𝘀𝗾𝘂𝗶𝗻𝘁. If they have to decode what you're saying in a Slack message, they'll pass. Harsh? Yes. True? Absolutely. ✅ 𝗔 𝗽𝗼𝗿𝘁𝗳𝗼𝗹𝗶𝗼 𝘁𝗵𝗮𝘁 𝘀𝗽𝗲𝗮𝗸𝘀 𝘁𝗵𝗲𝗶𝗿 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲. That genius React app with a Spanish README? Invisible to 90% of global companies. Your code might be perfect, but presentation kills opportunities. ✅ 𝗔 𝗟𝗶𝗻𝗸𝗲𝗱𝗜𝗻 𝘁𝗵𝗮𝘁 𝘀𝗰𝗿𝗲𝗮𝗺𝘀 "𝘀𝗲𝗻𝗶𝗼𝗿 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿." Your profile IS your first impression. If it looks like you copied it from a bootcamp template, you'll get bootcamp-level offers. ✅ 𝗗𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝘀𝗸𝗶𝗹𝗹𝘀 𝘁𝗵𝗮𝘁 𝗱𝗼𝗻'𝘁 𝘀𝗹𝗼𝘄 𝘁𝗲𝗮𝗺𝘀 𝗱𝗼𝘄𝗻. Remote work lives and dies on written communication. If you can't explain a bug fix clearly, you become the bottleneck everyone avoids. ✅ 𝗧𝗶𝗺𝗲 𝘇𝗼𝗻𝗲 𝗿𝗲𝘀𝗽𝗲𝗰𝘁 𝘁𝗵𝗮𝘁 𝗴𝗼𝗲𝘀 𝗯𝗲𝘆𝗼𝗻𝗱 "𝗜'𝗺 𝗳𝗹𝗲𝘅𝗶𝗯𝗹𝗲." It's not enough to say you'll work US hours. You need systems, boundaries, and habits that prove you can deliver consistently across time zones. The brutal truth? Global jobs don't go to the best coders. They go to developers who signal they're ready for global teams. LATAM devs: which of these is blocking you right now? (And please, be brutally honest.)

12

Jose de Cabo flipped the model: → Developers set their own rate. Remotely doesn't touch it. → A fixed, transparent fee goes on top — not a percentage. → Give your developer a raise or bonus? Remotely doesn't get a cut. The second-order effect? The best senior talent flocked to his model. Because the best engineers aren't just choosing based on rate — they're choosing based on respect. Transparent pricing isn't just ethical. It's a competitive moat for attracting top-tier talent. --- 🎧 Listen here: https://lnkd.in/enveyCF4 --- #HumanCloudPodcast #FutureOfWork #TransparentPricing #Staffing #TalentStrategy

2

Check out the short summary of Angularidades episode #69 with our guest Mauricio Arce Torrez, exploring when and how to apply microfrontends in Angular projects. ✔️ Why Angular doesn't include native microfrontend support ✔️ When organizational complexity justifies this architecture ✔️ Tools for runtime composition in Angular ✔️ How to maintain design consistency and shared UX across distributed teams 📖 Read the summary in English: https://lnkd.in/e2YV4UDS

15

Your Roadmap is Full. Deadlines are Approaching. Hiring won’t Move Fast Enough. This is where staff augmentation makes sense. Instead of waiting months to build a team, you extend your delivery capacity with ready engineers who plug into your workflow and ship to your standards. You keep ownership of scope, priorities, and decisions. What makes it work • Clear product ownership • Defined requirements and success criteria • Strong communication and delivery reporting What breaks it • Vague scope • No decision owner • Weak execution governance It’s not staff augmentation versus hiring. It’s about how much capacity you need, how fast, and for how long. #ITStaffAugmentation #TechLeadership #TeamScaling #ProductDelivery #SoftwareDevelopment #StartupGrowth #DigitalTransformation #AI

6

🧼 Writing clean code in Angular isn't just about prettier files. It's about performance, scalability, and future-proofing your app. In our latest tech blog, our frontend expert and Sr. Software Engineer, Mauricio Mage shares practical ways to apply SOLID principles, embrace reactive patterns, and leverage Angular’s latest features like Signals for cleaner, more maintainable code. Whether you're building a new Angular project or refactoring legacy code, this is a must-read. 📖 Dive in: Writing Clean Code in Angular: https://lnkd.in/dcEYBSyg #Angular #CleanCode #SoftwareEngineering #Frontend #WebDevelopment #ZartisTechInsights #TeamZartis

33

A good read from Sabrina Fernández Zambrano on how to get better results when using AI in frontend development. AI tools are powerful, but the quality of the output still depends a lot on how we guide them. Prompt refinement, iteration, and clear constraints make a big difference. If you're using AI in your frontend workflow, this article has some useful insights. https://lnkd.in/epVtbiZU

5

🚨 New episode of Señors @ Scale live! Trailer below 👇 🎙 Rails at Scale with Adrian Marin 🥑, founder of Avo and host of FriendlyRB This one’s for Rubyists, Rails engineers, and anyone curious about why Rails still powers serious products in 2025. Adrian Marin has been: 💻 A non-technical grad turned developer, breaking into programming through side projects 🛠 The founder of AVO, a toolkit that makes building Rails admin panels as smooth as Laravel Nova 🌍 A community builder, running the FriendlyRB conference and even inventing a Ruby Passport for attendees In this episode, we cover: ⚡ Why Rails is still the fastest way to go from idea to product (Adrian built a whole app on a 10-hour flight) 🧩 What makes Ruby unique — from metaprogramming to the fact that even nil is an object 🛠 How Hotwire changes frontend development by shipping HTML instead of JSON 🔑 Why Tailwind CSS clicked for Adrian and how it fits into Rails workflows 🌱 The importance of community, conferences, and building weird but memorable traditions 🎧 Listen now: ▶️ YouTube: https://lnkd.in/dqxCewdK 🎧 Spotify: https://lnkd.in/dJe-dHFr 🍏 Apple: https://lnkd.in/dbdCuuCf 📬 Newsletter: https://lnkd.in/d3cUAzpJ #rubyonrails #rails #ruby #softwaredevelopment #hotwire #tailwindcss #avo #engineeringculture #developercommunity #webdevelopment #señorsatscale

8

1 Comment

Hot take 🔥: Most React apps don’t actually have performance problems. They have perceived performance problems. I see developers: • obsess over useMemo and useCallback • refactor perfectly fine components • add memoization everywhere • optimize before measuring anything Meanwhile: • the real bottleneck is an API call • images aren’t optimized • unnecessary network requests exist • large lists aren’t virtualized • users don’t even notice the “problem” React performance should be handled like this: 1️⃣ Measure first (Profiler, DevTools) 2️⃣ Fix real bottlenecks 3️⃣ Optimize what users feel, not what looks bad in code Premature optimization doesn’t make apps faster. It just makes code harder to reason about. 💬 Question: What’s the most unnecessary optimization you’ve ever added to a React app? #ReactJS #FrontendDevelopment #WebDev #Performance #JavaScript #SoftwareEngineering

3

One thing I’ve learned in software development is that shipping fast can feel like progress, but it often becomes a dead end. Rushing usually creates more problems for the client than it solves.

3