Building a subscription billing system for scale
Former Dropbox finance and engineering leaders look back on taking a custom billing system from Series B to IPO
High-growth software companies face many challenges as they scale. So it can be easy to overlook some of the most foundational problems before they start costing your business time and money.
My former Dropbox colleague Scott Woody and I both know from experience that your billing system is one of those core foundational problems to get right early. Both Woody, former Director of Engineering at Dropbox and now Co-founder and CTO at Metronome, and I went on to help build new companies focused on improving the finance stack.
In a recent conversation at the Ascent conference in San Francisco, Woody and I looked back on our time at Dropbox and shared lessons learned—from taking billing more seriously to building a better relationship between finance and engineering.
Scott Woody: You joined Dropbox in 2011, when the company had just raised a Series B. As one of the first finance hires, what was the lay of the land?
Brad Silicani: I remember very vividly on my first day, my boss said, okay, we need to go get our initial financial statement audit done. Why don't you go talk to the engineering team and figure out revenue first? So, of course I said, great, I know how to do this. My background was at EY before that, and I was well equipped for that job.
I walked over to one of the engineers and said, can you give me the report on our billings for the past three years? And I remember just getting this absolute blank stare. And having the feeling that I was bothering this person, and also that they had no idea what information to share with me.
At the time Dropbox had both a homegrown billing system to support the website, and was also starting to do some enterprise sales motions, primarily using Salesforce.
What I quickly learned is that no one had thought about what we needed to do from a finance perspective, which was fairly normal. But the information actually wasn’t even there for us to be able to figure out quickly what had happened.
And the primary reason for that is the homegrown billing system was architected to be a real-time database. So it always captured the latest thing that was happening for the customer, which was super important obviously for product and engineering. But on the finance side of things, we needed to know what had happened in the past.
We also quickly learned that the company had done nothing on the sales tax and VAT side things. By the time we got to solving that problem it cost Dropbox over $10 million in back taxes—money that we could have been using in other places in the business.
So it was a rocky start on day one, trying to figure those things out. And it took us about 18 months before we were in a position to get the database in the right place, as well as be prepared to move forward on solving some of those blocking and tackling issues on the finance side.
SW: As the finance team, what was your vision for what the billing stack was supposed to look like and how did you go about getting that built by the engineering team?
BS: I think our vision of the billing stack came from pattern-matching against what we had seen from our prior experiences and the other systems we saw out there.
Directionally, we knew we had to tackle a number of foundational projects to make sure we were compliant from an audit perspective, and from a tax perspective, to really set ourselves up to be able to help grow the company.
So for us that was a very clear vision—these solutions already exist, can you just build that for us? But that definitely wasn't a message that landed well with the engineering team. It was a challenging relationship for sure.
BS: When you joined in 2013, what did things look like from your perspective? How was the relationship between engineering and finance?
SW: I worked as an engineer who was internally facing, building a number of internal tools. And the thing I would say about that company stage—this was a Series B company growing very quickly—is what you saw on the engineering team was this desire to focus on whatever the most impactful thing was, which at the time was to grow the user base.
And so you would get this really interesting dynamic between finance and engineering, where finance would ask for something and engineering was hard to wrangle and try to convince that this could be the most important thing for the business.
And so what we saw on the engineering side is that things related to billing, tax, accuracy, compliance, or auditing got serially pushed to the bottom of the queue. I used to joke that our billing system was an intern project, because what would happen is every year you'd have these big grand plans for what would happen on the finance and the engineering relationship, and then nothing would happen.
And then summer would roll around and a bunch of interns would show up and get put on it. I remember that even just supporting annual billing was an intern project that instantly minted like $10 million. But the only person who was willing to work on it was an intern.
I think it was kind of emblematic of this interesting tension for a fast-growing company, where engineers want to work on whatever the most interesting problem is, and it's rare at that stage that people are able to convince them that it could be finance.
Over time that changed. But definitely in those days it was like pulling teeth. You had to basically become good friends with an engineer and then bribe them into working on your project.
BS: Do you have tips on what finance teams, particularly in those early stages, can do differently in terms of engaging with engineering?
SW: The first thing is understanding how engineers’ brains work. Engineers are attracted to problem solving. And so if you come to them and say build this, it's almost going to have the exact opposite effect.
Whereas if you say, here's this problem, I have no idea how to solve it, it opens it up to them to be a creative problem-solving exercise. That’s really important framing.
The second thing that I think engineers really, really care about is impact to the business.
And so if you say, we need to do tax because of money reasons, engineers may or may not be motivated by that. The way you need to do it is say, if we do this, it enables the company to do that. It's critical for us to properly bill our customers so that X, Y, Z can happen.
I find that the right engineers are heavily motivated by impact, and you have to message-test against what an engineer cares about. At the end of the day, they're super autonomous, very creative people, and people who ultimately just want what is best for the company, especially at that stage.
So you need to convince them that your project is on par with scaling up the company or whatever. Ultimately the good thing about billing and finance is that these are really hard technical problems at the end of the day.
BS: As we continued to grow, on the finance side we were really pushing on using external tools, but the ultimate decision from Dropbox was to continue building an internal billing system. I'm curious how that build-versus-buy tension felt from the engineering side?
SW: Finance is an interesting thing. You mentioned that there's a lot of prior art in the world about the right way to do billing or revenue recognition. At Dropbox we were very in favor of building, not buying, and I think that’s partially a consequence of the timing. In 2013, 2015, there really weren't great solutions available, and the enterprise landscape for software businesses was not very mature.
But in retrospect, the way we approached the build was taking whatever problem we had in 2015 and solving for that moment, but not fully anticipating how things would change in the future.
A great example is when we started internationalizing. Our initial pricing on the website was $9.99. But on the backend in the database, it was literally coded as 9.99 without a currency attached to it. So when we wanted to launch in Japan, we would be charging 9.99 yen. But yen isn't even a fractional currency—so it just wouldn’t work.
It was a situation where engineering, in their infinite wisdom, built a system that worked really well for this point in time, but didn't anticipate the future. And that led to this herky-jerky evolution of the product, and it caused a ton of pain.
I would say part of it was that tool availability wasn't there. Part of it was the maturity of the business—like, we never hired billing subject matter experts until we were pretty close to IPO. And then part of it was, I think, a natural consequence of growing really fast.
SW: Did you feel the relationship between finance and engineering start to change as we approached IPO?
BS: Definitely, around that same time you’re discussing. I think it was about 2014, which ended up being four years before Dropbox went public, when we started thinking about preparation on the finance side.
We knew that to be successful in becoming a public company, we needed to have a good controlled environment to make sure that we could successfully pass an audit in year two after the IPO. And we knew that we needed to have a lot of confidence in the forecast. We needed to know that we had reliable reporting, not only on revenue, but on the key metrics that would drive revenue—to allow us to have confidence in setting really aggressive forecasts, knowing what the levers were to achieve those goals.
And I think that was the starting point of an evolution of the relationship with engineering where we started to get some traction on moving the ball forward on some key projects.
BS: What did that look like from your side?
SW: It was clear in 2015 that we needed to take this stuff more seriously. Beyond the finance perspective, I also came at it from the growth side where I was in charge of monetization for new product lines.
And whenever we wanted to test out new pricing or something like that, we’d have to file a ticket with the engineering team responsible for the billing system. Four months later an A/B test would go live and we'd realize we completely screwed it up, and then we'd have to wait another four months for that billing system to get updated.
So that super slow cycle time of pricing experimentation put more pressure on the billing team. At the same time that we were trying to build better data systems for finance, we were also trying to make it easier to change pricing and do experimentation. And the combination of those two reached a breaking point around 2016.
The engineering team realized, we need to reset everything that we're doing and they surged staff on that team. It went from 3 or 4 people to 45 in a couple months. And if you know anything about engineering, you know you can't actually solve the problem that way—you can’t just throw more engineers at the problem. And sometimes it makes the problem worse in the short term.
I remember some of the engineers on the team were some of the best engineers at Dropbox. And they spent years trying to make progress, unwinding a bunch of decisions that were made in 2009, and it was very painful for the business. It definitely slowed down the IPO process and I think it explains why engineering essentially had no time for finance. They were too busy trying to keep the system up and kind of rewrite it from scratch.
BS: Did that change after we got through the intensity of the IPO?
SW: Over time, Dropbox started to realize, well, we don't need to build everything. We can start to offload more and more of this stuff to third-party services.
They also hired sufficiently senior engineers who could say, here's the subset of things that Dropbox is going to own, like the user experience. And then there's certain parts of it that we're just never going to do, like payment processing. They started to have a more mature outlook, I would say, that we don't need to build every single last thing in this stack. And we can actually outsource large parts of this infrastructure to third parties.
And that's a long journey. It's taken them 10-plus years. They're still in the midst of it today. But that was one of the big maturations of the business.
SW: How did things change on the finance side as Dropbox went public? What were the things that changed about your relationship with engineering and product and the rest of the organization?
BS: We definitely got more leverage on the engineering organization. Prior to the IPO process, the financial organization was like a support organization for the business—we make sure that the billing’s okay, the revenue forecast is there.
As you switch to being a public company, you almost move towards the forefront—now we're starting to call the shots. Now we're saying, if we want to get to $2 billion in revenue, here are the gaps. And here are the things that we need from engineering to be able to make that happen.
So in terms of prioritization things worked more effectively. But as you described, there was still a lot of technical debt to work off. The impact of that on the finance side of things was that we had to pull back a little bit in terms of how we could go to market and talk to investors about the results that we could achieve.
I remember very vividly one of those limitations being pricing and packaging related, where we wanted to start launching new SKUs that we could bundle together, but there was a clear limitation in the billing system.
BS: If you were to do it again, what would you do differently?
SW: If you're on the engineering side, the key thing is figuring out which parts of the billing and finance stack you really want to own. And then try to make it work with external tooling wherever you can.
In the beginning, all finance and billing problems can look really simple, but as your business grows, they complexify very quickly. And so it can be very attractive to solve it in-house, but I think it’s a more measured approach to solve some uniquely valuable things in-house, and outsource others to third parties.
You want to put your engineering resources on the subset of things that will uniquely drive extra value to you and your customers. ⊞