Operators first
Every shipped feature came from a working operator's pain. Marketing-driven feature decisions belong on the floor of a venture pitch deck, not on a production roadmap.
We started RateStack because every pricing engine we'd worked on had the same two failure modes: black-box adjustments and brittle ratesheet ingestion. Both are solvable.
Residential mortgage capital markets runs on pricing engines that were built when the rule engine of choice was Excel macros and the integration of choice was email-with-attachments. Both have stuck around. We have friends who run capital markets for billion-dollar correspondents and they still spend hours reconciling adjustments by hand. Eligibility surprises at lock are routine. Audit responses take days. None of this is necessary.
The platform began as a bet: that the right primitives — versioned ratesheets, a stateless rule engine with full trace, two-stage eligibility, a hash-chained audit log — could deliver a pricing experience that's both faster and more defensible than what exists today. Building those primitives took longer than we expected. Once they existed, the rest of the platform fell out almost for free: locks, comp/margin, AMI, sell-side, MISMO import, webhooks with DLQ — they're all consumers of the same trace and the same audit chain.
We are not a hot startup. We are a small team building a serious tool for a serious industry. We will be here in 2030.
Operating principles
Every shipped feature came from a working operator's pain. Marketing-driven feature decisions belong on the floor of a venture pitch deck, not on a production roadmap.
We do not advertise what we have not built. We do not claim certifications we do not hold. We do not pretend a roadmap is a feature. The work is the work.
Spring Boot, MySQL, NATS, Redis, MinIO. The exotic stuff is in the algorithm, not in the operations. On-call should not be a research project.
We do not cold-call. We do not require procurement to start. We do not push timelines that don't serve you. Customers who want us find us; we earn the rest by being useful.
The team is small and remote-first across the United States. Engineering, product, and customer-success all sit in the same room (it's a Slack channel, but you get the idea). We do not have a dedicated marketing team, which is why this site reads the way it does — written by the people who built the system.
Engineering practices we will not compromise on: production code ships with tests; every feature ships with audit and observability hooks; security findings are paged; PII redaction is non-negotiable. We practice what the trust pages preach.
Customers we work well with: operators who want to understand how their pricing works, not just what number it returns. Engineers who want a REST or GraphQL surface and not a proprietary SDK. Compliance teams that read the trace.
If that sounds like your team, request a demo. If you're an engineer who wants to work on this stuff, see open roles.