Talk at wroclove.rb 2024 by Radoslav Stankov. Walks through how he structures the front end of his Angry Building ERP using the ViewComponent gem. Opens with his previous Product Hunt stack (Rails + GraphQL + Apollo + Next.js) and explains why, for Angry Building — a Rails weekend project — he wanted a Rails-only approach with Tailwind, minimal JavaScript, and extensive end-to-end tests. Criticizes Rails' default helpers/views/partials mix as an untestable 'wall of partials' and introduces ViewComponent as a way to build testable, reusable UI pieces. Presents a personal checklist for when to use a ViewComponent (code reused across controllers, HTML-generating helpers over ~3 lines, complex conditional logic, copy-pasted patterns, JavaScript-backed components) and when to stick with partials (underscore form) or view helpers (e.g. format_money). Introduces a mental split between UI components and domain components (e.g. money → product_price). Code walk-through of real components from Angry Building: a `component` sugar helper; a stats component using render_many / 'as :number' aliasing; a filter_form component built on a builder pattern (implemented before ViewComponent slots existed) exposing inputs like search, select, date_range, text; a page_header component using slots for breadcrumbs and action buttons, a `display` i18n helper for inferring object titles (display_name/name/title → string), and a before_render hook inferring page titles from the controller's translation table; a table component that started life as a view helper and now uses a builder DSL to declare columns (name, apartment, record, date, money, block). Uses a fetch-with-fallback pattern that raises in development/test but silently falls back in production. Testing approach: no unit tests — instead, smoke tests via Capybara that visit each Lookbook preview page and make sure it doesn't blow up, plus end-to-end tests for business logic. Advice: don't start a design system from button components (too many variants). Q&A covers comparing ViewComponent with React / React Native (pick per-product trade-offs) and testing strategy (smoke tests, no unit tests).