The insight that payments are a lot like pull requests has remained a core part of Routable’s DNA to this day — it influences everything we do.
Like many start-up stories, the co-founders of Routable, Tom and Omri began theirs in a basement that they entered each morning in the dark and left each evening… also in the dark. Over the course of 9 months and 300 customer development interviews, they realized that business payments were a lot like pull requests— the mechanism software engineers use to alert their team about changes to code and get it reviewed before it’s deployed. With the vision of building an engineering and technology-centered company for finance teams, this insight was key to making that vision a reality.
That insight has remained core part of Routable’s DNA to this day — it influences not just our product development and design process, but also our hiring process. It’s how we get the best engineers in the world to work on modernizing business payments with us.
Here’s how business payments are similar to pull requests.
Tickets are just bills and invoices
If you’re an engineer, you’re probably familiar with tickets — at most of the places I’ve worked, we’ve had some form of ticket driven development where you begin coding a feature or fixing a bug after a ticket has been assigned to you. This is important to stop rogue coding and ensure that there is a record of every change in the product for compliance, debugging and more.
Like an engineering team is driven by tickets, finance teams are driven by bills and invoices. Before they can transfer or request money, they need to make sure there is a record of every transaction for compliance and reporting purposes.
Bills can come in at any time of day, in a million different formats, and from a bunch of different sources. Invoices that are sent out are hopefully in a more standardized format, but different vendors will still have different requirements that you must meet to get paid.
New code and new payments need to be double-checked for validity
So let’s say you’re an engineer. You got a JIRA ticket and coded up a brilliant solution. The next step is to open up a pull request and share your work with the team for feedback.
The tests aren’t passing. Your team has a continuous integration service that checks for known security vulnerabilities, style violations, and broken tests. Until you’ve made all those checks happy and gotten the ✅ s that you need, you can’t send this out to your team to review.
Finance is really similar. Before an invoice or payment can be submitted, someone on the team needs to check bank account validity, if there is money in the account to spend, if they’re past your bank’s cut-off time for same day wires, and much much more. Finally, they need to ensure that the invoice or payment is properly recorded in your accounting software/ERP so there is a clear record of everything (especially come tax season).
There are multiple levels of approval
Excellent — the tests are passing! Now it’s time to send this to your team to review. Depending on what part of the codebase you’re working in, you might even need to satisfy that principal engineer that’s held personally responsible for any defect that makes its way into production.
Again, finance is really similar — they can’t just move $15,000 without at least one other set of eyes. For large transfers of money, expect multiple levels of approval all the way up to the CFO before an invoice can be sent or a bill can be paid. Just like in software, an extra 0 or a period in the wrong place can have a huge impact.
Shipping code is just like sending a large payment
In an incredible turn of events, the principal engineer loved your code and even gave you a little -it emoji. It’s the end of the day Thursday though and you have a concert that evening — You’re pretty sure your code is good to go, but you’ve been wrong before and you’re not trying to get paged during the show. You hold off until Friday morning to merge.
Same deal in finance — they’re pretty sure there’s enough to cover a large transfer, but they also know that a large transfer into the company account will clear tomorrow morning. So just to be safe, they schedule the payment to send tomorrow. ✨
Rolling back code is like cancelling a payment (sort of)
It turns out that you made the right decision to delay shipping your code… an hour after it went out. Luckily, it impacted very few users and you were able to roll back the code right away and mitigate the damage. The principal engineer is happy with your good judgement to ship in the morning and you’ll live to code another day.
This is where finance really has a rough go of it — it’s not always as convenient to roll back. Invoices are pretty straightforward to cancel, but payments are trickier. There’s usually a window of only hours that they can cancel a check or ACH payment. That’s why all the checks and processes that we’ve grown used to in software are even more important in the finance world!
Business payments as PRs is our ethos
Engineers are usually unaware of the complexities inherent in business payments. We’re used to PayPal and Venmo where it’s literally a click of a button to transfer money to a friend for lunch.
If you pause for a second to think about it though, it’s obvious that there is a boatload of complexity that those companies are hiding behind a beautiful, simple interface.
It’s the same at Routable — behind our simple UI, we’ve hidden away the complex problem of integrating with multiple accounting ledgers, legacy banking processes and managing the multi-step process of moving money between businesses.
Once we share this analogy, it’s an aha moment for engineers — business payments become an interesting problem to solve. Not only that, it builds empathy for our customers and helps us build a better product.
It’s also made product development really simple for us
Interested in working at Routable? Join our team – we’re hiring.
