For engineering teams

Modernize a legacy Rails application without a big-bang rewrite.

Fabrica observes your running system, turns its behavior into a reviewed specification, rebuilds selected workflows and tests them side by side before any traffic moves. We are starting with Ruby on Rails, and other stacks can be discussed on request.

Capture and Lock

What we observe, and how.

This is a proposed architecture for discussion. A pilot confirms compatibility and availability for each component.

Rails instrumentation

Requests, jobs, errors, SQL

Active Support instrumentation hooks, with observations tagged by release version.

Schema and data

Read-only catalog inspection

Keys, types and constraints from the live catalog and migrations, plus approved data-quality profiling.

Reporting and lineage

Reports mapped to outputs

Views, report SQL and ETL jobs mapped to the business outputs they feed, with important totals reconciled.

Usage evidence

Product analytics

PostHog event exports, GA4 via BigQuery or other clickstream sources where they exist.

Context and change

Code, tests and owners

Release and schema history, existing tests and owner review fill the gaps that observation can't.

Coverage review

Measured against a threshold

Critical workflows, business cycles and exceptions are checked against a threshold that owners and engineers agree.

Routing and rollback

The legacy app keeps serving until the evidence supports a move.

A reverse proxy in front of the legacy app initially sends all traffic to it. Rebuilt workflows run as a modern twin with isolated data and controlled side effects. When proof passes, gated cohorts move over, and rollback is a routing change.

  • Users and APIs keep calling the same endpoints
  • Agents build the twin and engineers review it
  • Cohorts move in evidence-gated steps
  • Data cutover is planned separately, covering mappings, backfill and sync, write ownership, reconciliation and rollback

What your engineers review

What your engineers can check.

  • The System Specification and its links to evidence
  • Pull requests built to written standards and reviewed
  • Proof results covering outcome, data, permission and performance differences
  • The data transition plan, before any live writes go to the twin

Known limits

Limits we state up front.

  • Compatibility with your Rails version, gems and hosting is confirmed in a pilot
  • Collection overhead is measured, and collection failures stay off the request path
  • Background jobs, queues and batch reports need their own handling, scoped in the assessment
  • Not every Rails app should be rebuilt, and an upgrade may be the better answer

Other stacks

Starting with Rails.

We are starting with Ruby on Rails because its instrumentation and schema tooling are mature and well documented. We can discuss Java Spring, .NET Framework, PHP and Django systems, and an assessment would confirm what observation is possible.

Want your engineers to pressure-test this?

Book a technical call. Bring the system, its constraints and your hardest questions.

Book a technical call