Ramp cut ML model deployment from 4 months to 5 minutes with a YAML config system

Ramp's first credit risk model took nearly four months and more than 3,000 lines of code to get into production. As a financial services company, Ramp also needed every model's outputs to be exactly reproducible on demand, which bespoke, one-off deployment code made hard to guarantee. Machine learning discussions tend to focus on the model itself, but engineering time was actually dominated by the 'feature pipeline' — the code that cleans, casts, and transforms raw data into usable inputs — which the team estimated was 99% of the real work.

Ramp's engineering team built Turbo, a YAML-based configuration system, to standardize this. They identified the entities shared by every ML workflow: a Feature Pipeline (raw data to features) and a Model Pipeline (features to predictions). A 'JobSpec' class reads a YAML file, materializes these as Pydantic objects, and submits them to a compute environment — a Train Job that fits a new model, or a Predict Job that loads one from the model store. Because both jobs share the same schema, deploying a model is close to copying a config file and editing a few lines.

The payoff was immediate: pipelines described in a config file today will produce the same results if run again in one or two years, as long as the underlying data hasn't changed, solving the reproducibility requirement directly. A migrated time-series forecasting model also picked up consistent holiday handling across the board for free, since every model built with the abstraction inherits the same feature-engineering logic instead of reimplementing it independently.

Turn every ML pipeline into two reusable pieces (features, model) described in one YAML file

Separating the Feature Pipeline from the Model Pipeline as reusable entities meant the 99% of ML work that isn't modeling only had to be solved once.

A declarative YAML schema, rather than a code library, meant engineers without ML background could deploy and maintain models without writing pipeline code themselves.

Training and prediction sharing one schema meant a developer only had to learn one set of concepts to do both, instead of separate tooling for each stage.

Standardizing feature engineering (e.g. holiday handling in time-series models) fixed a whole class of inconsistency bugs at once instead of patching each model separately.

When the same two-stage pipeline shape recurs across systems, encode it once as a declarative schema — it turns an expert-only, multi-month task into something any engineer can fill in.

By the time Ramp wrote about Turbo, a new model could be deployed in under 5 minutes with an average of about 40 lines of YAML, down from 4 months and 3,000+ lines of code. Nearly 20 models were in production, built by 9 different developers, many of whom had never trained or deployed a machine learning model before Turbo existed.