How SeatGeek Thought About Build Vs. Buy for their Unified Financial Backend System

IPO-readiness initiatives often highlight deficiencies in your revenue reporting processes and systems. If you’re in finance systems, your role is to evaluate whether to build or buy a unified financial backend system to solve these challenges. Building software in-house, can seem simple at first, but how do you make an informed decision and ensure the project is future-proof and successful?

I sat down with Joe Blanchett, Senior Product Manager, Finance Systems at SeatGeek, for an informative session on how SeatGeek navigated their build vs. buy decision and the key components they considered.

What was the trigger to decide between building vs. buying a unified financial backend system?

Joe: For us, the crucial trigger was IPO-readiness. We knew we were going to be a public company some day and we needed to close the books in a timely manner in order to report correctly.

Especially as we continued to grow through new product lines and business branches, we realized that accounting wasn’t able to use their time effectively. Instead of dedicating their time and energy on new product lines and flux analysis, accounting’s main work was preparing journal entry import files.

The main KPI we were looking at was our month-end close length. Our marketplace business is our bread and butter and the revenue recognition process for that line of business was incredibly manual, creating a lengthy process to close. We really needed a way to speed things up and technology was by far the best way to do that.

What did your timeline look like?

Joe: When I joined SeatGeek back in 2018, we were actually in the process of an internal build for a unified financial backend system. Four months after joining SeatGeek, we decided to stop the project.

One of the core reasons we scrapped the project was that we underestimated how much time and effort it requires to consistently build a revenue subledger and understand the different accounting rules, transaction treatments, and linkages between data.

Between 2019 and 2021, we ran on an Excel-based process where our accountants were coding SQL to pull reports. It was a very manual, spreadsheet driven process. We realized that there was a lot of undocumented knowledge that was hard to teach new hires.

Fast forward to 2021, we realized that at any time we could go public. We needed to find a solution that could provide a single source of truth, allow our accountants to stop coding SQL, and provide daily access to financials which led us to Leapfin.

Can you tell us more about why building your own unified financial backend system was unsuccessful?

Joe: There were two main challenges that made the project unsuccessful. First, when you build an internal data warehouse, you really need to have a full-time dedicated engineering team to the project. We just did not have enough staff to dedicate to that project.

Second, you need to possess a solid understanding at the individual transaction level how your transactions turn into debits and credits. Our challenge was that everything was done in a batch at the end of the month. We needed to interpret that in order to understand how the batch process corresponds to the transaction level at the smallest order level, which creates a lot of room for error.

What were the key components you evaluated when considering Build vs. Buy?

Joe: We had four primary considerations:

1. Our main consideration was a five year cost of ownership analysis. It became very clear to me and our engineering team that if we built a unified financial backend system, then this would be the only thing that they ever worked on.
2. Next, we considered the opportunity cost. If we built an in-house solution then Engineering would need to spend time working on the system and it’s bugs instead of focusing on revenue generating products or new business lines.
3. Our third consideration was time-to-value. It likely would have taken us around six months longer to build something similar to Leapfin. It’s unnecessary to wait longer to build something that isn’t as good from an end user perspective. It also would have prevented us from doing other things that needed engineering resources.
4. Finally, we thought about future-proofing considerations and maintenance costs. What happens if Stripe, Adyen, and Braintree each change their APIs at the same time? What kind of workload will we have that month? It’s more effective to have a 3rd party solution which has an entire team dedicated to addressing these issues vs. having our team managing them in an ad hoc manner.

After evaluating those components, it was very clear to me that we should buy something rather than build something.

Once you decided to buy a solution, what capabilities were most important to you?

Joe: We needed three major capabilities:

• Technical functionality: The key technical function we needed was the ability to lock the numbers in our reporting during what we call the “differential update”. The differential update occurs when you look at reporting for the past period and you find that the numbers have changed from what you reported in the previous period. This is not acceptable from a financial reporting perspective.
• Functional UI: Functionally, we needed to ensure we had all the necessary reports, the interface was easy to use, and we could configure our rules to turn source data into debits and credits. We wanted something that was flexible to work with and has configurability.
• Compliance: Compliance for us was more about just meeting basic requirements, we wanted SOX reports, ability to audit things like access and configurations.

Leapfin provided us with all of these capabilities and more. With their locking periods, we had the ability to apply any changes to the next reporting period as an adjustment. They’ve also provided us with on-demand reporting for SOC 1 and 2 reports and an audit trail in their user friendly interface. All in all, Leapfin has been a strategic partner who we see a long-term future with.

What advice do you have for someone who is navigating the build vs. buy decision? How would you pitch this to C-suite executives who typically think they can build a solution better?

Joe: We made our proposal to the CFO and looked at it in terms of the total cost of ownership over five years. There are a few key questions that we focused on to paint a picture of the real opportunity cost of making the decision to build like:

• How many full-time equivalent engineers is it going to take to build this?
• What’s our target timeline to launch the project? Is it tethered to other business initiatives like IPO or geographic expansion?
• What are the implementation period and ongoing maintenance costs? What are the infrastructure costs? How will they grow with our projected forecast?
• Will we need to hire more engineers to help with maintenance? Or will we use existing resources who then can’t work on any other projects?
• What’s on the product roadmap? Are we launching new integrations with payment processors or buy now, pay later?
• Will we need to hire UX designers to help with the user interface?

Bottom line, once you answer these questions, you should have a clear answer as to what solution is better for your business. For SeatGeek, the answer was pretty clearly “buy” and Leapfin was the perfect solution to cater to our marketplace revenue needs.