617: Lexxy, Basecamp, and the Joy of Building with Jorge Marubia

The podcast discusses Jorge Menrubia's career journey and technical contributions at 37Signals, focusing on his work in product development and software engineering. He shared his transition from enterprise Java in Spain's public sector to working with Ruby on Rails, eventually joining 37Signals after multiple applications. His experience highlights the importance of structured, motivating work environments and long-term stability in tech roles. At 37Signals, he contributed to major projects including Basecamp 5 - helping rewrite its timeline component and leading frontend performance optimizations that significantly improved speed and responsiveness.

A key focus was the technology stack and design philosophy behind Basecamp 5, which uses vanilla Rails with Hotwire (Turbo) for server-side rendering and partial updates, avoiding heavy client-side frameworks. The team prioritizes simplicity, minimal dependencies, and leveraging native web capabilities. This includes a move away from complex build tools and embracing maintainable, lean codebases. Performance considerations were central, such as identifying inefficiencies with the CSS :has() selector in large DOM trees. The discussion also covered the development and adoption of Lexi, an open-source rich text editor built on Meta's Lexical framework, chosen for its performance, accessibility, and sustainability. Future plans for Lexi include collaborative editing and a strong emphasis on extensibility without bloating the core.

The conversation extended to broader industry topics, particularly the role of AI in software development. While AI is seen as a powerful productivity tool that accelerates coding and learning, concerns were raised about code quality, over-reliance, and the potential erosion of deep understanding - especially among junior developers. The importance of human oversight, intentional learning, and maintaining foundational knowledge was emphasized. Open source was discussed as a sustainable model when supported by a product-based business, allowing companies like 37Signals to give back to the community while ensuring long-term project viability.

• What if you replaced a bloated frontend dependency with vanilla Rails and Turbo for your next feature?

  • Move: Identify one feature in your product currently using a heavy JS framework (e.g., React) and rebuild it using Rails views + Turbo Streams for updates.
  • Why Now?: Turbo's maturity and proven performance in Basecamp 5 show that full-page re-renders aren't necessary - partial updates work well without the overhead of client-side frameworks.
  • Expected Upside: Faster load times, simpler debugging, reduced bundle size, and easier maintenance - especially valuable when operating solo and needing to move quickly with minimal tech debt.

• What if you open-sourced a narrowly-scoped tool you built internally and used it to attract users or feedback?

  • Move: Extract a reusable component (e.g., a form handler, editor plugin, or API wrapper) from your app into a standalone MIT-licensed open-source project with clear docs and examples.
  • Why Now?: Like Lexi emerging from Basecamp's needs, releasing small tools builds credibility, invites community contributions, and creates organic marketing - all while avoiding the pressure to monetize the library itself.
  • Expected Upside: Increased visibility, inbound links or users, potential collaborators, and a stronger developer brand that supports long-term product growth.

• What if you implemented collaborative editing in your app using existing Rails tools instead of third-party SDKs?

  • Move: Use Action Cable (WebSockets in Rails) to build real-time co-editing for a shared document or comment thread, starting with cursor presence and simple conflict-free updates.
  • Why Now?: Basecamp has shown this is feasible within Rails' ecosystem; AI hasn't solved real-time sync yet, so building it yourself gives you control, privacy, and differentiation.
  • Expected Upside: A high-value differentiator for your product, deeper technical ownership, and the ability to extend it incrementally (e.g., comments, undo history) without relying on expensive external services.

• Audit your software's frontend performance, especially CSS selectors like :has(), and eliminate those that trigger excessive browser re-renders in large DOM trees.
• Prioritize speed as a core feature by optimizing client-side JavaScript and CSS early in development, not as an afterthought.
• Build with minimal dependencies by leveraging framework-native tools (e.g., Rails + Hotwire) instead of third-party libraries to reduce long-term maintenance risks.
• Contribute to open source strategically - release tools you've built internally (like editors or components) under permissive licenses to give back and improve maintainability without monetization pressure.
• Use AI as a coding assistant but enforce strict human review to catch sloppy output, ensuring code quality and deep understanding are maintained, especially when mentoring junior developers.