---
title: "What I learned taking Ramp Bill Pay from 0 to N"
description: "An engineer recounts lessons from taking Ramp’s Bill Pay from its first code in April 2021 to a publicly launched product that eventually became a product with multibillion annual total payment volume. For 0-to-1 work, the account emphasizes protecting core abstractions, including canonicalized payment statuses that reduce varied payment states to five, using mocked functions to coordinate parallel engineering, and reaching beta customers quickly. Customer feedback, session replay, and persistent iteration are presented as necessary because the first customer will usually expose substantial flaws. For 1-to-N growth, manual processes and duct tape must be prioritized for replacement according to user impact, error risk, and workload. Growing stakes also require testing, monitoring, contingency plans, gradual rollouts, QA, and documentation that helps engineers self-service onboarding."
---

# What I learned taking Ramp Bill Pay from 0 to N

[Ramp](https://yomu.fyi/company/ramp) · Pavel Asparouhov · Aug 1, 2023

**Type:** Explainer

## Summary

An engineer recounts lessons from taking Ramp’s Bill Pay from its first code in April 2021 to a publicly launched product that eventually became a product with multibillion annual total payment volume. For 0-to-1 work, the account emphasizes protecting core abstractions, including canonicalized payment statuses that reduce varied payment states to five, using mocked functions to coordinate parallel engineering, and reaching beta customers quickly. Customer feedback, session replay, and persistent iteration are presented as necessary because the first customer will usually expose substantial flaws. For 1-to-N growth, manual processes and duct tape must be prioritized for replacement according to user impact, error risk, and workload. Growing stakes also require testing, monitoring, contingency plans, gradual rollouts, QA, and documentation that helps engineers self-service onboarding.

## Context

The work covered two distinct phases of Bill Pay: creating a new product amid uncertainty and rapid decision-making, then scaling it as usage, customer reliance, and the engineering team grew.

## Approach / What changed

The account describes choosing durable system abstractions, using mocked functions to specify work precisely, launching quickly to beta customers, collecting behavioral and direct feedback, prioritizing manual-process replacement, adding testing and monitoring, and documenting the codebase for onboarding.

## Takeaways

- Canonicalized payment statuses reduced payment states across different payment methods to five, allowing Bill Pay features to be added without repeatedly handling payment-rail complexity.
- As usage increased, manual processes and ad hoc implementations were prioritized for replacement based on user-experience impact, potential for error, and manual-work volume.
- Scaling customer-facing operations required moving beyond YOLO merges toward gradual rollouts, comprehensive QA, extensive monitoring, and contingency plans.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture), [Monitoring](https://yomu.fyi/topic/monitoring), [Scalability](https://yomu.fyi/topic/scalability), [Testing](https://yomu.fyi/topic/testing)

- Source: [Ramp](https://builders.ramp.com/post/lessons-from-bill-pay)
- Source URL: https://builders.ramp.com/post/lessons-from-bill-pay
- Ingested by Yomu: 2026-09-01T01:33:53.244Z

[Read original post](https://builders.ramp.com/post/lessons-from-bill-pay)