Sequin with Anthony Accomazzo and Eric Goldman

Episode Description

Sequin's founders explain how their tool syncs third-party API data like Stripe and Airtable directly into your Postgres database for SQL access.

Episode Summary

Christopher Burns and Anthony Campolo interview Anthony Accomazzo and Eric Goldman, co-founders of Sequin, a developer tool that syncs data from third-party APIs like Stripe, Airtable, Twilio, and Shopify directly into a user's production Postgres database. The conversation opens with the founders' coding backgrounds before moving into Sequin's core value proposition: replacing repetitive HTTP API calls with familiar SQL queries or ORMs like Prisma. Chris shares his firsthand experience using Sequin with Prisma and Redwood, noting how it unlocked new ways to traverse relational data that were cumbersome through Stripe's REST API alone. The discussion covers Sequin's architecture—Elixir Phoenix backend, React frontend—and key technical details like the "wait endpoint" that resolves race conditions in read-after-write scenarios. Eric explains why Airtable holds a special place in the company's history, having been the first integration and the source of early community traction. Looking ahead, the founders preview an upcoming events system that would act as durable webhooks, generating event streams even for APIs like Airtable that lack native webhook support. They also discuss plans for a returning free tier, local development workflows, and their small but growing team funded by a pre-seed round from Craft Ventures.

Chapters

00:00:00 - Introductions and Learning to Code

The episode opens with Christopher Burns welcoming Anthony Accomazzo and Eric Goldman from Sequin. After a lighthearted exchange about pronouncing Anthony's last name, Chris sets the stage by noting he's already familiar with the product while co-host Anthony Campolo will be approaching it fresh.

The conversation shifts into the founders' coding origins. Anthony Accomazzo describes growing up building computers and installing Linux for fun before studying electrical engineering, only picking up Ruby on Rails after graduation. Eric Goldman shares his path from economics and product management into JavaScript and React during the pandemic, mentored by Anthony. The hosts and guests bond over the quirks of learning React as a first framework and the blurry lines between browser and Node runtimes.

00:05:16 - What Sequin Is and How It Compares

Anthony Campolo prompts a high-level explanation of Sequin, and Accomazzo delivers the core pitch: developers connect services like Stripe, Shopify, or Twilio, and Sequin syncs all that API data into their production Postgres database in real time. Instead of dealing with HTTP authentication, pagination, and filtering, developers simply query with SQL or an ORM.

The group draws comparisons between Sequin and StepZen, noting that while both normalize third-party data access, they operate at different layers—Sequin at the database level and StepZen as an API gateway. Accomazzo argues that SQL is a lingua franca far more expressive than any REST endpoint, since APIs can't anticipate every query pattern a developer might need. Chris reinforces this by describing how both tools address the same pain point through fundamentally different methods, giving developers meaningful choice.

00:09:47 - Real-World Usage and the Power of SQL

Christopher shares his hands-on experience combining Sequin with Prisma and Redwood, explaining how having Stripe data locally in Postgres allowed him to waterfall through relational data via GraphQL in ways that were tedious or impossible through Stripe's API alone. Finding core data points became dramatically easier without the repeated pull-and-pull-again pattern of REST calls.

Accomazzo responds by breaking down from first principles why APIs exist—access control and abstraction—and how Sequin can replicate those guarantees with a database layer instead. He explains that REST endpoints are inherently limited because API designers must predict common query patterns, whereas SQL lets developers query in any direction. He also lists Sequin's current production integrations: Stripe, Airtable, Twilio, and Close, with Shopify in closed alpha.

00:12:04 - The Airtable Story and Pricing

Eric Goldman explains Airtable's special role in Sequin's history as the first platform they integrated. He describes Airtable as a relational database with a spreadsheet interface, popular across companies for organizing workflows. The founders built Sequin initially to solve their own pain with Airtable's five-queries-per-second rate limit while working on a charity project, and the Airtable community quickly embraced the product.

The discussion moves to why Airtable has separate pricing on Sequin's site. Goldman explains that Airtable and Stripe differ dramatically in data volume and architecture—Stripe supports millions of rows with event-based APIs, while Airtable caps at 100,000 records and requires polling. Anthony Campolo also raises the topic of Sequin lacking a free tier, and Accomazzo acknowledges it's a temporary state, explaining that a new free tier with incremental adoption options is coming soon.

00:15:56 - Syncing, the Wait Endpoint, and Data Flow

Eric describes how syncing data to Postgres gives developers a powerful primitive with instant accessibility, changing how quickly teams can adopt platforms like Stripe. Instead of slowly building API integrations, developers can rapidly move from processing a payment to displaying invoices, receipts, and refunds. He highlights downstream benefits like easier business intelligence, internal tooling, and analytics.

Accomazzo then walks through the "read-after-write" race condition and Sequin's solution: a wait endpoint that ensures the database is fully synced before returning. This enables a clean workflow where developers write to Stripe, call the wait endpoint, then confidently read from their local database. The conversation also covers why Sequin focuses on one-way sync from API to database, since reading and writing involve fundamentally different challenges like validation versus pagination.

00:22:38 - Edge Cases, Events System, and Webhooks

Chris raises the question of transactional or search-based APIs where storing all data locally doesn't make sense, like address lookup services. Accomazzo acknowledges these would likely remain as remote procedure calls, as Sequin's model fits best with APIs whose data benefits from persistent local storage.

The conversation then turns to Sequin's most anticipated upcoming feature: a durable events system built on Postgres triggers. This would track all changes across synced APIs and trigger callback functions in the developer's codebase, effectively replacing traditional webhooks—even for platforms like Airtable that don't offer them natively. The hosts draw parallels to tools like Coral and discuss how webhook implementation on the client side remains ripe for innovation, with Sequin's approach of pairing a database, events table, and client libraries promising to close a compelling loop.

00:30:23 - Feedback Culture, Team, and Closing

Chris advocates for giving honest product feedback rather than silently abandoning tools, noting that developers who voice their needs often get features built for them. The conversation shifts to Sequin's team: just three people, including Kiki, a remarkably talented developer from São Paulo who learned to code at 12 without internet access and is about to graduate high school.

The founders share that Sequin raised a pre-seed round from David Sacks at Craft Ventures and is actively hiring. Eric encourages listeners to sign up for the free trial at Sequin's website and reach out directly to the founders. Chris closes by expressing genuine excitement about Sequin's unique approach, calling it a brand-new way of handling third-party data that increasingly feels like the obvious choice the more you think about it.

Transcript

00:00:00 - Christopher Burns

I can start it off, but I don't think I've ever actually pronounced your last name, Anthony.

00:00:04 - Anthony Accomazzo

One of my favorite things is hearing people attempt it. It's Akamatsu if you want to give it a little bit of an Italian flair. Akamatsu.

00:00:21 - Christopher Burns

Welcome to the show. Anthony Akamatsu and Eric Goldman from Sequin.

00:00:27 - Anthony Accomazzo

Thank you. Good to be here.

00:00:28 - Eric Goldman

Thanks for having us. We're excited to be here.

00:00:30 - Christopher Burns

I've already looked into Sequin a little bit. I've played around with the documentation, and I've played around with the product. It's really exciting what you're doing.

This podcast is going to go like this: I already know the product and understand it, and Anthony, for once, has no clue how anything works. So he's going to be asking the stupid questions this time and looking like the idiot.

00:00:52 - Anthony Campolo

Total noob here.

00:00:53 - Christopher Burns

Yeah. Before we get into the product, we always like to ask where you guys learned to code and how long you've been coding for. It's a nice icebreaker.

00:01:03 - Anthony Accomazzo

I grew up always building computers. I would install Linux operating systems for fun. I cracked the Mac operating system the moment they moved to Intel so I could install it on my desktop PC. But no one ever told me I could code and that it would be a good career path for me.

I actually studied electrical engineering in college, so the extent of my programming was in Verilog, if you can call it that. It wasn't until after I graduated that I picked up Ruby, Ruby on Rails, and was just so enamored with rapid prototyping, web application development, and startups that I got my first entry-level programming job. And then I've been programming ever since.

00:01:45 - Eric Goldman

For me, I'm relatively new to coding. In college, I studied economics. We had some required computer science courses, C++ and R, to properly handle statistical sets of data. I didn't really do too much coding other than that I got really good marks in those courses.

Then I went into product, and I was one of those product managers who had the deeply held belief that I didn't need to understand how to code to properly help manage the product or work with my engineering counterparts. And boy, has my opinion of that changed since learning to code.

So when I started working with Anthony right during the pandemic, it was like, this is the time to learn to code. With some mentorship from Anthony and on the side of our business, I picked up JavaScript and React and have been enamored ever since. Now I get the pleasure of coding every day a little bit, at least here and there, depending on what our customers need. So I'm fresh to it, I believe.

00:02:41 - Anthony Accomazzo

I told Eric, hey, this is going to be a fun, enjoyable ride no matter what, but if we're building a dev tools company, you're going to enjoy it a lot more if you know how to code. I think I was right.

00:02:52 - Anthony Campolo

Yeah. It'd be like having a whole staff of Spanish speakers and being like, I don't speak Spanish, but I can manage them fine, right? Like, what's the problem?

00:03:00 - Eric Goldman

Yeah. I mean, I think when I didn't understand how to code and I worked in building software products for a long time, it was always enjoyable to dig into it. I had enough understanding of generally how systems work together, and I had a rough understanding.

But really being able to participate, get in there, and understand what's going on, I'm a complete convert on that being a core competency for anyone working with development and shipping great products. It just makes it so much more fun. The opportunities of what can be built are so much more apparent. I love it.

You're looking at a little toddler coder over here, but I'm getting there.

00:03:33 - Christopher Burns

I think you've almost taken the same path as me, but five or six years later. When I moved to JavaScript, I moved straight into React. It's only recently, moving out of React, that I'm like, what is React and what is not React? That is such an interesting abstraction to learn about.

If you've just jumped straight into React, figuring out what vanilla JS can do by itself is such an interesting point. That's what Vue and Svelte do so well. Like, binding for onClick is totally different in React, and if you're so used to that abstraction, when you come away from it, you're like, how do I do it now? It just doesn't work like it does.

00:04:11 - Anthony Accomazzo

Even for seasoned developers, it's such a weird line because you have these two different runtimes. You have the browser runtime, and then you have the Node runtime. The Node runtime took a lot of those browser paradigms like setTimeout and just copied them into its own runtime. The lines and borders are super blurry.

With React, you have the DOM, the browser environment, and Node. There's enough shared between them that you get kind of lulled into a sense of unification, and then you find yourself in a weird corner case where they're not the same.

00:04:43 - Christopher Burns

I already know the answer, but what is Sequin built with? What tools? What frameworks?

00:04:50 - Anthony Accomazzo

We use Elixir and Phoenix on the backend, and then a React single-page app for the front end, and a lot of Postgres, as you can imagine.

00:04:58 - Anthony Campolo

It sounds like Supabase. It's a very similar stack to them.

00:05:01 - Anthony Accomazzo

Very cool.

00:05:02 - Christopher Burns

You don't use Next, or do you use Next? I thought you used Next for your SPA.

00:05:08 - Anthony Accomazzo

Yeah, we use it for our docs marketing page. I think our main single-page app does not use Next.

00:05:15 - Christopher Burns

Oh, interesting.

00:05:16 - Anthony Campolo

We should probably talk about what Sequin is before we start talking about all their tech and all this stuff. So why don't we get a high-level description of what Sequin is?

00:05:23 - Anthony Accomazzo

Developers log into our dashboard. They can select the services that they integrate with, like Stripe, Shopify, and Twilio. In just a couple of clicks, we begin a sync to their production database of all the data from that API, and we keep it in sync in real time.

So instead of having to go and make HTTP requests, deal with authentication, pagination, sorting, and filtering to get the data that you want from these APIs, you can just read from your production database using SQL or your favorite ORM instead.

00:06:00 - Anthony Campolo

This is such an interesting pitch for me because I work at a company called StepZen, which is slightly similar, but not exactly the same pitch. We're giving you an API gateway into a whole bunch of different data sources, whereas you're giving a database that aggregates all the data sources.

So it's like you're kind of the back of the backend, and we're like the front of the backend. The point you're kind of solving is not necessarily like a unified... well, it is both a unified access point into the data, but it sounds like it's also about backups and just having all the data in one place and audits. Is that kind of also the pitch here?

00:06:37 - Anthony Accomazzo

That's definitely a big part of it. I think, in general, we think SQL is a lingua franca. It is a standard. The Postgres database is a standard format that people are already familiar with. HTTP APIs can only hope to approach SQL in terms of expressibility and power when querying for the data that you want.

If an API doesn't let you sort by createdAt ascending as opposed to descending, you're hosed, and you have to paginate all the way through to get the first event from that API. But if it's in a database, it's two words and boom, you've just flipped the sort. For us, we just see putting the data into the database as being a de facto normalization and standardization of that data.

00:07:18 - Christopher Burns

I've played around with both products. To me, they both tackle the use case of, say, I want to normalize and standardize my Stripe data, for example. Both platforms can do that, but they do it in completely different methods.

StepZen unifies it into a simple GraphQL API so you don't need to go through Stripe's APIs, and Sequin backs it all up to your database, and then you can call it through tools like Prisma. It is that thing of like, you may find that one choice will be better than the other choice depending on your scenarios.

But it's really interesting to know that there are now multiple choices to tackle the same end goals that will give you such a different outcome on how you handle your data, what layer the data is coming from, and how deep the data is accessible. So it's really, really interesting.

It's something that I've looked at myself at my company, Everfund. I can see solutions for both at two different levels. It's a really, really exciting industry that, as you said, you think is a unique new idea.

[00:08:27] And I would completely agree. It turns your Stripe data on top of its head. I no longer have to call Stripe's APIs. I can just do a join or find it however I need to find it and then handle everything else myself.

What's really, really exciting about this is obviously because it's just Postgres that you're spitting it all out to, you can use tools like Prisma. I've used Sequin with Prisma and also Redwood, one of these FSJam frameworks. The real power that I saw was how fast you can go from not having anything, any of your Stripe data, to: I've connected my production database, I've added it to my Prisma file. Just like that, data is moving over, imported, and you have all that data.

You run your generators through Redwood like that. You can literally just call all that data that you used to have to go through the Stripe API to get, and it is now fully accessible through a GraphQL endpoint. When I used it and I was testing it, I found out it unlocked new ways of fetching the data because, with GraphQL and Redwood, you can just carry on your waterfall as deep as you want to find the data that you want through any relation.

[00:09:47] Doing that, I found it so much easier to find core information points that were actually a lot harder to find out through just going through the Stripe API, because sometimes you felt like you would pull once, and then you would get your answer and then go, okay, now I need to pull again to get the answer from that one, then pull again to get the answer for that one.

But because this is obviously mixing technologies like Redwood and Sequin and Prisma, you can just waterfall it all the way down to get the answer you need in one GraphQL statement. So to me, Sequin is a really, really powerful tool and I really recommend people give it a go.

Obviously I've just mentioned it supports Stripe, but what else does it support?

00:10:27 - Anthony Accomazzo

I want to comment because you said a lot right there that I was super engaged with, and I'm just glad to hear about your experience.

If you think about it from first principles, we kind of thought, well, why does this API exist in the first place? There's basically two main reasons. The first one is security, right? In a world of perfect trust, Stripe would say, hey, here's a database user for our production Stripe database. Just don't look at anyone else's data but your own, but have at it, right? They would just kind of let you go in there and query and get the data that you wanted. That's one reason that we have APIs: to control access.

And the second reason is as an abstraction layer, so that if they change the name of a column or a table, they don't have to break all the integrations with that API. We realized that we could pull that off with a database instead, which is pretty exciting. But now when Stripe builds that API, HTTP can only ever approach SQL in terms of expressibility and queryability.

[00:11:20] So they have to basically think about what the most common use cases to query the data will look like, and then recreate those use cases as REST endpoints with various query parameters. But it's never going to be as complete.

And as you were discovering, Chris, they can't predict all of the use cases for how you might want to query data for your startup. So you're going to have these access patterns, especially as your integration grows and gets bigger and bigger, that are hard for them to anticipate or support. And that's where having it all in SQL just unlocks all of those new ways to query the data, as you were describing.

As far as which platforms we support right now in production: Stripe, Airtable, Twilio, and Close, the CRM, with Shopify in a closed alpha right now.

00:12:04 - Anthony Campolo

The Airtable one I'm kind of curious about, because this is one that I had never used Airtable before I started working at StepZen. It's used in a lot of example apps, and a lot of people at the company are very into it.

I'd always known it was fairly well known, like a big-deal type thing because it's a database, but not exactly because it's like a database. It's like a really, really nice API on top, I think is kind of the idea.

But when you go to your pricing page, you have two options. You have the Pro and Enterprise, and then you have an Airtable option completely separately. So it seems like Airtable has kind of a privileged position here compared to the other connectors.

So first, let's define Airtable for our listeners. What is it if they've never heard it at all? And then why is it such a big deal? Why do developers love it? Why have you invested so heavily in it?

00:12:52 - Eric Goldman

Airtable absolutely has a special place in our company's history. It's the first platform we integrated with. What Airtable is, for those that don't know, is it's basically a database, a relational database with the niceties of a spreadsheet interface.

It basically takes Excel VLOOKUP and makes it a first-class feature where you can automatically create relationships between tables, which for those of us as developers, is just a nice relational database.

It's incredibly popular at companies of all sizes because it allows you to organize almost any task or workflow that you'd otherwise do across hundreds of Google Sheets in one Airtable base.

We launched on Airtable because it actually does have a fantastic API. You can access all your data in there. But if you go into the docs, if you're going to be doing heavy reads from Airtable, they encourage you to use a caching layer. Because there's a five-queries-per-second limit, it's very easy to get rate limited and not be able to pull out all the data you need.

[00:13:52] We saw Airtable as kind of the perfect prototyping platform. Actually, Anthony and I had worked on a charity that used Airtable as its primary backend, and you really quickly began to hit this throttling as a developer. You knew that all of your non-technical teams, operations, and people working with a volunteer organization could easily work with all the data, but as a developer, we were quickly kind of hitting the limit of what we could build on top of it.

You go into that community, and the Airtable community is fantastic, and you just saw all these requests of, hey, could I use SQL to query this data? Could I get this into my database? Can I work with it in real time? We shared the same pain point. And we had the same hypothesis, which is this data should just be in a database.

So we started with Airtable and we were delighted with how quickly the Airtable community picked it up, started working with it, and all sorts of amazing companies came out of the woodwork that we had no idea were using Airtable, or were using Airtable in such a way that their entire business ran on it as their primary data source.

[00:14:50] It was really surprising. As we expanded, we knew that we wanted to do more than just Airtable. We wanted to service every API, but Airtable's API is really unique compared to Stripe or Twilio's.

From a business perspective right now, it just didn't make sense to price Stripe the same way that you would price Airtable for a myriad of reasons, one being that the data volumes are dramatically different between Airtable and Stripe. Stripe can have millions and millions of rows of data. You can have thousands of transactions a day. Chris, as you launch a big charity campaign, Airtable maxes out at 100,000 records.

Stripe has an event-based API and system, so we can really integrate in a pretty smooth way. Airtable requires polling. They don't provide any webhooks or notifications that a single record has been changed.

So both from an architectural perspective and just from a business perspective of actually how these platforms are used and consumed by developers, we split them up for now to make it really easy for our customers to adopt and start working with their data without needing to think about the complexities of data volumes or anything like that.

00:15:56 - Christopher Burns

One of the big things we've been speaking about is that your data, instead of using the API, is now stored in your database. So what does that unlock? What abilities can you now do with that data?

00:16:09 - Eric Goldman

When we sync to your Postgres database, we really think that we're giving you a really powerful primitive that contains all your data in a standardized, approachable way that isn't standardized by our unique definition. It's standardized by the protocols of Postgres.

What it unlocks is instant accessibility of all your data, which I think really changes the adoption curve of platforms. You quickly get to their tutorial like, okay, I'm running a payment through Stripe. We rapidly take you to: I'm getting a payment processed in Stripe, and I'm showing the customer their invoice, and I'm showing them their receipt, and I can allow them to do a refund right away.

That instant accessibility of all your data in a local database really changes the way we're seeing developers adopt platforms and accelerates the way that they actually build really cool things on it.

That transactional use case is the thing that makes us most excited. It's just seeing developers build features that their customers can use, all on a really complicated platform like Stripe or Twilio, in a much faster time frame.

[00:17:10] But once all the data is in your database, you also unlock all sorts of other downstream use cases. It's all in your database, so pulling BI and analytics out of that database is much easier. Building internal tooling on that data, like simple internal CRUD apps, is much easier with Postgres.

What we're really excited about and beginning to focus on is that full developer lifecycle of how an entire team can work on an API and test and build and deploy much more elegant, interesting, cool features without all the bottlenecks of having to work through an API layer first. That database is really something every developer has been working with, and by putting all the data in that database, you just unlock all the use cases they've already been familiar with from a database.

00:17:53 - Anthony Campolo

It's cool how you have docs for actually showing how to hook up Prisma, because as you're saying here, it gives you a SQL interface and that is really great if you know SQL. But some devs, they either haven't learned it yet or they have no interest in learning it. I think it's a useful skill, so I would recommend most devs kind of bone up on some SQL if they can, but giving that ORM layer can be super useful.

And so I'm seeing some Prisma examples. Are there other ORMs that you think are good to use, or do you push people toward using Prisma, or is it just because you wanted some example and that seemed like the most popular one to do? What was the decision-making around the ORM layer?

00:18:32 - Anthony Accomazzo

We definitely want to support and be ready to support ORMs in every language. Because you're right, for most developers, the way that they interact with their data in a database is through an ORM. We chose Prisma to showcase, in large part because a lot of our customers right now are using Prisma, and it's a really great ORM.

00:18:53 - Christopher Burns

You could say it's the best ORM currently today. Or is it? I don't know.

So you have a lot of examples in your developer documentation. As you were saying, they all show how to build these business intelligence tools. And I'm pretty sure some of them are without even using a line of code as long as you have a database.

There was something really interesting I came across. What happens if I need to wait for some data? How do I know that Sequin has put the data that I need in my database? Say I'm doing something transactional, like a checkout. I obviously need to wait somehow. So how does Sequin handle that?

00:19:33 - Anthony Accomazzo

This is a key use case. We call it the read-after-write use case, which is very common. Let's say that we're working with Stripe and a customer changes their credit card on file.

So what does that look like in the code? Well, you make a call to Stripe to update the credit card, and then hopefully you just re-render your React app and you hydrate the React app with SELECT * from your database. But there's a race condition there. You wrote to Stripe, and then there might be some delay before we sync that data to your database. We're syncing data every 500 milliseconds, so it's a small delay, but there's still that race condition.

So we have what we call the wait endpoint, which you can call at any time. When you call it, we just ensure that your database is up to date before returning a 200. So now this workflow will be: call Stripe with this POST or PUT request, call Sequin's wait endpoint, and then after that you can confidently read from your database and know that the data will be up to date.

[00:20:33] So this is how we control for those race conditions around the fact that you're reading from a database but writing to an API.

00:20:39 - Christopher Burns

It's such an interesting circle that you need to understand. I'm always going to write to the Stripe API, but I don't necessarily have to read from the Stripe API anymore because I've got all the data in my database.

It was that moment of: I've put in the card details and I've sent it off to Stripe, expecting a re-render of your React page. But what happens if Stripe returns and says, yep, we've done the purchase, and then you call your Stripe API and it returns something that says purchase incomplete when actually it was complete, it just re-rendered too early? So the wait command, well, it isn't a command, it's an endpoint, is super useful for that.

00:21:28 - Anthony Accomazzo

One key thing that we often get asked: right now we do focus on that one-way data flow, syncing from the API to your database. Part of the reason we're focused there is we think that reading from APIs and writing to APIs often get conflated, but they're actually super different problems.

So for reading, the question is things like rate limits, pagination, query parameters. But writing is validation and retries. They have very different problems and designs that you need to do. So we're focused right now on reads because we think that that is a uniquely hard problem, and that we can make it extremely easy by putting it in your database.

And for writes, you still write to the main provider, the main reason being that you want to go through their validation stack to make sure that that credit card that the customer entered is actually valid, as opposed to writing to your database and then having to figure out later if that transaction was valid. So that's kind of the data flow right now.

[00:22:30] Read from your database but write to the API, call that wait endpoint, and then you'll know that when you do that next read, the data will be up to date.

00:22:38 - Christopher Burns

What about unique data, as in data that's never been queried before? I'm trying to find an address. We wouldn't expect Sequin to save every address in the world. Is there a solution for that kind of more transactional data searching, or is that still an open book of something you will tackle or will not tackle?

00:22:59 - Eric Goldman

So you mean in terms of a query path that is completely outside the standard API paths?

00:23:06 - Christopher Burns

Well, I mean, you're using it as a tool. So when we say it's an abstraction layer on third-party APIs, it's not an abstraction layer on every API because some APIs it wouldn't make sense to store all things in a database, like, for example, a search address finder. That's very transactional, very unique. I'm using all the wrong words, obviously, but do you have plans on how to integrate those kinds of tools as an abstraction layer above, or is that something that you're going to just tent post and put your flag on the hill and say, that kind of API we're not going to tackle?

00:23:43 - Anthony Accomazzo

It's a great question. We haven't thought a lot about those APIs. I think you're talking about something like EasyPost or Easy Street, the address lookup, right? Yeah, I think those we would imagine you'd probably keep as remote procedure calls, but we haven't thought too much about that.

00:24:01 - Anthony Campolo

I was curious to get into the pricing because this is a rare company we have that does not have a free tier, it looks like. And whether something is pricey or not is an arbitrary question because it's a question of, like, what is the value you're providing?

So I think it's totally valid for a company to charge lots and lots of money for the product if they're offering lots and lots of value. So I'd be curious, what is the pricing structure, and then how do you make the pitch for why that is worth the developer to invest in this product?

00:24:26 - Anthony Accomazzo

Yeah, the free tier. We hope to bring it back. It's really just that we're super early. And from a product pricing perspective, we started with what was easiest, which is a flat price.

But we're introducing things pretty soon that will allow for incremental adoption. Instead of adopting the whole Stripe API all at once, you can maybe select just a couple of sub-tables or just the most recent data, and then that would qualify for a new free tier. So it's coming.

00:24:53 - Eric Goldman

The free tier is coming back. It's coming back soon.

00:24:56 - Christopher Burns

That's great to hear. What does the next six months look like? Are we going to see much improvement on Airtable and Stripe, or are we going to see more APIs being added? How do you see the next six months going?

00:25:10 - Anthony Accomazzo

The feature we're most excited about that we're working on right now is an events system. Imagine we are able to track all changes to all the APIs that you sync to your database using Postgres triggers, and then we can use those changes to call callback functions in your code base.

So sort of like a durable webhooks system, as opposed to having to set up a web server that can never go down, that will listen to all the webhooks from these APIs. And some of these APIs don't support webhooks like Airtable. Instead, Sequin can generate an event stream for you, and then we'll pair that with client-side libraries in your language like Node.

That will allow you to set up callback functions. For example, every time a Stripe customer invoice is created or updated, call this block of code with that data so that I can act on it, send that data to another API, or insert it into a table in my database. So that's one.

The other, as Eric mentioned earlier, is really covering the full lifecycle of adopting an API integration.

[00:26:20] So what does it look like when you want to develop with Sequin? You're doing this locally or with a local database. We don't have a great answer to that. Or what does it look like when you want to write automated tests on top of the API integration? Answering those questions and coming up with great solutions for them so that you just have an easy path for that full adoption cycle is going to be key for us.

00:26:43 - Christopher Burns

Your first potential product, is that more like a webhook replacement tool, like custom event-based webhooks? Because that's the one thing that I can say Stripe does really, really well: their webhooks and the things that they can trigger custom code on.

But where I think that webhook solution is always let down is in the actual implementation in the client. Sometimes it's a bit too open, as in, oh, you need to sign the webhook, but apart from that, we leave that all up to you. And we've seen tools like Squirrel Dev actually build this custom webhook wrapper around their cron job system. So basically cron jobs for JavaScript apps.

00:27:28 - Anthony Campolo

Coral, not Squirrel.

00:27:29 - Christopher Burns

That's it. Coral by...

00:27:31 - Anthony Campolo

Simon. That's why you were thinking Squirrel, because you combined Simon and Coral.

00:27:36 - Christopher Burns

There you go. But he built a custom wrapper around his webhooks to make it much easier. So it's more like every single webhook was a Lambda function that you could just call and be like, everything in this code block will run and handle everything else.

So I think that's something really, really interesting, and especially, as you said, if you can add webhooks for things that don't have webhooks, that's super exciting.

00:28:03 - Anthony Accomazzo

We'll have to check out Coral. That sounds very similar, right? So getting rid of all the overhead of: did we miss these webhooks? Do we need to pull to backfill them, or do we have to check to make sure they're signed correctly? We're eliminating all of that, much like it sounds like Coral is doing.

00:28:20 - Anthony Campolo

Yeah. Someone actually just dropped a thing called JobScheduler.net in a Discord I hang out in, so there's another JobScheduler one for you to check out.

But yeah, we had Simon on almost a year ago now on the show, so I'm assuming it's still going strong.

00:28:34 - Christopher Burns

It was built for the Next community first, not the Redwood community, but it does have implementations in all languages. What I thought was really good was that abstraction over webhooks, if that makes sense.

Because we could speak all day about webhooks, but that's another area that I think is ripe for innovation because it's just a bit too complicated. When we live in this world of Lambda functions, of just like run everything in this function, surely it should be easy to just say event A, run this code; event B, run this code.

But obviously that requires JavaScript abstractions to be written into your API, so some open-source library potentially. There's a lot of work to do there as well. Webhooks is a super interesting area. I'll be really interested to see that solution.

00:29:21 - Eric Goldman

We're excited to roll it out. We think pairing a Postgres database with a complete events table and a client library really unlocks, to your point, Anthony.

If SQL is not your language of choice, of course you can use an ORM, which is fantastic. But then when you also have our client libraries, you can use native Node, your language of choice, to really work with and process and adapt the data to your needs. We think it really begins to close the full use case that we're seeing all of our customers ask for.

We've kind of begrudgingly had customers asking about these events and how they handle these webhooks and how they trigger these outcomes. We've really taken this approach of letting developers convince us of why they need it, how they need it, what it's going to do for them. We think this kind of closes a really compelling loop of being able to really make sure all the data that your company relies on from these third-party APIs is completely accessible to the developer natively.

[00:30:17] So we're excited to roll it out. And, Chris, you're going to have to give us some proper feedback on it once we do.

00:30:23 - Christopher Burns

I love giving feedback to all tools. And just so everyone knows, sometimes I feel like a really bad critic. It's like I've just looked at their tool and I've just ripped it apart saying, this is awful, but it has good potential. So please come back to me because as a company owner myself, it's just what you want to hear.

But people are like, they'd rather just never use the platform again, have those thoughts in secret of, oh, it didn't do this, so now I'm just going to walk away. A lot of the time it's like, yeah, but if you say I need it to do that, maybe begrudgingly, most of the time developers of the software will be like, yeah, we'll do that, because more customers, more potential revenue. It's all business at the end of the day.

We wanted to quickly get into what the rest of your team looks like. We see that you're currently hiring. There's a lot of JavaScript developers that listen to this, so if you want to plug your careers page, we'd be happy to let you.

00:31:18 - Anthony Accomazzo

So the team is super small. It's just Eric, myself, and Kiki, who's a full-stack developer based out of São Paulo, Brazil. Kiki is actually part-time right now because he's still in high school, but he graduates high school in two weeks, so we're so excited to have him on board full time.

00:31:35 - Anthony Campolo

Let's see. A smart high schooler.

00:31:37 - Eric Goldman

He's amazing.

00:31:38 - Anthony Accomazzo

He's an extremely smart high schooler. He learned to code when he was 12. He didn't have internet at the time, so I'll let you fill in the gaps around how smart he is.

But we are hiring, and it's an incredibly exciting time to join us. Not only are we working on developer tools for our customers, who are other developers, but we have traction. We're pre-product market fit, but we're closing in on it.

So for anyone that's entrepreneurial, loves building tools for other developers, and wants to kind of see a startup go through the iterations to close the gap on product market fit, this is the perfect time to join us.

00:32:19 - Anthony Campolo

And did you take funding or are you bootstrapping?

00:32:21 - Anthony Accomazzo

We took funding. We raised a pre-seed round from David Sacks at Craft Ventures.

00:32:28 - Anthony Campolo

Oh, cool. Awesome.

00:32:30 - Christopher Burns

I feel like the odd one out here because all three of you are in California, so it's super early for all of you and it's like 5 p.m. for me. So I think I got the better time today.

00:32:41 - Anthony Campolo

We'll be here much longer. I'll be out of here in two months, hopefully.

00:32:44 - Anthony Accomazzo

You know, the daylight savings transition has made early mornings a staple. So it's been a great past couple of weeks.

00:32:53 - Eric Goldman

Fantastic conversation to wake up to.

00:32:55 - Christopher Burns

It's beautiful. I think that's about it. Is there anything else you want to say about the company, where people can find you, what you're interested in, anything else? The limelight is yours.

00:33:06 - Eric Goldman

You can find us at Sequin.io. Oh, that's sick. Sign up. We have a completely free trial that's very flexible. So we don't have a free tier at the moment. It was very hard for people to understand our free trial initially.

But please sign up and give it a try. You can email us at any time: founders@sequin.io, and we'd love to hear from you. We're just getting started, so these are early days for us. We're so excited about the opportunity to just tell you our story and to tell us yours. We want to help you build something cool, so we're excited to hear from you.

00:33:38 - Christopher Burns

So as you have feedback on this episode, just message founders at Sequin dot io. We don't need to hear it for once.

00:33:47 - Anthony Accomazzo

Just send it our way.

00:33:48 - Christopher Burns

It's been a pleasure to have you two on. I'm really excited about your company. I can't wait to see where it goes, and I really hope that it puts a flag on a brand new hill, as I can say, as this is a brand new way to do something, because it's a really unique way that the more you think about it, the more it almost always makes sense to do it that way.

00:34:12 - Eric Goldman

We think so too.

00:34:13 - Anthony Accomazzo

Yeah. Thanks for having us on.

00:34:15 - Eric Goldman

Yeah. Thank you so much for this opportunity. Really appreciate it.

00:34:48 - Anthony Campolo

Sweet. Yeah, we went a little under there, but I think you guys were very, very succinct in your answers, in your descriptions. So I think we covered pretty much everything people would want to know. So yeah. Great to hear.