Rails Frontend Implementation

You have a strong engineering team that ships features fast, and the UI is the thing that keeps slipping. Figma files get handed to backend developers who do their best, and the result is a reasonable approximation of the design, not the design.

This is the work we do. Design plus Rails frontend implementation, by the same operator, with the same hands on Figma and the actual production code.

What we build

Real Rails frontends, on the current Rails stack:

• Production UI on Rails 6 through 8, with Hotwire, ViewComponent, Tailwind, Sass and PostCSS as the toolset
• Design systems that ship (see Design Systems for the deeper system work)
• Page redesigns and full app UX, scoped per app
• Component refactors that consolidate two-and-a-half versions of every button into one canonical version
• Production-ready code, no invented build systems, no unnecessary dependencies

Why Meticulous

We have been shipping Rails since before 1.0. Meticulous's first Rails-based project shipped in late 2005, around the version 1.0 release. We have been writing Ruby and Rails continuously since.

The Rails Foundation hired us to redesign the official Guides in 2024, working with Amanda Perino. Code review came from various core team members, including Carlos and DHH.

The thing that is hard for clients to find elsewhere: a designer who codes, on the same Rails stack the team is shipping. Most product design shops hand off comps and call it done, and most Rails consultants do not do design. We do both.

How the engagement runs

We identify the workflows that matter most to your customers and business, then choose an approach that lets your team ship and learn. The work may include:

• Focused workflow improvement. A focused redesign of one app surface, with design and production implementation in the same engagement. Often the entry point.
• Full app redesign. Page-by-page or section-by-section, shipping behind feature flags, with design system work folded in as needed.
• Ongoing product improvement. Sustained design and frontend implementation as customer needs and business priorities evolve.

We agree on priorities, release milestones, and how to assess progress with your team before implementation begins.

FAQ

We already have designers. Can you just do the Rails implementation?

Yes. The "designer who codes" framing is what we lead with, but we also take pure frontend implementation work where the design is already settled and your design lead is in the loop. The thing we do not do is rebuild a UI from a Figma file without your design lead in the loop.

What if we do not use Hotwire?

Rails 6 through 8 with various combinations of Hotwire, Stimulus, Turbo, ViewComponent, Phlex, Tailwind, vanilla JS, or React are all in scope. We have stronger opinions about what Rails does well than about which JavaScript layer sits on top.

How long do projects typically run?

Timing depends on the change you need, the state of the application, and how your team releases software. We plan around useful improvements reaching customers and agree on milestones together.

What is the investment?

We start by understanding what better workflows would make possible: easier onboarding, more successful task completion, or fewer delivery bottlenecks. We shape the engagement and investment around the value of that change, with clear priorities and agreed measures of success.

What if we want to build the design function internally?

That is a different engagement shape. See Embedded Design for the build-the-function-and-hand-it-off work, including the operating model.

Who this is for

Rails teams of three or more engineers shipping production software, where the UI is the constraint and the team would rather invest in fixing it than keep apologizing to customers.

Start a conversation

If your Rails team's UI is the constraint, get in touch. If the source of the problem is unclear, the UI Coherence Diagnostic identifies the worst gaps and recommends fixes.