Loading…
Ramp
Corporate card and spend management platform building innovative financial technology solutions for businesses.
48 postsWebsite
Latest articles
Ramp ·
Growth Intern to Procurement New Grad
A 2023 summer internship on Ramp’s growth engineering team changed the author’s view of software engineering and led to a return as a new graduate engineer. The team accelerated outbound sales through fast experiments, metric ownership, and decisions about whether promising tactics deserved scalable systems, rather than following the thorough specification process typical of regular projects. His work included reducing third-party data-enrichment costs, building AI-driven outbound-sales tools, adding observability and service monitors, and conducting competitive intelligence projects. He returned to join the new procurement product line, where he helped match card transactions to purchase orders and led additional projects. The post also recommends rapidly building system context through code review and on-call shadowing, while full-time engineers should weigh velocity against maintainability and take initiative on less-defined problems.
Aaron AbrahamRamp ·
A Fall Internship at Ramp: Improving Reimbursements
During a fall internship at Ramp, a backend software engineering intern worked on the reimbursements team and describes projects that improved reimbursement flows while providing full-stack experience. One early change clarified multi-currency mileage reimbursements by showing both the expense currency and the payout currency, while later work overhauled mileage support with live navigation storage, frequent-trip recommendations, commute deductions, and automatic e-receipts. The post also discusses using LLMs to predict merchant categories from receipt text, enhancing merchant matching, and adding monitoring and alerts for OCR categorization errors. The reflection emphasizes measuring feature usage and outcomes, writing and revising specifications before implementation, leaving reusable code, and using Ramp’s transparent documentation and collaborative support. The internship concluded with a return to the University of Waterloo planned for 2025.
Sat AroraRamp ·
Building Ramp's MCP server
Ramp built an open-source MCP server that exposes its developer API to LLMs through tools and a SQL interface, enabling natural-language access to business spend data. Using FastMCP in Python and Claude Desktop, the prototype could run analyses, generate visualizations, and issue cards on demand, but pagination struggled beyond a few hundred transactions because of miscalculations, context limits, input sizes, and token use. The team replaced bulk responses with an in-memory ETL that flattens API JSON into SQLite, then exposes load, transformation, and query tools; an OLAP-powered API was added for reporting workloads that caused timeouts. This let Claude analyze tens of thousands of spend events with aggregate and window functions while reducing token usage, although API latency, occasional reliability problems, tool-selection errors, and security risks remain; audit logs, OAuth scopes, and constrained tools provide mitigations, while write actions await a safety framework.
Junho ChoiRamp ·
Turbo-Charging ML Development
Ramp describes Turbo, a YAML-based configuration system created to reduce the time and engineering effort required to deploy machine-learning models while preserving reproducibility and explainability. Its abstraction represents end-to-end feature and model pipelines, datasets, and shared train and predict jobs; Python entities and aggregates built with Pydantic are materialized through JobSpec and executed locally or remotely before models are stored. A developer can run a training workflow with a YAML file and a few lines of code, then adapt the same schema for prediction by changing a few configuration lines. The first Credit Risk model required nearly four months and more than 3,000 lines of deployment code; with Turbo, new models deploy in under five minutes using about 40 YAML lines on average. The system also standardizes practices such as holiday alignment in time-series models and supports nearly 20 deployed models built by nine developers.
Ryan Stevens, Ryne CarboneRamp ·
From RAG to Richness: How Ramp Revamped Industry Classification
Ramp's former industry classification system combined third-party data, sales-entered information, and customer self-reporting, creating inconsistent, overly broad, and unauditable categories. Precise classification was needed for compliance, portfolio monitoring, sales targeting, and product analytics, despite fuzzy boundaries, sparse data, and no ground truth. Ramp migrated to six-digit NAICS codes and built an in-house Retrieval-Augmented Generation model that embeds business data, retrieves candidate codes, and uses an LLM to select a final prediction. The system evaluates retrieval with accuracy-at-k and final predictions with a hierarchy-aware fuzzy-accuracy metric, while ClickHouse stores knowledge-base embeddings and Kafka logs intermediate results. Deployed guardrails validate output codes, and the model has improved data quality, consistency, auditability, and control over tuning and costs.
Ryne CarboneRamp ·
Improving Retrieval on Ramp with Transaction Embeddings
Ramp developed transaction embeddings to help automate accounting coding, where employees choose general ledger (GL) categories for transactions. The model represents enriched transaction features—such as merchant, category, department, location, amount, memo, spend program, and trip—as stringified documents labeled with chart-of-accounts codes. Starting from a pre-trained encoder, it is fine-tuned with sentence-transformers and BatchSemiHardTripletLoss, using large batches and contextual sampling to learn embeddings whose similarity is measured with cosine similarity. Triplet loss pulls same-label transactions together and pushes different-label examples apart, while informed mining addresses subtle distinctions such as Travel: Sales versus Travel: Engineering. The embeddings support GL coding suggestions, high-confidence defaults, business-spend similarity analysis, and transaction context for LLM-enabled features, with the stated aim of keeping predictions personalized and data private.
Calix Huang, Anton BiryukovRamp ·
Make Better Decisions by Embracing Uncertainty
Ramp uses multi-armed bandits to choose among third-party bank-linking providers when provider performance varies by financial institution and available data is noisy, incomplete, or stale. Instead of maintaining separate, static A/B tests, it applies Thompson Sampling, modeling each provider’s success probability with a Beta distribution and repeatedly sampling, routing traffic to the highest sampled value, then updating the model from the result. Simulations examined changing success-rate trends, noise, volume, rolling-window size, trend type, and initial conditions; the algorithm generally exploited clearly better providers, split traffic more evenly when rates were close, and recovered eventually from incorrect starting conditions. In a sequential quasi-experiment, Thompson Sampling increased financial-institution linking success by 10% and reduced customers with manually uploaded bank statements by 25%.
Ryne CarboneRamp ·
Increasing velocity by modernizing a Python codebase
An expanding monorepo of machine learning workflows became difficult to change safely as contributors and projects multiplied, undermining the velocity it was intended to support. The team replaced requirements.txt with Poetry, using pyproject.toml for direct dependencies and poetry.lock to record transitive dependencies and hashes, while virtual environments simplified setup. Ruff standardized formatting, linting, and CI enforcement; pytest addressed corner cases and bad assumptions, and mypy added annotations and stricter checks that could expose incompatible changes across call sites. To adopt these controls incrementally, the team used ignore comments and staged remediation, including a script for mypy exceptions, while an ignored revision preserved useful git blame history. The resulting codebase was kept in better shape, enabling faster iteration with greater confidence.
Peyton McCulloughRamp ·
Learnings from Building and Scaling Ramp’s Growth Engine
Ramp’s growth team explains the principles and systems it used to scale customer acquisition since launching its first product in February 2020. By February 2021, annualized run-rate revenue reached $12 million, crossed $100 million a year later, and was far beyond that figure at the end of 2023. The approach combines first-principles thinking and prioritization with fast, data-driven MVP experiments, then productionizes ideas that show significant impact; it also relies on full-stack capabilities across business operations, engineering, and sales. An AI email overlay that classified and prioritized sales messages helped representatives handle more prospects and increase conversion rates. The team attributes tens to hundreds of millions of dollars in sales pipeline and real revenue to these practices, while noting that sustainable growth requires a solid product and real addressable market.
Hima TammineediRamp ·
Engineering Management
The post presents an engineering-leadership perspective on how the author incepted and grew Ramp’s Core Engineering team from zero to 50+ engineers, while noting that the guidance is shaped by a company under Dunbar’s number. It defines an engineering manager’s role as unblocking reports, appreciating their contributions with technical depth, and helping them advance through the leveling deck. The central leadership practice is “pay attention”: build a coherent organizational model, maintain consistent direction, understand motivations, and avoid feedback that misses important tradeoffs. Core Engineering favored hiring individual-contributor engineers and moving some gradually into management after testing their aptitude. The post also presents one-on-ones as a way to build organizational context, and describes slow growth, intern mentorship, and prompt dispute resolution as forms of compounding management quality.
Patrick AndersonRamp ·
Abstraction Engineering
Ramp’s early product encoded opinionated limits, but by fall 2022 customers needed configuration based on departments, accounting fields, subsidiaries, budgets, and HRIS fields, making incremental feature work increasingly complex. The team reframed these requests as a generic workflows platform in which Python functions served as actions, boolean logic as conditions, and workflows as graphs persisted in Postgres. After rejecting a dependency-based design, they built a graph-traversal engine, a Postgres-backed queue that retries asynchronous tasks, and an SDK for expressing constructs such as elif and else. The infrastructure now supports customer-facing policies and internal tasks; more than 45 million workflows have run, at over a million per day, while the core engine has not changed since launch. The project took weeks upfront but saved the engineering organization months by turning complex features into applications of broader abstractions.
Rodda John, Jared WassermanRamp ·
Finding the right balance of speed and security through just-in-time access to cloud resources
Ramp’s rapid growth exposed problems in its AWS access model: three broad roles created persistent production access for some senior engineers while junior engineers depended on seniors for queries. The team first reorganized permissions into more than 20 team-specific AWS Identity Center groups, each backed by permission sets and a Terraform module that presents IAM configuration through human-readable resource lists. It then introduced just-in-time access through ConductorOne by pairing each non-production role with an elevated production role, removing standing production access and provisioning entitlements through AWS SSO group membership. Team-owned requests were automatically approved, while cross-team requests went to the relevant tech lead, with temporary access and backup approval handling described in the design. The resulting model reduced exposure, preserved fast access to needed resources, and recorded production activity for accountability and audit purposes.
Julien ColombainRamp ·
Picking Low Hanging Fruit
The page identifies the item with the title “Picking Low Hanging Fruit,” but provides no accompanying article narrative or technical subject matter. Instead, it consists of HTML metadata, favicon and RSS references, JavaScript and stylesheet asset links, a notice that JavaScript must be enabled, and analytics snippets. The metadata names the site “Ramp Builders” and labels its RSS feed “Ramp Builders Blog”; the scripts reference Segment analytics and a Google Analytics configuration. No problem, implementation, experiment, outcome, or conclusion is described, so the title’s meaning and the post’s intended subject cannot be established from this text. There is no basis in the available material for a more specific technical classification.
Rodda John, Luke Zeller, Rahul SengottuveluRamp ·
How Ramp Accelerated Machine Learning Development to Simplify Finance
Ramp describes how its machine-learning organization used Metaflow to shorten the path from prototype to production for models spanning credit risk, fraud, growth, product, and Ramp Intelligence. Its initial riskiness model exposed long vendor-managed jobs, weak logging, limited Docker support, and substantial platform friction; the model took months to build. Metaflow, with developer-experience improvements, lets teams define flows in Python, run them locally or on AWS Batch, visualize results with cards, and connect production execution to Step Functions and Airflow. Ramp chose AWS-managed infrastructure, initially using Fargate before encountering startup and resource constraints, and later built a MetaflowOperator to simplify Airflow triggering and log access. After adoption, Ramp shipped eight additional models in ten months, recorded more than 6,000 Flow runs, and reports that data scientists can largely self-service while platform engineers spend less time debugging infrastructure.
Peyton McCulloughRamp ·
What I learned taking Ramp Bill Pay from 0 to N
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.
Pavel AsparouhovRamp ·
Moving Fast by Moving Slow: How We Built Payments at Ramp
Ramp describes why it delayed the launch of BillPay by about two months to replace its existing, ad hoc bank-transfer infrastructure with a new payments service. The earlier system encoded product-specific concepts such as employee bank accounts and reimbursement transfers, forcing each new use case to add bespoke data models, jobs, and scheduling logic. This friction became especially costly as the team anticipated additional payment products and vendor payments scheduled for future dates. The redesign used generic primitives—ACHDetails and TransferCanonical—to separate business logic from money-movement logic; it also treats failed transfers and retries as concerns requiring an auditable identity, history, and consistent provider mapping. The post argues that stress-testing assumptions, modeling relevant degrees of freedom, limiting conditional logic, and building platforms after recurring patterns can make future products faster to launch.
Shreyan JainRamp ·
How Ramp builds customer-first AI
Ramp describes principles for building customer-focused AI, contrasting embedded outcomes with superficial chatbot experiences it calls “AI washing.” The approach emphasizes integrating models into workflows, separating general models trained on aggregated and masked data from sensitive models that use private customer data temporarily through in-context learning, and requiring explicit opt-in for sharing contract data. It prioritizes user control and feedback over lengthy explanations, while using guardrails that constrain outputs through predefined interactive data blocks rather than relying only on censorship filters. Ramp cites contract term extraction, spend intelligence, pricing benchmarks, Copilot, and Jsonformer as examples of these practices. The stated goal is AI that saves customers time and money while protecting privacy and producing safer, more useful results.
Yunyu LinRamp ·
Responsibly mid-size: What Matters, Suffers
Moving into a mid-size company requires adopting processes and attitudes piecemeal rather than suddenly operating like a large enterprise, while preserving the ability to deliver customer value. The post challenges “clean code” as a universal standard, arguing from Sandi Metz’s discussion of churn and semantic complexity that important, frequently changed files are often large and complicated, making “bad code” an emergent feature of successful systems. It also uses Joel Spolsky’s case against rewrites to explain that ugly code may contain accumulated fixes for real bugs and operating conditions. The resulting advice is to distinguish code that manages responsibilities from code that does not, develop engineering judgment, and avoid letting aesthetic reactions damage collaboration, team cohesion, or delivery.
Pablo MeierRamp ·
Cost Efficient Snowflake CI
Ramp’s data team used Snowflake CI checks that created a full duplicate production database for each pull request, causing rising warehouse costs and up to 30 minutes of developer idle time as pull-request volume and model count grew. They changed the process by storing dbt manifest.json artifacts in S3, using dbt’s state selector to build modified models, and generating an upstream-model list for cloning. A custom dbt macro uses Snowflake’s information schema to create zero-copy clones of required production tables in the pull-request database, preserving a single namespace for debugging instead of relying on defer across databases. The resulting CI command sequence builds and tests modified models plus direct downstream dependencies, and the post reports a dramatic, mostly sustained dip in the rolling seven-day average warehouse cost despite higher pull-request velocity.
Kevin ChaoRamp ·
Rate limiting with Redis
Rate limiting at Ramp must handle third-party API quotas, globally paced Celery tasks, and inbound API traffic limited by authenticated application identities rather than only mutable IP addresses. Celery’s per-worker controls were insufficient for global limits, while queue prefetching could let rate-limited tasks block workers and stall queues. The team created a general framework for comparing algorithms and evaluated fixed-window, sliding-window, leaky/token-bucket, and Generic Cell Rate Algorithm (GCRA) approaches. They selected GCRA for implementation simplicity and compute and memory efficiency, storing a theoretical arrival time in Redis and using a Redis lock to prevent races. The implementation also uses floating-point timestamps, Redis server time, key expiration, unit tests, and manual testing; it has been introduced gradually across the three use cases, with monitoring, while additional algorithms remain planned.
Kwuang Tang