EPISODE 1706

[INTRO]

[0:00:00] ANNOUNCER: A common challenge for developers of SaaS products is integrating with existing services including services that customers might already be using. For example, a SaaS product might need to integrate with customers using Salesforce, HubSpot, or another CRM system. However, this can be demanding for developers when third-party APIs are poorly documented or inconsistent.

Lauren Long is a co-founder at Ampersand, which is a developer platform for SaaS integrations. She joins the show to talk about smoothing out API connectivity to make SaaS interoperable. This episode of Software Engineering Daily is hosted by Sean Falconer. Check the show notes for more information on Sean's work and where to find him.

[EPISODE]

[0:00:52] SF: Lauren, welcome to the show.

[0:00:53] LL: Thanks, Sean. Great to be here.

[0:00:55] SF: Thanks for being here. I was looking forward to this. So, like me, you are Canadian. You're also an ex-Googler. Now you're the founder and CTO of Ampersand. But this isn't your first company, right? You also started something called Boxit a number of years ago. So, I guess, was starting companies something that you always wanted to do?

[0:01:12] LL: That's a great question. It was not. So, I grew up wanting to be a doctor because my mother was a doctor when she lived in China, and had kind of always convinced me that that was a great career path. It wasn't really until second year university when I got back my midterm exam for physiology, and I think I got B- or something. It wasn't even that bad. But it was kind of a shock to me, because I was used to getting straight As. I remember this moment, in my dorm room, when I was sitting on my bed, I literally cracked open the textbook to start studying for it. After about an hour of doing that, I realized this was really silly, because it wasn't something I was passionate about. I realized that I was taking computer science as an elective course and that was really something I was way more interested in, and I easily got good grades in that course without doing much studying.

So, that's when I transferred my major to computer science, and started my journey in tech. But startups was something that was serendipitous. I applied for this accelerator program in Canada, called the Next 36 that chose 36 undergrads from across the country, and gave us funding and mentorship to start businesses. If it wasn't for that program, I don't think I would have really had the initiative at that moment in my life to start a company. But because I was able to do it in the safety of the support system, I started my first company Boxit right after university, and ran that for about a year, full time, before my co-founder and I decided to pivot a little bit and make it more into a lifestyle business that we ran part time. In fact, we're just in the middle of shutting that company down after 10 years. So, that was my first entrepreneurial journey. The second time around has been quite different. Happy to dive into that also.

[0:02:58] SF: That's great. I mean, it's nice that you had that program to kind of help you give you some foundation for what starting a company might be like, because that is a tough transition to go from university directly into - even if you worked in companies prior, there's a big difference between being I don't know, like an IC in a company as an engineer to running a company and trying to start a company. There's just a lot of things that take on. I guess, what are some of the things that you learn during that first company journey that you've essentially been able to apply at Ampersand?

[0:03:29] LL: The biggest lesson I learned was to be very careful about what you work on. So, with that first company, my co-founder and I had experimented with a bunch of ideas and this was actually the third idea we landed on. Just to give a bit of context what Boxit did was we provide a storage by the box, physical storage, non-digital storage with delivery services. So, as you can imagine, that was very logistics-heavy and also very low margins. It was an idea that we had gotten some traction on early on and that was really encouraging. We kind of didn't stop to think about whether this was a company we want to build and dove into it.

So, I think the biggest takeaway for me it was if I had taken more time, initially, I would have realized, A, it was not a space I was interested in building for years to come. And B, it was a space that was really hard to build a scalable business. This time around, I was very careful about picking something I felt like I had a unique advantage in which was developer tooling. Given my background, I had spent four and a half years on the Firebase team at Google as a tech lead there. So, building developer tooling was something that I had a lot of expertise in. And B, it was something I was really interested in. I really liked developers as a customer segment. They are very able to articulate what they want, which I appreciate and they're really supportive when they like your product. I remember at Firebase, we had developers giving us code snippets of how we would fix certain things, at the moment that they filed a bug. That kind of customer interaction was something I really like having. So, it was kind of a no-brainer this time around that developer tooling was the space I want to build in.

[0:05:10] SF: Yes. I suspect that you probably spent a lot more time like vetting various ideas and talking to people, doing like proper research before jumping into writing a single line of code. This time around versus, maybe your first experience.

[0:05:25] LL: Definitely. It actually took me about a year between quitting my last job and starting Ampersand, and that's how long I think people should give themselves when they're starting something new. Really, that's time and space to explore, to ideate, to learn, to meet people, so I'm really glad I took that time.

[0:05:42] SF: Right. So, I want to get into the weeds a bit about some of the stuff that you've been building at Ampersand. But for context, let's give maybe a brief explanation of what Ampersand is, like what problem you're solving before we dive too deep into the technical aspects.

[0:05:55] LL: Ampersand is a developer platform for SaaS integrations. So, when someone is building business software, software as a service, they have to integrate with systems that their customers are already storing their business data in. A good example of this is, let's say you're building this new sales assistant software, your customers are going to already have their data living in Salesforce or HubSpot or other CRM systems, and they're not going to buy your new product unless you work seamlessly with their existing tools. Instead of spending your engineering time building out those integrations and accommodating for the various intricacies of different systems and different customers, you can spend that time working on core product and use a platform like Ampersand to assist with that connectivity piece.

[0:06:43] SF: Essentially, am I getting one single API to rule them all amongst the various like integration points I might need to do, while building like a SaaS application?

[0:06:52] LL: That's a great question. What currently exists in the market and what you're referring to is unified API. So, it's the idea that when you make a single API call, it gets proxied to X number of APIs underneath the hood, and things get transformed into a common schema before it is given back to you. That is not the approach we're taking. We are helping people build deep and flexible integrations. So, we are more of a configuration declarative-driven approach. There is a manifest file, a YAML file where you are defining the data sources, the APIs that you are reading from or writing to, the objects and fields that you are reading and writing, as well as the configuration knobs that you're exposing to your end customers.

From that YAML file, Ampersand is orchestrating all the reads and writes and subscribes. We are providing embeddable UI components that you can put into your app for your customers to onboard and set up their integration and configure them and manage them down the road. All of that orchestration is driven by both your configuration, the manifest file, as well as your customers indicated preferences in that embeddable UI components. So, it's a bit of a different approach than what currently exists. We're not really unifying the data schema. What we're unifying is the patterns of interaction.

[0:08:14] SF: So, if I'm integrating with something like Salesforce, how would that work? Am I essentially doing - I'm still doing a direct integration with Salesforce, but there's some level of obstruction through using Ampersand. It's not like I'm - regardless of the CRM, or regardless of the customer platform that I'm integrating with, I have the same API. I'm going to have something that's like specific for Salesforce or specific for like HubSpot or something like that?

[0:08:37] LL: Yes. That's a great question. So, when you're using Ampersand, you are defining an integration for Salesforce in addition to an integration for HubSpot, or any other tool you would like to integrate with. The reason why that is, is that Salesforce and HubSpot are very different tools. People use them in pretty different ways, especially enterprise customers. They're very sophisticated. They're setting up custom objects, custom fields, and they're certain concepts that exist in Salesforce that might not exist in HubSpot and vice versa.

Instead of forcing you to make all of them look the same and treat them all the same through a unified API, or allow you to indicate if a customer comes in with Salesforce, I would like to interact with it this way, but HubSpot will be treated another way. But what we are making really easy for you is all of this lives in one file and is using the same pattern. So, for each of your integrations, you're defining the objects you're reading and writing and the exact same way. You're not having to read API docs from Salesforce or HubSpot. You don't have to figure out the different auth patterns, the different pagination patterns, different query patterns, or taking care of all of that for you. You really have to do is think about what are the integrations you want and how flexible you want to make those integrations and what are the mappings you want to enable for your customers? What are the optional fields and objects you want to enable for your customers and indicate that in this single manifest file.

[0:10:10] SF: Okay. Then, in prior experiences, I've done integrations directly to like HubSpot, or directly to Salesforce. Besides it being kind of, it can be kind of a bad experience. But there's also, you have limited like control over those integrations. It can be a little brutal. But works is works. If it goes down, it can be fairly big impact to whatever it is that you're building. So, is there something in Ampersand that helps me like solve this problem in terms of having more sort of reliability of the integration?

[0:10:45] LL: Yes. You've really uncovered a key insight, which is, most people think the work of an integration is building it. But that's really a small part of the work. Most of the work is the maintenance and the debugging, the troubleshooting, and keeping these pipelines running. That's really where Ampersand can really help. There's a few things we offer in that regard. The first is we have a management console, where you are able to have visibility over all of your integrations, all of your customers, all the sub tenants of those integrations, and have a good sense of the operations happening. You can view logs from those integrations. So, it's really good way for you to detect what's going on, and to troubleshoot if you say get a customer support ticket coming in.

That's first. First of all, we offer troubleshooting and telemetry capabilities. And the second thing we offer is we try to automatically fix a lot of the problems for you. So, a really common one that people run into is credentials that expire. With Ampersand, we are taking care of automatically refreshing credentials when they expire. We are also taking care of quota issues. So, API rate limits is something I'm sure you encountered Sean, in your past integrations. We manage that for our customers and when we hit one of those errors, we are able to know how long is the appropriate amount to wait for before retrying? Does this even makes sense to retry and able to handle all of that automatically?

[0:12:10] SF: Right. In terms of companies that are doing this kind of integration themselves, like what is the typical engineering team size that they are allocating for these kinds of integrations? Then, what is the typical, like maintenance costs involved?

[0:12:25] LL: This is a great question. So, it really depends on the company and how - it mostly depends on whether they're going upmarket in terms of their customer segment, or if they're mostly selling to SMBs. If companies are mostly selling to SMBs, they might have an easier time with integrations, because the tools that their customers are using, they're not customizing it a lot. But people that are selling to enterprise and mid-market really struggle under the load of maintenance, and we're seeing pretty large teams of half a dozen people, dozens of people sometimes that are just focused on integrations. It's also a team where there's low satisfaction and high churn. As you can imagine, it's not the most exciting thing that engineers want to be working on, so it becomes really hard to think about the staffing and the retention of those teams.

My co-founder, Ian, he previously had a company in the SaaS cost management space, and they actually had a dedicated integrations team, and it was one of his biggest struggles as a CTO of that company to figure out how to get people excited to be on that team, how to encourage people on that team to not leave. So, it really becomes quite the challenge for these bigger companies.

[0:13:38] SF: Yes. It's hard to justify putting your best people on that when it's not necessarily like a customer-facing feature that's like core to your company. So then, maybe you ended up having to try to put like junior folks on it that end up really making mistakes that lead to some of the brittleness of these integrations, which could cost you down the road. Then also, if these people don't want to stick around on these teams, there's just like a constant sort of flux of transfer knowledge and so forth. So, it can become like a pretty big cost center for a company.

[0:14:07] LL: Absolutely. It has a lot of downstream impact. So, first is customer retention. My co-founder's previous company, they had some of their largest customers churn because their integrations kept breaking, and they were getting really frustrated by that experience. You also can block some deals from closing, if you're not able to provide a certain integration in a speedy manner. Those customers won't sign. So, you're losing out both on revenue, in terms of new revenue, as well as revenue retention.

[0:14:37] SF: You mentioned earlier, one of the tripwires people can run into is around when credentials expire. How does the refresh work where you essentially have to balance potential downtime? If it expires, and even if you refresh it, there could be a moment in time where things aren't working, essentially. So, how do you engineer around that problem?

[0:14:57] LL: Yes. That's a great question. So, there's two types of refreshes that you have to handle. The first is once we can automatically do on behalf of the customer. Those are the best. There's no downtime when we do that. The second is when the customer has to re-off. This typically happens if, say, the first person that set up the integration has now left the company and that credential just doesn't work anymore. Or someone was in the admin dashboard of a particular tool and kind of revoked access by accident of one of their integrations and didn't realize how important that was.

In those cases, we do need the customer to actually do something to fix the issue, and that's where then, in those cases, there could be a like in the data that we're reading or writing. So, at a high level, we built a lot of cues within our system. This is both in terms of using - we're on GCP, so we use Google Cloud Pub/Sub in between a lot of our services. We also use a product called Temporal to orchestrate a lot of our API interactions. So, between these two types of systems, we're able to, even when things are down, and when we aren't able to make the API calls need to be in that moment, are able to keep track of them and replay them later if needed, when it makes sense.

[0:16:15] SF: So, is that where Temporal comes into play is, essentially, if the async call fails, then Temporal, essentially, hold on to that and complete it later when the API comes back up?

[0:16:26] LL: Temporal, for listeners that might not be familiar, is an orchestration engine, and we are using the Temporal cloud product. So basically, Temporal solves two primary problems for us. The first is scheduling. So, we have scheduled reads, is on the capabilities we offer, and that can be configurable. Temporal handles all of the individual schedules for us, and those can be updatable, cancelable down the road also.

The second thing that Temporal really helps with is that resilient retry. So, within the workflow code that we wrote, we are able to detect which errors are retriable, which ones are not retriable, and when they are retriable, when to retry based on the particular error message or status code we're getting. So, Temporal is handling that retry logic and error parsing logic for us also.

[0:17:21] SF: Then, Pub/Sub, you're using Pub/Sub essentially as like your queueing systems?

[0:17:26] LL: So, there are a few places that we use Pub/Sub. The first is when we first get input from the customer. One of the things we can do within the system is asynchronous bulk writes. We have customers that are writing millions of rows each night, and they're doing this big data right back into their customers other systems. For that, as soon as we get the input, we have a Pub/Sub queue, and that causes us to immediately store they're important to Google Cloud Storage, just so we don't lose the data. The first thing we do is be persisted. Then, there's a few other spots in our system where, let's say before we send a webhook message, or between different steps of processing that we also use Pub/Sub, for that queueing capability. And in order for us to make sure if any part of our system is down, we can still continue afterwards when our system is back up.

[0:18:23] SF: Then in terms of the handling, rate limiting, is that handle - are you handling that using your orchestration layer? Is that handled somewhere with your queueing system?

[0:18:33] LL: For rate limiting, we've built a pretty robust engine on top of Gubernator, which is an open-source project that Mailgun has put out. We have built a layer on top of Gubernator, which allows us to track rate limits by a couple of dimensions. So, the first is by the SaaS API. That's the most obvious thing we need to differentiate by. We also do it by module. Sometimes there's different limits depending on if you're using Module A or Module B. If the product, sometimes by different endpoints, those will have different quotas also. We also track it by what we call connection ID, which is the particular credential that we have for a SaaS provider. That usually matches a Salesforce instance or a HubSpot workspace, and using those labels together, we're able to track at a very granular level what the existing usage is of those APIs, and when we need to start slowing down our calls, and we're also able to track when we get throttled. So, when we get back a quota exceeded error, we have this reactive flow where we then are able to look at what is the appropriate amount of time we should wait for before we retry again.

[0:19:52] SF: How do you keep track of all these nuances of the specific API? Are you storing - do you have basically a metadata storage system that gives you this specification of the rate limits, the page sizes, like all the kind of like intricacies of the API so that you can properly manage that stuff?

[0:20:11] LL: Yes. You got it. So, we are storing things in a lot of different places. At the high level, we read the API documentation and turn some of that knowledge into metadata storage. We also do a lot of overrides that are individual to the customer or individual to the instance and that's because, for a lot of products, customers can actually request for exemptions for quotas. So, say you're an enterprise customer of a particular product, you can write into customer support, and say, "Hey, I would like to increase my quota." When we know about a particular customer that's done that, we have to do an override for them. So, there's many layers of overrides and many tables where we're piecing that information together to understand what is the actual limit.

[0:20:55] SF: Yes. It's almost like you have in the world of like object-oriented programming, you have like an abstract class that represents the default of these things and then you can write a subclass for specific customer that override some of those fields.

[0:21:08] LL: That's a great analogy. Yes, absolutely.

[0:21:11] SF: In terms of storage, in the case where you're doing these batch writes, I believe your explanation there was it goes through Pub/Sub, and then you're going to write that into cloud storage medium on GCP, so that you don't lose that while you're doing the batch writes, depending on what the timing for those things are. What is that storage system? What are the back-end storage systems that you're using within GCP?

[0:21:33] LL: So, for our database, we're using Postgres and for blob storage, we're using Google Cloud Storage. Pretty standard tooling. We want to use technology that folks are familiar with, that were resilient.

[0:21:45] SF: Postgres, is that a managed service under GCP?

[0:21:50] LL: Yes. We're using Cloud SQL, so they're a managed version of Postgres.

[0:21:54] SF: Okay. In terms of Ampersand itself, how does like deployment model work? You're also SaaS, if someone's building SaaS, using your SaaS essentially, your SaaS offering. Is this running like essentially, like a multi-tenant model within your Cloud account?

[0:22:09] LL: You mean our prod GCP account?

[0:22:12] SF: Yes. How does, as a customer of Ampersand, is where does the Ampersand offering live? Is that living within my cloud environment? Or is that living within your cloud environment? Or maybe there's both? Essentially, how does deployment work?

[0:22:25] LL: Got it. Okay. That's a good question. So, at the moment, we are a cloud offering. Everything does live within our GCP account, and that's where all the resources happen. That's where all of the workflow runs. Down the road, we will like to offer a private cloud offering also of our product where you can deploy Ampersand on your own infrastructure, and we haven't yet built that piece, but it's definitely something that we have our eye on.

[0:22:52] SF: Got it. Okay. In terms of the APIs that you're integrating with, I imagine you've encountered a fair amount of like API weirdness. There's REST APIs or SOAP APIs, there's GRPC, there's other sort of bespoke things that people do. What are some of the strange things that you've run into?

[0:23:12] LL: Yes. If I had a son for every weird API quirk I run into, I'd be rich by now. I think this job has definitely taught me that APIs are very interesting and there's a lot of non-standard things out there. So, one provider we've worked with, I won't list names, they have a search endpoint where you are limited to 10,000 records per query. But there's almost no indication that this is the case. You almost have to discover it by experience. So, if you are issuing a search query that might have returned more than 10,000 records, you'll have to have some clever way of chunking your query.

The thing that we do on our side is when we get 10,000 records back, we know there's likely more than 10,000 results. Then we break it up by update time. So, we'll reissue additional queries until we get less than 10,000 back per call. That's when we think, we've encountered API endpoints that takes CSV as input, but returns JSON or vice versa. We've encountered SOAP APIs, as you mentioned. We've encountered a lot of APIs that return a 200 okay, no matter what. Even when there's an error, it's still 200 okay, and you have to actually parse the body of the message to understand an error has happened.

[0:24:29] SF: Is there circumstances, like I know Salesforce used to be like a SOAP API, and then I think now, it's been modernized. But I wouldn't be surprised if they support both for backwards compatibility. So, is that a situation that you have to deal with where you might actually have to support multiple formats and essentially different versions of APIs?

[0:24:48] LL: Yes, that's definitely the case. So, Salesforce is a good example. They have their REST API, their SOAP API, as well as a GraphQL API, and those have different capabilities. There are some overlap where for a particular use case, you can choose one of the APIs, but there's a lot of capabilities that only exist in, say, the SOAP API. One of the things we do with Salesforce is we can actually - we're starting to create objects and fields programmatically. So, this is helpful for integrations that needs to create a special custom object for their data. So, they're not messing with their customers, that other CRM data. Right now, to do this within the Salesforce ecosystem, you have to use their SOAP API. We have this very complex XML parser that we built within our system to handle that.

[0:25:39] SF: What about Off? How does auth work both with Ampersand and across all these different systems?

[0:25:46] LL: That's been my other learning is how different auth is across the board. I used to think that most modern APIs would implement OAuth and that is definitely not the case. So, in addition to OAuth, a lot of APIs still have API key-based auth. So, if you're trying to do user-facing integrations, you actually have to instruct your customer to go into their settings page of the other API provider, generate an API key, copy and paste it back into your platforms. That's very common. There's a few providers that still use basic auth. So, basic auth is basically you are just taking the username password and putting - and Base64 encoding it and then passing it in with your API request.

Within OAuth, there's a couple of different flavors. There are people that are still using OAuth 1.0. So, the legacy-based, the legacy OAuth flow. In OAuth 2, there's different ways of doing this. There's authorization code grant, and that's the three-legged flow that's the most common. There's client credential, that's a two-legged flow. There is password grant OAuth, where you're passing in plain text username and password along with your token. There's OAuth with PKCE, spelled P-K-C-E, which is OAuth plus a code challenge, and there's OAuth endpoints that use non-standard headers that don't actually follow the spec to the tee. There's OAuth endpoints that return an access token, but there's no refresh tokens. So, definitely lots of sub-flavors of OAuth that we've encountered as well.

[0:27:16] SF: Yes. This just kind of goes back to some of the things we were talking about earlier, where this is kind of like, not necessarily the sexiest project for people in a company to work on, having to deal with all these weirdnesses across APIs and auth systems and stuff like that. There's a tremendous amount of value to kind of offloading that to somebody who I'm assuming your engineers are excited by taking on these challenges and excited to work on that kind of stuff.

[0:27:40] LL: Yes. Absolutely. I think it's been really fun actually, to think about the right level of abstraction to offer to our users, and to think about how to build our system in a flexible manner, where we are almost expecting the unexpected. So, I think early on, we learned to not make any assumptions about standardization across APIs, and to just build in a way where we can plan for any of these weird flavors of stuff to happen. So, that's been a fun engineering challenge.

[0:28:11] SF: How does something like asynchronous APIs that start long-running jobs work? There's APIs where you hit an endpoint and the expectation is it returns a result right away. Then there's other API endpoints that essentially kick off a job, and then you need to get like status updates, or they ping you back through a webhook or something like that?

[0:28:31] LL: Yes. That's another value, I think, that Ampersand offers, is being able to deal with the different types of APIs and their interaction patterns. So, we definitely do encounter a lot of asynchronous API, and that's one of the other things we use Temporal for, is once we kick off the job, we have a Temporal workflow that pulls on that job at an interval and then tells us when that is done. Then we can reflect that back to our customers.

We also have a synchronous, in addition to asynchronous way of interacting with our system. So, that is to accommodate the different types of use cases that our customers have. Some of them will want more real-time reads and writes, and this is typically when someone's building SaaS, that is more collaborative workflows, or a better UX layer on top of existing tools. They want the real-time updates. There's a different breed of SaaS, which is more about enriching data, offering insights, offering analytics, and those are more asynchronous because they're dealing with larger data volumes, but they don't need to be as fresh. So, there's different ways of using Ampersand to accommodate both of those.

[0:29:40] SF: Then, can I use Ampersand to standardize how I get some of those responses? So, if there's some that essentially require pulling an endpoint versus hitting back like a webhook, can I, regardless of what the API supports natively, can standardize that to one or the other?

[0:29:58] LL: You got it, yes. That's what I was referring to earlier when I mentioned that while we don't standardize data schemas, we standardize the patterns of interaction. The value of using Ampersand is you can essentially treat all APIs the same way. All you have to do is to think about what is the data you need? What is the flexibility you need? Then you're calling them all the same way. You're dealing with them all the same way.

[0:30:23] SF: How does the security work? Because as a customer, I'm trusting you with my API keys, which is kind of like the keys of the kingdom. Then additionally, I'm trusting at least some pass-through or temporary hold of potentially customer data that's going to pass through to like a CRM or pass back out of the CRM.

[0:30:43] LL: That's a great question. So, table stakes, we have soft two, type two compliance. We definitely do try to follow the most secure standards in terms of our infrastructure setup, our processes. The other thing by design is we don't hold on to your customer data. While we do hold on to credentials, because we need those to make API calls, we don't actually hold on to the data that we read from your customer systems. This is another area where we're different from unified APIs.

For unified APIs, they are keeping a cache of your customer data. And when you issue additional API requests, it's basically querying that cache and they'll update that cache at a certain interval. We are more of a transport layer where we pass through the data to you, and you, essentially, if you wanted to, you can build your own cache off of that, that you query against, or you can make a call to us and we'll propagate that call to the downstream API again. So, in that way, we are only holding on to your customer data for a limited amount of time. Otherwise, just passing it through to you. That is another area where some customers prefer us over the model where the other providers keeping all of the data.

[0:32:00] SF: Yes. I guess, under sort of GDPR terms, you're a data processor rather than data controller, because you're not actually holding on the interface. It's basically a pass-through.

[0:32:09] LL: Exactly.

[0:32:10] SF: You mentioned earlier and I also saw in preparing for this that you offer a UI layer library as part of Ampersand. As a customer, what am I doing with the UI library?

[0:32:23] LL: So, the UI library takes care of two things. The first is just getting credentials. Getting your username and password. If you're doing auth flow, or if it's an API key-based flow, getting the API keys. So, that's the most important job it does. The second thing is it gives your customers control over what is being processed in that integration. So, you can within the YAML file, enumerate what are the required things that your integration must read and write, and what are the optional things. And what are the things where your customers can map custom objects and custom fields to concepts within your application.

That level of control and flexibility gives your customer confidence in knowing what kind of data you're getting, and offers them the ability to tell you if they've set up their system in a particular way. What it means, field A actually means this thing, and they're able to do that mapping within our UI library. So, it's really customer configurability is the second big job that it does.

[0:33:24] SF: I see. Okay. You guys are still fairly early in your journey as a customer. What are some of the problems that you end up running into as you started to onboard your first customers?

[0:33:36] LL: So luckily, none of the problem we ran into were due to scalability or business logic. I think we got a lot of our architecture and design right. We did run into some pretty obscure bugs and the different systems were using. We have a proxy endpoint where if you don't want to use this to orchestrate, you can do pass-through API calls through us and we're attaching the right tokens and taking care of the token management for you.

For that particular service, we ran into a very obscure bug within Go's HTTP library that we had to debug, and it took a while for us to figure out and we eventually were able to fix it. So, it was mostly just weird bugs that only showed up when a certain number of conditions all had to be true, and that we started seeing once we got live traffic.

[0:34:24] SF: Is the back end written in Go?

[0:34:26] LL: Yes. As an ex-Google engineer, I am biased. So yes, it is written in Go.

[0:34:30] SF: A lot of proto files floating around, I'm assuming?

[0:34:33] LL: Yes.

[0:34:35] SF: Then, with the nature of what you're doing, you end up being kind of responsible, or to blame of someone doing an integration where the API that you're orchestrating to, has some kind of undocumented features or something like that. The theme that you were mentioning around earlier where the only way to discover that there was a limit of 10,000 records was essentially by hitting that limit through an application and then sort of building around it. So, how do you think through preemptively understanding where those undocumented features might exist, so that you can engineer around them without it being a pain point that your customer essentially discovers?

[0:35:15] LL: Yes. That is definitely something we do a lot of work on. One thing we like to do with every prospect customer is if they've already built an integration with an existing tool, we asked them all about it. So, we're really doing this intelligence-gathering process, even if they aren't looking to migrate that particular integration to Ampersand, we still want to learn all about it, because there's a lot of value in their experience and what they're discovering. So, a lot of our insights actually just come through conversations, and new customers that onboard onto Ampersand, are able to rely on us. It's almost their integration consultants, so to speak, because we're able to tell them about what other companies have experienced, what other issues that they might likely encounter down the road. That's the first thing we try to do, is we try to uncover a lot of those through conversations.

The second thing we try to do is we try to build really robust monitoring on our side, so that as soon as we hit one of these issues, we're able to troubleshoot it really quickly, and put in a fix really quickly so that other customers are not affected.

[0:36:17] SF: Then, as you've been building the technology, what's one of the hardest technical challenges that you and your team has had to solve?

[0:36:27] LL: So, the hardest challenge, I think, is definitely thinking through our abstractions and thinking through the data schema, and making sure that what we're building is really flexible and can accommodate for a variety of use cases. I think one of the interesting things about integrations is we have to understand our customers' businesses really, really well and understand what are their customer profiles like? What are their customers doing? How are they using the tools? There's just such a wide spectrum between what people want and the level of flexibility, and level of configuration that different end customers want. Just planning for that flexibility, I think has been a really interesting architecture challenge for us and that's one thing that I think we continue to make investments in and improve on.

[0:37:17] SF: As we start to wrap up, what's next for you? And is there anything else you'd like to share?

[0:37:23] LL: We definitely want to expand our integration coverage. So, we're right now focused on the go-to-market space. Our goal is that any company that's building in that space, so they're building a product that's selling to sales teams, or marketing teams, or revenue teams, are able to use Ampersand for all their integration needs. Expanding coverage deeply in that space is top of mind for us.

The second thing we're working on is enabling real-time event subscriptions for tools that don't yet have webhook support. So, an example is Salesforce, there's no webhooks support. If you want to get real-time updates for Salesforce, there's a lot of hoops you have to jump through. You most likely need to build a managed package using a proprietary language that they have called Apex. You have to then distribute it through the Salesforce marketplace. We are building a mechanism where you can do that without doing any of that work and just use Ampersand to deliver these real-time event subscriptions to you.

[0:38:21] SF: Yes, so essentially, you can start to build new functionality that these existing APIs don't necessarily support natively based on like the requirements of the customer?

[0:38:33] LL: Yes. You got it. We really want to - our big vision here is to really unlock use cases that weren't even possible before Ampersand existed.

[0:38:42] SF: Yes. It's not just the value-add sort of standardizing the patterns. But there's also value-add in terms of just like unlocking new use cases, like you said, being able to do something that you weren't able to do before, or at least not able to do in like a reasonable way.

[0:38:56] LL: Yes. That's right.

[0:38:58] SF: Lauren, awesome. Well, thanks so much for being here. I really enjoyed this. Best of luck with your journey. It's early days. You got a long road ahead, but I'm sure it's going to be a ton of fun.

[0:39:07] LL: Thanks, Sean. This is really fun. Thanks for having me.

[END]