Acquiring a startup: what to do AFTER the deal closes - with Dan Moore from FusionAuth
FusionAuth bundled the authorization company it acquired into its enterprise tier only — treating fine-grained authorization like SCIM or Kubernetes support: a feature some customers need badly and most don't need at all.
In November last year, FusionAuth — which sells authentication software — acquired Permify, a five-person startup out of Turkey building fine-grained authorization based on Google's Zanzibar model. Dan Moore, back on the show for a second time, was handed the job of turning that purchase into an actual product integration, with no prior experience doing anything like it.
We go through the document he put together on what that job actually involved: deciding on messaging for multiple audiences before the deal even closed, figuring out pricing and packaging, setting a realistic migration timeline for customers on Permify's own cloud, and keeping a newly-acquired product front of mind for sales and support teams who have their own jobs to do.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What was this acquisition, and how did you end up being the person responsible for making it work?
FusionAuth sells authentication software — it's an identity provider that lets you add authentication to your application. Permify, the company we acquired, sold authorization software: it's based on Google's Zanzibar and lets you build more complicated authorization structures, the canonical example being something like Google Drive permissions. We'd heard customer demand around fine-grained authorization, and this opportunity came across our plate to accelerate our roadmap. I was basically told, 'Hey Dan, the purchase happened, now it's your job to help integrate this into FusionAuth's offerings,' and I said yes. This was the first time I'd ever done anything like that, and I've learned a lot about what that simple yes actually means.
What's the first thing you actually have to do, once the deal is happening?
A couple of days to a week or two before the closing date, we started thinking about messaging — for all the different communities involved: Permify's users and customers, FusionAuth's community, press, and internal teams on both sides. You need to decide things beforehand, because the last thing you want to do is communicate something that turns out not to be true. Is the product going to keep getting invested in? Are there major changes coming, like a re-licensing? What do existing users need to do to keep the service running? For us, Permify being open-source was something we were very cognizant of — we wanted to be clear that it would always remain open-source, even though FusionAuth itself isn't. That wasn't something I could decide unilaterally; it was an executive-level decision.
How did you land on pricing and packaging for the acquired product?
We knew what Permify was charging, had a sense of their market uptake, and could get a rough sense of competitor pricing by asking around, since we'd had partnerships and introduced customers to some of them. After talking to a number of customers — people using Permify, and people who'd passed on FusionAuth but mentioned needing fine-grained authorization — I concluded it's a feature very much like SCIM or our Kubernetes support: lots of people want it, but only a certain type of customer needs it. That meant we could bundle it with the enterprise offering. We also decided to charge for hosting, since Permify lets you deploy into your own infrastructure, and a lot of customers with mature DevOps teams would rather run it themselves and just want a support contract.
Having gone through this, how would you think about the build-versus-buy decision for something like this?
The things I think about are: was this something the customers and market were demanding — and not just the customers who talk to you, since some people won't even bring it up if they see you don't have something they need. Are competitors offering it, and how often do customers bring that up? Then you swag it: how long would it take to build? You can't estimate that with precision, but you can say weeks, months, or years — and building a highly performant Google Zanzibar-style authorization server is not a trivial undertaking. We estimated the time it would have taken us was worth more than the dollars we spent acquiring it. There's also the risk you build it badly because it's new to you, versus a team that's been out in the wild, hit the edge cases, and scaled it already — which, funnily enough, is the same pitch we make to customers buying FusionAuth instead of building auth themselves. And there's a cultural fit consideration too.
How do you think about the timeline for migrating customers off the acquired product's own cloud?
It depends on what it's costing you to keep running things, and on the customer's desires — if we'd had customers who wanted to stay on Permify's cloud forever, we might have found a way. But shutting it down cuts out a whole bunch of ongoing work: you don't have to document it, support it, or make changes to it. You want to put control in the customers' hands rather than force it, so it fits into their roadmap as planned work rather than unplanned work. A year felt like the right timeframe for this integration. It also depends on whether there's a drop-in replacement — if AWS said RDS was going away, that's painful but you can stand up Postgres; if DynamoDB were going away, there's no ready replacement. For us, the replacement is that you can run Permify yourself, which makes the transition easier than it would be for a tool with no self-hosted option.
What's the difference between the initial announcement and what you're calling 'cross-marketing'?
Initial communication is 'here's what's happening, here are our plans.' Cross-marketing is later, once you've actually done big chunks of the integration and the sales team has a story, support knows how to support the new software, solution engineering can talk about it technically, and marketing knows how to talk about it too. We had one of the Permify team members come over to the US and do training across four or five departments, in person and on Zoom, to help FusionAuth feel more comfortable talking about how Permify helps our customers. Only once that education has happened can you go do a webinar, blog posts, and email campaigns.
What were the biggest challenges in making this a successful integration?
Three things. First, early-stage ambiguity — a lot of decisions had to be made with less-than-perfect information, from pricing and packaging to how tightly integrated to make things out of the gate. Second, accounting and branding complexity: keeping track of every account and access point, and being cautious about brand integration in a way that keeps the open-source community happy while still making clear we're open for business commercially. Third, and this one surprised me: after the initial splash, internally and externally, people go back to doing their actual jobs — which aren't necessarily to integrate Permify. So we've had to keep it front of mind: a Permify slide at every all-hands, training, and enablement materials that tell salespeople specifically when it's appropriate to bring it up in a conversation.
Does that ambiguity make things harder for the sales team specifically?
You always want salespeople talking about what your product can offer, but you don't want them doing it in a way that gets egg on their face. So you almost want to wait to equip them to talk about it until pricing and packaging, and the integration, are figured out enough that the ambiguity has mostly dissipated. It's actually easier, and better for sales, to tell them 'mention this when customers are asking for it anyway' and hand them a one-sheeter that answers the question, rather than asking them to proactively push something that isn't fully baked yet.
Has this made you want to do a lot more M&A?
Ask me in a year. My guess is every M&A is like every marriage — they're all really different, and I was in a particular place at a particular time to be the right person for this one. This is an N of 1 for me. But I do think it's been a tremendous growth opportunity, because there isn't a department inside FusionAuth I haven't had to interact with in some way — figuring out how to frame this integration for support is a totally different set of questions than for engineering or finance.