Reliable Payroll Systems in TypeScript with Effect
#7: Reliable Payroll Systems in TypeScript with Effect
In this episode, Johannes Schickling talks with Adam Rankin, CTO at Warp, about using Effect to bring structure and composability to a growing TypeScript codebase, enabling a small, fast-moving team to stay productive while shipping reliable payment & payroll systems.
In this episode, Johannes Schickling talks with Adam Rankin, CTO at Warp, about using Effect to bring structure and composability to a growing TypeScript codebase, enabling a small, fast-moving team to stay productive while shipping reliable payment & payroll systems.
Effect is an ecosystem of tools for building robust, production-grade applications in TypeScript.
Song: Dosi & Aisake - Cruising [NCS Release]
Music provided by NoCopyrightSounds
Free Download/Stream: http://ncs.io/Cruising
Watch: http://ncs.lnk.to/CruisingAT/youtube
- (00:00) - Intro
- (01:45) - Adam’s background & early startup experience
- (08:18) - Warp’s origin story
- (17:36) - What made Effect click for Warp
- (29:24) - Getting started with Effect (AI browser agent)
- (34:52) - Onboarding developers to Effect
- (42:17) - Benefits of composability in payment systems
- (43:53) - Warp’s system architecture
- (56:48) - Closing thoughts
Transcript
00:00I'm coming to them and saying, learn this
00:02entirely new way to write TypeScript.
00:04Trust me, bro, it'll be worth it.
00:06And it helps to like have some examples I
00:08can point to. And I think I recall one
00:11team member of the one actually with
00:13prior TypeScript experience.
00:14He he trusted me enough to give it a try.
00:16And he said it really clicked for him
00:19when he was writing tests, actually,
00:21because he mocked some layer or
00:24wrote a test layer for for some service.
00:27And he's like, oh, this is what I can do
00:29with this and like isolate just certain
00:31services and tests
00:32just the core business logic.
00:34And it's super helpful there. But
00:36that was the moment that clicked for him.
00:37I think we've all had sort
00:39of that that moment, you know, that that
00:41is just like, oh, this is
00:42what this is capable of.
00:43This needs to be sort of
00:44everywhere on a code base.
00:49Welcome to Cause & Effect, a podcast
00:52about the TypeScript library and
00:53ecosystem called Effect, helping
00:56engineers to build
00:57production-ready software.
00:58I'm your host, Johannes Schickling, and
01:00I've been building with
01:01Effect for over four years.
01:03With this podcast, I want to help others
01:05understand the powers and
01:06benefits of using Effect.
01:08In this episode, I'm talking to Adam
01:10Rankin, CTO of Warp, a YC-backed payroll,
01:14payments, and HR platform for startups.
01:17In this conversation, Adam shares his
01:19path from Rails to TypeScript and how
01:21Warp incrementally adopted Effect across
01:24a single fast-moving monolith.
01:26Let's get into it.
01:28Hey Adam, it's so nice
01:30to have you on the show.
01:31How are you doing?
01:32Doing well, thanks for having me.
01:33Excited to be here.
01:34Yeah, I'm really excited to
01:36learn more about Warp today.
01:38But before we talk about Warp, do you
01:40mind sharing more about who you are and a
01:43little bit of your background?
01:45Sure, so I'm Adam. I'm the CTO of Warp.
01:48I came to Warp maybe three years ago,
01:51started it with the CEO who
01:53I actually met on Twitter.
01:55Before that, I've only
01:56ever worked at startups.
01:58I have experience building web apps of
02:00all sizes using mostly Ruby on Rails.
02:03And I trained as an engineer in school.
02:06That is awesome.
02:07So you mentioned like most of your
02:09background being in Ruby on Rails.
02:12Can you already foreshadow a little bit
02:14of like how you went from
02:15Ruby on Rails to TypeScript?
02:17Did that happen at Warp?
02:19Did that already happen
02:20as sort of a prior role?
02:22Sure, so I actually started
02:24my career in Ruby on Rails.
02:26I worked at a startup while I was in
02:28school who was
02:29building a web app on Rails.
02:31And I actually didn't know any
02:33other way to build a web app.
02:34It's a great experience, Rails.
02:36It's very opinionated.
02:38Ruby is a very sort of
02:40easy language to write.
02:41I like to say if you know English, you
02:44know Ruby because you're just kind of
02:45like guessing the
02:47method names and they exist.
02:49And then I actually sort of took a long
02:51break from it while I was writing some
02:53Python and various backend services for a
02:57bigger company, a banking company.
02:59And then when it came time to start Warp,
03:01we kind of were
03:02choosing our initial stack.
03:03And we were choosing something that could
03:05make us move as fast as possible and ship
03:08early features to customers.
03:09And at the end of the day, I basically
03:11googled, you know, what do
03:13people use in web apps nowadays?
03:15And it's like, okay,
03:17Next.js has some cool logos.
03:19Let's try this.
03:20And that's sort of how we
03:22started with TypeScript.
03:24I actually want to linger a little bit
03:25more on that because I feel like that
03:29there is still some aspects about like
03:31Ruby on Rails is not bad it is like I'm
03:33not sure numbers wise, I wouldn't be
03:35surprised if it has more usage than ever
03:38before, just because like the well, many,
03:41many people are building software in
03:43many, many different ways.
03:45I think like one of the like North stars of
03:48like what developer experience can be
03:50like that I think in many regards, the
03:53TypeScript ecosystem has not been able to
03:56replicate partially due to just the
03:58constraints of the language, but also
04:01like there's some like vibes and some
04:03like maturity and some like elegance of
04:06the ecosystem that I also
04:07think like kind of culturally is
04:10quite different in the JavaScript and
04:12TypeScript ecosystem and I
04:14don't agree with like all the
04:17perspectives that the Ruby
04:18on Rails creator DHH has.
04:21I still think that there's
04:23like very interesting ideas.
04:25So I'm curious whether you're still kind
04:27of like keeping up with the developments
04:29where it's like Ruby on Rails is going
04:31whether you're still can derive like some
04:33inspiration from that ecosystem.
04:35I haven't kept up with the development
04:37lately. It's funny you say that because
04:39Rails is definitely lingering. It's
04:41definitely still strong.
04:42You know, every I feel like once a month,
04:45you find out like a new website or some
04:48new product that has billions of users or
04:51sorry, millions of users and it's like,
04:53wait, they're on Rails. No way.
04:55So many like of these huge products
04:57started on Rails and I think it's because
04:59it has so much out of the box that you
05:02you need to run like like jobs for
05:04example, you know, you pick up a
05:07TypeScript project and you're like, how
05:09do I queue up some background job and
05:11like respond to my users API request and
05:15in Rails, that's kind
05:16of trivial in TypeScript.
05:18There's no opinionated way to do that.
05:21People are doing all kinds of different
05:22things. You have to kind of build your
05:24stack more and think about it.
05:25I think good DX tends to always win. That's
05:28why we see Next JS on Vercel winning.
05:31Rails is super easy and it kind of
05:33abstracts away the complications of doing
05:35a lot of infrastructure heavy activity.
05:38And I think that's something that the
05:39TypeScript ecosystem in
05:41general is, you know, behind on.
05:43Yeah, I definitely agree. I think what
05:45you've mentioned about like the queuing
05:47system or like any kind of common
05:49canonical thing. Yes, it is possible with
05:52TypeScript, but you like open 10
05:55different blog posts that show you how is
05:58like any find 10 different ways.
06:00Whereas like in the Ruby and Rails world,
06:02like you have 10 blog posts and they all
06:04show the same like there's just like in
06:06one world you're kind of like at ease
06:08where you feel like okay like all roads
06:11where you feel like okay like all roads where you feel like okay like all roads
06:11lead to Rome and like in the TypeScript
06:13world is like wait what like no this is
06:15like entirely different
06:16stack like should I use that?
06:18Oh no, people like in Reddit say like
06:20it's dead. Should I use that? And it's
06:22just like it's a very different world.
06:25And I think there's like a lot positive
06:27to be said about about that where like I
06:30think it's a it's a richer place for
06:32different ideas to like be
06:35be explored at the same time.
06:38But there's also the kind of like
06:40confusion that and sometimes even like
06:43like paralysis of choice that
06:45comes alongside. And
06:47you see a similar thing also in
06:49other language ecosystems, Java obviously
06:52being a big one, but I think in Java, you
06:54have something like Spring etc that has
06:56more of like that that rails kind of
06:58coercion in in one direction.
07:02And I think this is also for if we're not
07:05bringing things back to to Effect, what
07:07we want to talk today about.
07:08I think this is also one of the big
07:10pieces of potential of effect. Yes, it
07:13gives you individual building blocks, but
07:16they all fit together in one holistic
07:19cohesive way of building software that I
07:22think can actually bring a lot of the
07:25nice coherent aspects of something like
07:28Ruby and Rails or something of
07:29like Spring Boot to the the TypeScript
07:32world. And so yeah, and I think we're
07:34going to hear quite a lot about that
07:36today is like in the way how you're
07:38building Warp. So thanks a lot for for
07:40sharing your background and like
07:42which twisted paths you've
07:44taken through the world
07:46of software development.
07:48Maybe before we dive into all things
07:50technical, can you share a little bit
07:52more about Warp? So you mentioned you
07:54started it together with a friend who you
07:56met over over the
07:57internet three years ago.
07:59Like how quickly did things develop? Like
08:02I think today it's no longer just the two
08:03of you, but you I believe like you you
08:06raised a fairly big round recently.
08:08Can you share more about the company and
08:11maybe starting with what is Warp? What is
08:13the product and the goal of Warp?
08:16Yeah, definitely. So we have sort of a
08:18funny origin story. I met the
08:21founder on Twitter in sort of this
08:24pseudonymous era where where people were
08:26using like fake Twitters to sort of meet
08:29each other and he had announced a project
08:32that he was working on
08:33and he raised money for
08:34I thought it was cool. It was actually a
08:36consumer social app. So I had joined it
08:39and and we kind of connected on there
08:41And he had posted on there that he was
08:43looking for engineers and I was sort of
08:45looking for my next thing at the time.
08:48So we actually met each other and agreed
08:51to work together before we knew each
08:53other's names. I always like to tell that
08:55story because it's super funny. I was
08:57visiting my parents at the time
09:00And I was like, oh, I have sort of a job
09:03interview and they were like, you know,
09:05with who? And I was I was like, I don't
09:08know his name, so I
09:09can't really tell you that.
09:11And there was a peak of covid as well,
09:13right? Yes, yes, this is like 2021.
09:16at the time for some
09:18personal context, I was like kind of
09:20playing with the idea of starting my own
09:22thing. I had left my previous role. I was
09:24actually living a nomadic life. I was
09:27living in a different city every month.
09:29So I found this social app. I met the
09:32founder of it. We agreed to work together
09:35on this social app. It
09:36was Swift UI, AWS, Firebase.
09:41And when you build a consumer social app,
09:44you need to monetize it
09:45eventually. And there are only two ways
09:47to do that. And it's to get people to pay
09:49or to get people to see ads.
09:52And if you're not growing with some
09:55insane K factor, then you're not going to
09:57make any money on ads. So we ended up sun
10:00setting the project and sort of going
10:01back to the drawing board and saying, you
10:04know, what can we build?
10:05And again, this was mid covid. We were
10:08using a competitor, payroll product at the
10:11time. And our sort of insight was that,
10:14you know, remote work is not going
10:15anywhere. There's a lot of compliance
10:19work in paying remote teams and paying
10:21people across the globe
10:22and across the country.
10:24There are thousands of tax jurisdictions
10:26like what if we could just take all of
10:29this off the plate of founders and build
10:32a payroll payments HR products tailor
10:36made for startups and founders.
10:38So that sort of was our initial insight.
10:41We joined YC and started talking to
10:45startups and other small customers. It's
10:48like, what do you need? Let us handle it.
10:51And that's sort of how we got started.
10:52And our roadmap has sort of been built
10:54from there. We've like built a lot of the
10:57table stakes features you need. And now
10:58it's very product driven by like
11:01what people are requesting.
11:02And then sort of in conjunction with
11:05the whole covid thing, the LLM
11:07revolution has sort of come along. So
11:09we're now exploring ways to be more AI
11:12native and use these things for
11:15automating different processes that that
11:16we don't want to do.
11:17And our customers don't want to do so.
11:19Hopefully that's that's a good background
11:20on kind of how we started and what we do.
11:23Oh, most certainly. And I want to make
11:25sure that we come back to the AI native
11:28automation part as well as that's another
11:30key interest of
11:31mine currently as well.
11:32But I want to linger a little bit more on
11:35sort of like your personal relationship
11:37to Warp as you went from building a
11:41consumer app to now building a software
11:44for other startups, etc.
11:46I guess much more B2B. And I think there
11:49is kind of two perspectives on like how a
11:52startup founder can end up building
11:55something either kind of out
11:57of love or out of frustration.
11:59What I mean with this, you love something
12:01so much. So you want to build something
12:03that's just like fundamentally good and
12:06like makes it even better.
12:07Or you're so frustrated with an
12:09experience that you say, like, OK, this
12:11needs to be solved. And I think you're
12:13falling into the ladder.
12:15But I think what is tricky about that as
12:17a founder myself, like I had plenty of
12:20like very frustrating experiences
12:22throughout my life where I felt, OK,
12:25there can be something better.
12:26But I also then pictured myself in a life
12:29where I'm not like solving this problem
12:31for 10 years and I would not derive a lot
12:35of joy of like getting and becoming an
12:37expert at tax codes in France.
12:41I'm like frustrated enough with like
12:43barely trying to stay
12:44afloat with the German ones.
12:46So I'm just curious like how your own
12:48perspective is sort of
12:49like has evolved on that.
12:51I'm very glad you're all in solving this.
12:54So I have a better
12:55experience not being exposed to that.
12:57But how you're finding your own balance
13:00of like that frustration that you wanted
13:02to address, like you're flying even
13:05closer to that sun of
13:07frustration to like figure it out.
13:09Maybe you can just
13:10reflect a little bit on that.
13:12Yeah, yeah, it's a funny question because
13:15payroll tax codes, it's like the
13:18unsexiest thing you
13:19could probably imagine.
13:20It's like B2B SaaS payroll.
13:22I have like a few answers to that.
13:24I think one is like the fact that not
13:28many people could imagine themselves
13:29doing it is sort of good for us because
13:32we're happy to kind of go in and like get
13:35our hands dirty and let's
13:36figure out what needs to be done.
13:37And I think the actual joy of building a
13:40product comes from seeing a customer use
13:43it the right way, seeing a customer be
13:46satisfied and not have to worry.
13:49One joke we like to make is that we pride
13:51ourselves on least required user minutes.
13:55So we have some founders that have like
13:58not logged into our product in months and
14:00it's just sort of running in the
14:01background for them.
14:02So we like take a lot of joy in people
14:05not actually having to use our product
14:07because we've become
14:08experts in payroll and tax.
14:10And yeah, I definitely know more about
14:14payroll than I ever thought I would.
14:16But I think that building a intuitive UX
14:20for something that's so boring, I think
14:23with sort of these unsexy industries,
14:25people come to expect unsexy and clunky
14:29products and we're trying to change that
14:32and that's really fun to me.
14:34All right. Yeah, that definitely
14:36resonates. And so like if you think about
14:37this as like this delta between like very
14:40frustrating experience without work to
14:43like joy and delight and like blissful
14:46ignorance of like all the stuff that
14:48needs to happen behind the scenes.
14:50Like if you can get it, delta is probably
14:53pretty wide. So thank you for doing that
14:56work that no one else has to do it.
14:59So yeah, I don't want to get much
15:01closer to tax codes, but I want to get a
15:03slight more intuition and context on like
15:06the people of building Warp.
15:09So I've mentioned that you all raised, I
15:11think, a Series A recently and that
15:13allows you to continue to grow.
15:15So how many people are currently in the
15:17company and how many
15:18of those are engineers?
15:20We have 16 people currently in the
15:23company and our
15:24engineering team right now is four.
15:27So we've we've kind of tried to remain
15:29small, even though we just raised a big
15:31round where we're hiring
15:32for all engineering roles.
15:34So if you're listening to this
15:36joinwarp.com/careers
15:38We like to move very fast and remain sort
15:41of nimble and kind of cut out processes.
15:44Yeah, so we've tried to remain small.
15:46We're very conscious of
15:47growing too fast, but also hiring.
15:50That is awesome. And that definitely
15:52resonates. And like for I think a
15:54contemporary example of like who has done
15:57that really well for a long time is
15:59Linear, where like their tax code
16:02equivalent is task management.
16:04And they've built an absolutely amazing,
16:08delightful experience
16:09for project management.
16:11And I think maybe you're thinking of
16:13yourself like being part of the same
16:15category of like next
16:17generational software.
16:18And the parallel I definitely want to
16:20draw here is they've remained super,
16:23super small for a very long time in
16:26regards to engineering team.
16:27And you mentioning that you're still just
16:29four people like I
16:31definitely applaud you for that.
16:32I think this allows you to just have like
16:36a velocity and agility that is hard to
16:39match when when you're growing and
16:42growing in terms of the engineering team.
16:44I think at some point that is inevitable,
16:47but like remaining small and like keeping
16:50the bar high for engineering talent, I
16:52think is definitely the way to go.
16:55So maybe you can share a little bit more
16:58on like the background of the other
17:00engineers, like when we are now drawing a
17:03bridge to Effect, which has not
17:06too many similarities with
17:08Ruby and Rails in that regard.
17:11That is like more coming from like the
17:13functional programming world, even though
17:15that is not like the core
17:16essence of Effect these days.
17:18This is where it had its origin story and
17:21still draws a lot of people to Effect.
17:24And it requires a little bit of like a
17:26entry ticket to learn a few new things.
17:30So I'm curious, like what was sort of
17:31like the catalyst event for
17:34Warp getting on board with Effect?
17:36Yeah, I guess to say a bit about our
17:39early team, I mentioned Rails.
17:41One of our other core engineers came from
17:43a huge product
17:44running on Rails and React.
17:46And our other team members have come from
17:49a big Python world, especially the guy
17:53who's good at AIs,
17:55written a lot of Python.
17:57And then the last member, I guess I can
17:58just enumerate the whole list
17:59since it's since it's small.
18:02He was a new grad, so he was actually
18:03very interested in Rust and systems
18:06programming languages.
18:07So not actually much
18:09TypeScript before we started Warp.
18:12I think that the way, if I could tell the
18:14story of how I first came across Effect
18:17was that I'm in sort of these online
18:20circles that expose me to things way out
18:24of anything I need to
18:26write B2B SaaS payroll software.
18:29And I'm sure you know a lot of these
18:31communities that they're like heavy
18:33systems programmers.
18:34You'll find some very like eccentric
18:38people writing like
18:39the craziest software.
18:41I'm very interested in
18:42like type systems in general.
18:44And I was writing a lot of random side
18:47projects in Haskell.
18:48Yeah, and I always love that experience.
18:51But I just couldn't justify for the
18:54business like starting to
18:55write something in Haskell.
18:57It would be like such a big
18:59learning curve for people.
19:00It would be like, how
19:01do we deploy this thing?
19:03How are we going to build our entire
19:05pipeline around this?
19:06I can't justify that when you're trying
19:08to just ship features.
19:10But anyway, back to how I found Effect.
19:13I think it was in these circles like some
19:15of these guys obsessed with type systems
19:18are like, why would
19:19anyone ever use TypeScript?
19:21It sucks.
19:22Like only Effect is like
19:24doing something decent with it.
19:26And I'm like, okay, like take that with a
19:28grain of salt, but
19:30file it away for later.
19:32Kind of go to the Effect docs eventually.
19:34A bit daunting like, all right, what is
19:37this thing on TypeScript?
19:39And eventually sort of through osmosis
19:42and seeing like code snippets of people,
19:44especially like the
19:44Vercel team posts a lot.
19:46Like, okay, this could be nice.
19:49And then looking for sort of some project
19:51to start it with some like
19:53some excuse to write with effects.
19:56And finally, we had some little proof of
19:59concept very isolated from our product
20:01that we were going to build.
20:03It was actually an AI browser agent.
20:06So it was automating browser actions and
20:10computer use with AI.
20:12And I was like, you know what, screw it,
20:13I'm going to use Effect for this.
20:15And that's sort of my first experience.
20:17It was very slow going.
20:18There is definitely a learning curve.
20:20And that's sort of the impetus.
20:22And I guess I can mention sort of to why
20:25I was even ready for
20:27something like Effect.
20:30We like started early on TypeScript, as I
20:34mentioned, because it was just like the
20:36easiest way to get started.
20:37You can move very fast.
20:39And it's very optimized
20:41for like happy path coding.
20:44It's like, you know, those old TVs with
20:47the antennas on top, you like hit it a
20:49bunch of times and
20:50eventually it like starts working.
20:52It's like static and you just hit it.
20:53That's how it feels like coding in
20:56TypeScript or in JavaScript without like
20:59proper result types
21:01and dependency injection.
21:02It's just like, okay, this error happens.
21:05Let me like add some
21:06conditional for that.
21:08And then like eventually like a thousand
21:10times later, you have like something that
21:12works and you're way too
21:13scared to touch it again.
21:15That's how it feels like coding in
21:16vanilla sort of TypeScript, JavaScript.
21:19So I'm like, all right, this
21:20is like just not sustainable.
21:21We have a product where, you know,
21:23everything has five or six different
21:26states it could be in, statuses.
21:28And then every and then there's like, say
21:3220 objects with 20 different statuses.
21:34Like it's just an exponential amount of
21:37different statuses things can be in.
21:39So a lot of antennas
21:40that you need to slap.
21:43Exactly.
21:43That's what I'm saying.
21:44So I'm like, I need
21:46something that can do this better.
21:47And so that's why I was like very
21:49receptive initially to Effect.
21:51So this is one analogy I make quite a bit
21:55of sort of like the sugar high versus
21:57eating vegetables, like
21:59getting building something quickly.
22:01This is like, I mean,
22:02JavaScript is like perfect at that.
22:04But then like when you like run into
22:06those problems where in production you
22:09see undefined is not a function and you
22:11have no clue where
22:12this might even happen.
22:13Maybe the the strike phrase is like, it's
22:16somewhere like some esoteric place and
22:19you're just like completely lost and easy
22:21kind of like dawns on you.
22:22Yes, I should have eaten more vegetables.
22:24I should have built
22:25this in the right way.
22:26But now to kind of like get from place
22:29A to place B where like
22:32you're currently in
22:32undefined is not a function place.
22:34And you're in that place where everything
22:36is nicely modeled like
22:38that can be quite daunting.
22:39So you've taken the plunge with the A.I.
22:42browser automation project.
22:45Can you share a little bit more of like
22:47what that looked like?
22:48What were you trying to did
22:50you build that from scratch?
22:51Did you have like an existing version
22:53that's like has worked in happy path
22:56land, but you now want to make production
22:58ready or like take me through like the
23:00adoption journey of Effect
23:02for that particular project.
23:04And how did you involve
23:05your other team members?
23:06So this project
23:08was very, very isolated.
23:09It was a from scratch product.
23:11We haven't done
23:12anything like that before.
23:13It was it was sort of R and D just kind
23:16of going out seeing
23:17if this would work.
23:18And and actually in hindsight, like that
23:21was probably not the right place to start
23:24with Effect because we were just trying
23:26to build a proof of concept.
23:28But I was like so dead set on on
23:31improving our workflows that I was trying
23:33to use this thing I wanted to use.
23:36You know, startups are great
23:37because you can just kind of choose your
23:39tech stack as you go
23:40along and try things out.
23:42You're not like constrained to other
23:44internal libraries or anything.
23:46So super excited to try it there, even
23:48though it wasn't the best fit.
23:50I was using this library called Stagehand
23:53from Browserbase that kind of
23:55integrates with different providers and
23:57and read sort of the DOM to extract
24:00actionable things in on any
24:02web page and then act upon them.
24:04So I was just kind of like wrapping
24:06functions with Effect and
24:08like seeing how it worked.
24:09Like how does this
24:10dependency injection thing work?
24:12So that's sort of how it got started.
24:13I was actually working on that
24:15project pretty much alone.
24:17And then we built out the proof of
24:19concept where like this can work, we're
24:21going to productize it later.
24:22But I need to go back
24:24to like building product.
24:25So it was sort of a decent amount of time
24:29between that experience and all right, we
24:32need to get this into our product.
24:34And I think the
24:35sort of thing that pushed me
24:36was actually hiring new people.
24:39We have this like mess of of old happy
24:42path code in some places that that needs
24:45to be like more productionized and and
24:47part of it is like an ego thing like, oh,
24:49I have to show this code to someone else.
24:51I have to like someone
24:52else has to work on this.
24:54We need to turn up before
24:56before your friends arrive.
24:57Exactly, exactly.
24:59I'm like, how can I expect like a new
25:01team member or like five members?
25:05I know the feeling this is like you want
25:06someone like it works the right way, but
25:09like you gotta you gotta clean it up now.
25:12Yes. Yeah.
25:13So that that's when we were sort of like,
25:16all right, we need a
25:17better developer experience.
25:19We need everything to be more testable,
25:22everything, all the errors enumerated.
25:24Let's like sit down and sort of if we
25:27were in an ideal world,
25:28what would our stack be?
25:30That still allowed us to move very fast
25:32and allowed people to onboard quickly and
25:35write both front end
25:36and back end very quickly.
25:37And we sort of came up with that answer
25:39and we were like, all
25:40right, let's just go for it.
25:42And just to share sort of like one
25:46anecdote I've heard from a couple of
25:48other companies who are using Effect.
25:51That is it's actually interesting that
25:53they also hired people with no prior
25:57TypeScript experience.
25:58And this was sort of like the first time
26:00really where someone went super deep on
26:02TypeScript and went right into Effect.
26:04I was like me as a Effect team member,
26:07this felt initially kind of
26:09counterintuitive because I came to Effect
26:12because I've done TypeScript for like a
26:15decade, suffering through the
26:17limitations of TypeScript.
26:19And then I saw Effect
26:21as the answer to that.
26:23But I've already learned sort of like all
26:25of like those mishabits of like holding
26:28it in this particular way that like tribe
26:32knowledge has just
26:32been passed down to you.
26:34But people outside of the TypeScript
26:37ecosystem, they've never been burdened
26:39with all of those like crafty experience
26:43like you're using this way not
26:45because it's particularly nice, but just
26:47because you have to do it this way.
26:49But if you're new to TypeScript and new
26:52to Effect, then like you're learning it
26:53the right way right away.
26:55And it's weirdly enough, it's actually
26:57easier to learn Effect if you don't have
27:00that year's worth of like using
27:03TypeScript already in
27:04this particular way.
27:06And so that really resonates now.
27:08Well, it is almost like writing or
27:11reading a new language.
27:12Like you never really use generators in
27:16like your day-to-day TypeScript.
27:19Like you'll never see
27:20that in a React app.
27:22And then the type signatures are just
27:24completely different from
27:25something you write yourself.
27:28Yeah. And I think that's the most useful
27:30mental model that you can give like a
27:32newcomer, being
27:33unburdened from like things before.
27:36Yes, the type signatures, etc.
27:38I think that's helpful to have an
27:40understanding of that.
27:41But I think this is actually one of the
27:43most elegant parts about TypeScript, how
27:46nice the inference works.
27:47But then sort of like to absorb the
27:51mental models of the concepts, etc.
27:53Like if your brain is not constantly
27:55racing of like trying to bind it to a
27:57prior TypeScript thing you've been using,
27:59but just like absorbing
28:01that in a more like free world.
28:04I think that's actually
28:06kind of works super well.
28:07And I think this seems to work super well
28:09for people with prior Rails experience.
28:12And also for that new grad you've
28:14mentioned coming more from a Rust
28:16background, since I think Effect is
28:18actually the closest thing
28:19to Rust we have in TypeScript
28:22in terms of like applying systems
28:24programming mindset
28:26and rigor to TypeScript.
28:28Yeah, I definitely agree.
28:30Going back a bit to writing Haskell,
28:32there's this meme in Haskell where if you
28:36pass the type check,
28:37then your code works.
28:39In vanilla, like JavaScript and
28:41TypeScript, I heard someone joke one time
28:43that TypeScript is a VS Code extension.
28:46And that's really funny to me because
28:48types are just suggestions there.
28:50They're not actually real guarantees.
28:52And Effect is sort of the layer that
28:54makes it feel like my
28:55type is a real thing.
28:56I can actually trust that this thing here
28:58is this thing it says it is.
29:00I go so far in writing
29:02production ready code.
29:04Yeah, so as you then like introduced
29:07Effect into like that first R&D project
29:10and then you brought it
29:11to the rest of the system,
29:13walk me through how you've like, how you
29:16cleaned up before new people joined and
29:18how did Effect step by step.
29:21How did you migrate
29:22your project step by step?
29:23I guess we started with sort of
29:26asking the question, you know, how can we
29:29do this incrementally?
29:30And the first place we sort of used it
29:33was we're using these
29:35NoSQL stores in some places.
29:38And we were like, all right, let's try to
29:40use Schema and just the general Effect
29:43dependency injection to try to more
29:46strongly type some of these NoSQL stores
29:48we're using and see if we
29:49can like parse out our data.
29:50We were using like a lot of places just,
29:54you know, let's get this basically
29:56document object and like just write as
29:59thing at the end of it.
30:01And then it's like that thing and we run
30:03into tons of issues doing that with
30:05that's that happy path coding, you know,
30:07so let's schema parse all of these.
30:09Let's like, be sure we have
30:10the things we say we have.
30:12And that sort of led us to starting to
30:14wrap our like database drivers and our
30:19various domain objects
30:20in schemas and context.
30:23And we're like, you know what, let's just
30:25like, forget that, like forget trying to
30:27like rewrite old stuff.
30:29Let's just come up with our
30:30new stack and and write it.
30:32And so we actually
30:33completely wrote a new server.
30:35It's funny the way it
30:36worked because the other sort of DX
30:38improvement we were looking to get was we
30:41wanted to write less
30:43hooks on the front end.
30:44We wanted Open API specs so that we could just
30:47generate all of our front end code.
30:49So we're looking at different ways to do
30:50that. We eventually found, you know, the
30:52Effect Platform thing.
30:54We're like, all right, let's take our
30:55existing API and write the HTTP
31:00group endpoints that
31:02match like what our API is.
31:04And then we can generate our hooks from
31:06that. And then we go deeper and we
31:08realize, oh, we don't need
31:09to generate anything.
31:11Effect can just like infer the entire
31:14HTTP client. So we'll do that.
31:16And then we're like, you know what, let's
31:19why would we rewrite the old things when
31:21we already have the hooks for them?
31:23Like, let's just actually implement our
31:25new API endpoints
31:27through the effect platform.
31:29And then so we kind of incrementally
31:31after implementing one thing in each
31:33place, we were like, you know what, like,
31:35let's just write the whole thing end to
31:37end in Effect and like start pulling in
31:39like entire flows from the legacy code
31:42into our like sort of new stack.
31:44And that's sort of how we've been going
31:46about it. We use RPC to sort of interface
31:50from our old backend
31:52to our Effect backend.
31:54And that's sort of the bridge where we
31:55need to like make a call for a new
31:57service or a new context.
31:59It is like somewhat of a friction point
32:02to add random effects in non Effect code,
32:08because you do like the run sync, you
32:10have to add the all the dependencies
32:12basically right there.
32:13And then you have to handle all the
32:14errors before you're back in like the
32:16world where you don't know anything.
32:18It's a bit more verbose, but I actually
32:20somewhat prefer it because,
32:22as we sort of adopt more and more that
32:25the sort of scope of that initial run
32:27sync just grows and grows.
32:29And then it's like, okay, now we just
32:30have everything Effect. So that's sort
32:32of how it's been going.
32:33I know that was kind of convoluted, but
32:35hopefully answers the
32:36sort of adoption path for us.
32:38No, it definitely resonates. And I think
32:41it shows sort of, I mean, there, I don't
32:42think there is like the canonical
32:45adoption experience for Effect.
32:47I think it always kind of depends on your
32:50particular pain points. That's typically
32:52what I would recommend to people when
32:54they look into Effect.
32:55I wouldn't recommend them doing one big
32:57bang migration where they don't ship any
33:01new features and just migrate everything.
33:03And that drags on for a very long time. I
33:06would rather recommend doing it
33:08incrementally where you can start it
33:11one day and like in the same day you ship
33:13the first version of Effect.
33:15And that touches just a small part of the
33:17code base, but then like you've gained
33:19sort of that incremental confidence that
33:22you can do that without maybe your
33:25colleagues even knowing.
33:27And step by step for the code that you
33:29own, you can clean it up
33:32and make it more like a home.
33:34And then over time you will realize that
33:37it can absorb a lot of
33:39the manual code you've written before.
33:42And by embracing more parts of Effect,
33:45you can delete a lot of the code.
33:47And then also there is some gluey stuff
33:50that you have while you're still sort of
33:53in the adoption process.
33:55And that's fine. Like that you don't need
33:58to ever move beyond that.
34:00But if you then start adopting even more
34:03Effect, then every like even those parts
34:06become just like seamless, like sort of
34:08the seam becomes seamless.
34:10Where you interact with Effect and then you
34:12have like a single entry point.
34:13And I think this is really like where
34:15when I went first through that, it's
34:17like, oh my gosh, this just felt so good.
34:20Like how everything feels so coherent.
34:22And the last time I had that experience,
34:24I think was like migrating a
34:26giant jQuery code base to react.
34:29And once that was completed and I could
34:32just like delete the jQuery dependency,
34:35that felt sort of like a similar step.
34:38Think back to the
34:39time when you onboarded more of your
34:43engineering colleagues and like you
34:45exposed them to Effect.
34:46how did you take them by the hand
34:48and sort of like showed them around and
34:50help them build an intuition?
34:52I probably sounded a bit like a
34:55crazy person at the time.
34:56If they hadn't heard of effect, I hired
34:59them one with prior TypeScript
35:03experience, one the new grad with none.
35:07And then basically he got a bunch of
35:09TypeScript experience.
35:11And then I sort of come to them and I'm
35:13like, this is amazing.
35:14Like we need to rewrite everything,
35:16basically like everything, you know,
35:18effect works best when
35:19it's like end to end.
35:21It has a way of just like
35:23sucking up more and more.
35:24We joke now that like, oh, another day
35:28like I was like reading through
35:29source code or like deep in the discord.
35:31And I found another primitive that that's
35:34in this library that just
35:35like works perfect for us.
35:36So side note, there's a lot of work to be
35:39done to like get a lot of these effect
35:43primitives and sub packages
35:45to have more documentation and get more
35:47people to know about.
35:48I think this this definitely resonates
35:50because Effect is such a vast
35:52ecosystem and sort of like the along
35:56the lines of the saying like that gift
35:58that keeps on giving.
35:59But I think it's all about having the
36:00right mindset since like you could with
36:03one perspective look at it as like, oh,
36:04such a vast ecosystem,
36:06so many things to learn.
36:07And you could be paralyzed by saying
36:09like, oh, this is this is too much. I
36:12won't even get started.
36:13What I think is much more helpful is like
36:17picking a few abstractions of Effect, not
36:19even bothering about the existence of the
36:22others and like starting to adopt it.
36:24And like you'll be surprised how great
36:27this will already feel.
36:28And then step by step, once you have an
36:31understanding and an intuition for how
36:33these pieces work, then
36:34you're in the right spot to.
36:35Appreciate the next abstraction and have
36:38that sort of like improve everything in
36:42the same way as if we see how other
36:44ecosystems and languages have have
36:47evolved over the years,
36:48something like React hooks.
36:51They solve particular pain
36:52points that existed before.
36:55But if they would have been introduced
36:58like that in the beginning, maybe that
37:00would have been too overwhelming. So
37:02If you fully adopted Effect throughout
37:04your system, then there's still another
37:07incremental adoption dimension where you
37:09can start refactoring things with more
37:12Effect primitives that you realize, oh,
37:15this is actually a great fit.
37:17And I think with that, you can solve
37:19about modeling your system.
37:21Right. And once you start sort of
37:23thinking in Effect, you start having
37:25these ideas like, oh, what if I wrapped
37:28this service this way or like abstracted
37:31this thing this way.
37:32And you come to realize that the
37:34ecosystem has already done that.
37:38And here's the thing that does it. And
37:39you're like, oh, this is this is actually
37:41perfect. I don't need to like even write
37:43anything. I can just use this.
37:45one example recently was
37:46just simply caching any
37:48network call like on Redis.
37:50And we were like about to write a wrapper
37:52for just calling an Effect that calls
37:56some other service and first
37:58checking the cache in Redis.
38:00And then we found the tagged requests and
38:02it's just like, oh, just add a cache key
38:04and like to provide the
38:05provide the Redis layer or whatever.
38:08And it's like, oh, these things already
38:11exist. It's back to the
38:12way Rails is sort of very opinionated.
38:15It's the way that Effect
38:17has this giant ecosystem.
38:19It's moving more towards these are the
38:21ways we should do things and it's almost
38:23even better because you can implement a
38:25layer any way you want.
38:27So it's not as opinionated. It's just you
38:30have the building blocks for what you
38:32need. It's like it's like building with
38:34Legos, but it's almost
38:35even better than that because
38:37when you build with Legos, you can't like
38:39enter in the center and rip out a piece
38:42and like replace it.
38:43But with Effect, you can you can rip out
38:45any layer and replace it with anything
38:47else at any time as long as it like
38:49matches the service.
38:50Exactly. And I think this is sort of
38:52hinting at the amazing
38:54concept of composability.
38:56And like when we say we're talking about
38:58Legos is like that we
39:00can click them together.
39:02We can compose them.
39:03and there is sort of like the like the
39:05atomic or subatomic level of like you
39:08can't get smaller than that.
39:10But everything else is kind of composed
39:12out of those. But then you have like
39:13those like more macro structures that are
39:16already useful and you can use them.
39:18But you can also at any time like kind of
39:20take take those apart and like have the
39:23little Legos that make the big Lego.
39:25And I think this is what you rarely have
39:27in those larger
39:28ecosystems like Ruby and Rails.
39:30This is where basically you get the big
39:31thing. And if it doesn't do what you
39:33want, well, bad luck.
39:35You got to roll your own from scratch.
39:37Whereas with Effect, you can very
39:38elegantly kind of take those things apart
39:41and tweak them to your liking.
39:44I guess back to your
39:46earlier question about introducing it
39:48sort of to the to the team and whether
39:50they were apprehensive.
39:51They definitely were.
39:53there's a learning curve and we're always
39:54just trying to ship as fast as possible.
39:57We have pressure from customers and
40:00product guys just to
40:02ship as fast as possible.
40:03Like, let's have this out tomorrow. So
40:06I'm coming to them and saying, learn this
40:08entirely new way to write TypeScript.
40:10Trust me, bro, it'll be worth it.
40:12And it helps to like have some examples I
40:15can point to. And I think I recall one
40:18team member of the one actually with
40:20prior TypeScript experience.
40:22He he trusted me enough to give it a try.
40:24And he said it really clicked for him
40:27when he was writing tests, actually,
40:29because he like mocked some layer or
40:32wrote a test layer for for some service.
40:35And he's like, oh, this is what I can do
40:38with this and like isolate just certain
40:41services and tests like
40:42just the core business logic.
40:44And it's super, super helpful there. But
40:47that was the moment that clicked for him.
40:48I think we've all had sort
40:50of that that moment, you know, that that
40:52is just like, oh, this is
40:53what this is capable of.
40:55This needs to be sort of
40:56everywhere on a code base.
40:57Exactly and I am considering those sort of like
41:00the superpowers of Effect. And
41:03you can also turn around those
41:04superpowers into like super tricky
41:08problems when you like those being error
41:11handling those being observability
41:13testing concurrency, etc.
41:15Like if your app doesn't need those yet,
41:18great. And like if you're in that
41:20position, like Effect
41:21might make less sense for you.
41:23But the moment you need those and even
41:26more if you combine those, then you're in
41:28a really tricky spot.
41:30Like, let's say you want to test your
41:32app. OK, that's hard. But now you want to
41:35test your app for particularly tricky
41:38error scenarios that you don't know how
41:41to kind of like induce into your system.
41:44like trying to do that without Effect,
41:46then you basically just spend
41:47like so much time building your app and
41:49you spend so much time just building this
41:51crazy mocking system that like tries to
41:54simulate everything.
41:55And you probably feel like, do we really
41:57need that test? And just this
42:00incentivizes good software engineering.
42:02And I think this is
42:03what Effect really flips.
42:05There's always a breaking point for
42:06someone's error
42:07handling for someone's testing.
42:09And I think you just need to like
42:11walk someone to that problem. And then I
42:15think it like it starts to click.
42:17Yeah, exactly. This
42:18composability, interestingly, has
42:19actually been great
42:20specifically for payments.
42:23You have like all these different payment
42:25rails and and all these different like
42:27providers and you can just write one
42:29common interface and the usage
42:32code doesn't care about what
42:34rails the payments going on.
42:35You can change the rails. You can
42:37dynamically route the payment rails just
42:39by like providing a different service,
42:42providing different layers.
42:43So it's been super interesting to see
42:45that the patterns we
42:46can develop this way.
42:48Can we shift gears a little bit and talk
42:50a bit more about like the architecture of
42:53your system? So like if I'm going to
42:57joinwarp.com, like there's a website and
43:00probably next to the website, there's
43:02also some sort of like dashboards that
43:04your customers are using.
43:06So that dashboard, I suppose you're using
43:09something like Next.js for that. So that
43:11run, there's a front end at minimum.
43:14But that front end is then talking to
43:17some sort of like API tier. So we have
43:20that as well. But I'm curious, what else
43:23is there? Is there like you have an API
43:26level, but then you
43:28probably also have places.
43:29Maybe you have cron jobs. Maybe you have
43:31like other things you've mentioned like
43:33that AI agent browser setup, etc. So I'm
43:37not sure whether you're thinking about
43:39this as like
43:39microservices or majestic monolith.
43:43But like maybe you can explain a little
43:45bit of like how that imagine we're at a
43:48whiteboard and you're drawing the system
43:50architecture. Like maybe
43:51you can do that in words.
43:53We definitely prefer to keep things
43:56as simple as possible. We're a team of
43:58four and we don't have high requirements
44:01for like latency on requests.
44:04We have requirements for reliability
44:08being being payment software.
44:09another thing is we don't have a high
44:11total number of like daily active users.
44:15So our compute requirements are actually
44:18interestingly somewhat low. That being
44:21said, the way we started was on Next.js
44:24and almost everything was
44:26just in a Next.js API route.
44:28That grew honestly way past its
44:30usefulness, but that's the way things go
44:32at startups. You just pick a stack that's
44:35been the theme of this whole interview.
44:36You pick a stack, you go too far with it.
44:39It doesn't meet your needs.
44:40And also just as a side note, it's almost
44:43diametrically opposed to what you've been
44:46building before with the social network
44:49where like it's like the latency really
44:52matters, etc. And like it now you've like
44:55completely flipped all of
44:56your like tech trade offs.
44:58Yeah, that one was fun to build because
45:00it was tons of caching, streaming, like
45:02all the stuff that needed to scale very
45:05quickly when there was a usage upburst
45:09for whatever reason.
45:10And now our usage patterns are a lot more
45:13predictable if you think about it. People
45:15log in to see their paycheck twice a
45:17month. We just need to like get that part
45:19right and then make sure
45:21all the payments are right.
45:22So I guess to say more about the
45:24infrastructure, we're running containers.
45:26We have one monolith pretty much that
45:28handles all of our API routes, jobs, even
45:33like yeah asynchronous jobs, cron jobs
45:36and that's our effect platform API.
45:39And then we do have like separate
45:40services, for example, for the browser
45:43agent thing, we have a slack bot that's
45:46separate. That's like sufficiently
45:47different to necessitate another service.
45:50But all that to say pretty simple, we
45:53like to work in a monolith.
45:55And is that monolith currently deployed
45:57in a single place or are you already
46:00running that in a distributed setting
46:02that maybe you have one running in the
46:04East Coast, one running on the West
46:05Coast, wherever your customers are?
46:08Yeah, we just have one running on the
46:10East Coast that's next to our database.
46:12Got it. So maybe at some point, there
46:15might be the day on the horizon where you
46:18need to like go multi data center, which
46:21I'm sure will upend a whole bunch of like
46:25so far trade offs you
46:26didn't have to make yet.
46:27But this is another thing where maybe
46:30I'll invite you back to the podcast to
46:34see whether Effect Workflows could help
46:36with that. Since this is
46:37exactly what this is about.
46:39Kind of like to like going with a
46:41monolith and just deploying that monolith
46:44to a single place is the simplest you can
46:47go with. And I love simplicity.
46:49But at some point, you might need to go
46:52beyond that and then to still go for
46:54maximum simplicity. I think this is where
46:57Effect will be another gift will be
47:00receiving from Effects is like Effect
47:02workflows that try to help
47:04exactly with the sort of thing.
47:05But we'll talk more about that in the
47:07future. Yeah, I hope to make
47:09it there. I hope to have these problems.
47:11but maybe going back to that, so
47:13you mentioned like you're running this
47:14right now in a container. You mentioned
47:16that you run some sort of like jobs,
47:19background processes, etc.
47:21How do you orchestrate that right now? Is
47:23that still mostly driven through what are
47:25the entry points are those entry points
47:28are requests. Those entry
47:29points might be cron jobs.
47:32Anything else that sort of serves as an
47:34entry point to kick off code that runs?
47:37Yeah, so we have the HTTP like sort of
47:41restful API that that kicks off code
47:43where we actually wrapped.
47:43We actually wrapped BullMQ with
47:46some Effect helpers so that's the
47:48way we're kind of queuing up jobs and
47:51processing them. We're still running that
47:53just on one server, all the
47:54handlers. We could distribute that
47:56somewhat simply.
47:56And then yeah, there's also RPC endpoints
47:59just for calling more service type
48:01functions from from our legacy back end.
48:04that's pretty much it.
48:05I guess to mention cron we can
48:08queue like cron type jobs in in our
48:12BullMQ so we're not officially using like
48:14cron jobs, but it's it's
48:16you know daily scheduled jobs.
48:18Got it. Can you share a bit more about
48:20sort of like the DevOps lifecycle things
48:23that that you're dealing with and how
48:27you're using Effect for that
48:29part of the picture as well?
48:30One thing I didn't mention
48:31is that we're using bun in in our
48:34container runtime. So that's
48:36been fun effect pretty much instructs
48:38that away. So it's it's no different than
48:40using it in node other than we get to say
48:43we're running on bun and and
48:44it's it's fun a bit faster.
48:46There are some bun
48:47features that that we like.
48:48Yeah, I guess we're we're fully automated
48:50like deployments. We just you know, build
48:53the container in a GitHub action with bun
48:55and PNPM and then push it to our
48:58like ECS cluster on running on AWS.
49:01Got it. Speaking of sort of like the
49:03monolith and bun approach a friend of
49:06mine has been working at Midjourney and
49:10I think Midjourney actually has also
49:12embraced the sort of architecture and
49:14deployment architecture where they have
49:17like one big machine where they're
49:20running their monolith through bun and I
49:22think they call it the mother bun.
49:24So just a little fun fun side note here.
49:27But speaking of Midjourney and therefore
49:30AI, you mentioned initially that one
49:32theme that you're currently also spending
49:35quite a lot of time on is automating
49:37things further with AI. So maybe we can
49:41pivot the conversation a bit in that
49:43direction. Do you want to give an
49:45overview of like what that means and then
49:47diving closer into that?
49:49Definitely. The way I think about AI and our product
49:52is sort of two
49:54separate kind of verticals.
49:56We are a payments product we, you know,
49:59remit taxes, we have to know all the
50:01taxes and we have to get those right. So
50:04you think that plus AI is probably a
50:06recipe for disaster.
50:07But I think there are there are sort of
50:08two ways we we think about it. One is the
50:11customer facing way, which is, you know,
50:13we've built this wonderful
50:14platform for people to use.
50:17How can we make AI to one make that
50:21easier to use and two, I think one common
50:24theme that's going on right now is just
50:26meeting customers where they are, which,
50:28for many means building slack bot.
50:30Chat interfaces, etc. So how can AI
50:34actually be the bridge between our end
50:36users and our products in a way that's
50:38like very safe and human in the loop and
50:41you know we're not triggering payments
50:43for people that are that are approved,
50:45but we can actually use our
50:46product with natural language.
50:48And I guess when I say AI here, I'm
50:50talking about LLMs specifically.
50:52And then sort of the other way we're
50:54thinking about it is automating process
50:56heavy workflows sort of on the back end,
50:59which is, you know, what if an
51:01AI can file taxes, what if an AI can like
51:05read your tax reports and, you know,
51:09generate insights and and go and and sort
51:12of do the things that need to be done.
51:14And these are things that, in
51:16the pre 2023 era, you might have needed
51:20an army of employees or contractors to
51:22like, go through these, you know,
51:25convoluted .gov websites and
51:27click through these things.
51:28But we're sort of asking the question,
51:30you know, what if, what if a person
51:31doesn't actually have to do that.
51:33So those are sort of the different
51:34ways we're sort of thinking about it.
51:36Got it. That that is super helpful. So in
51:39regards to the the latter,
51:41automating those
51:42various like manual processes.
51:44When you mentioned that currently work is
51:4616 people, 4 of them being engineers, I
51:49suppose, like a big chunk of the other
51:52employees are still doing that sort of
51:55like making the entire
51:57thing happen behind the scenes.
52:00But there is, as you scale up your
52:02customers, you would need to scale up the
52:05employees. So you want to like automate
52:08as much as possible.
52:10And this is where AI like is helpful.
52:12Yeah, exactly. The economics of it, I
52:16mean, is that, you know, we have to scale
52:18our team somewhat linearly with the
52:20number of customers we have.
52:22But with AI, you can presumably pay
52:25pennies for things that you'd have to
52:27hire a bunch of people for.
52:29So we're exploring
52:30different different ways to do that.
52:32Got it. And now it's like a great
52:34opportunities for your existing employees
52:36who've been doing that so far, like help
52:38in that automation process
52:40as they're the domain experts.
52:42And yeah, that sounds fascinating. It
52:44gets us full circle back to the initial
52:46point of like we can be thankful to
52:48you like doing that.
52:50And now it's actually super fun for the
52:53people who were the domain experts that
52:55they can now start being
52:57included in the automation process.
52:59So that makes a lot of sense. And I think
53:02that's a whole different topic of what it
53:05means to do that automation.
53:08And there's like a lot of like just from
53:10my own experiments and like work on AI
53:13driven things. There's like so many
53:16things that can just go wrong.
53:17I mean, if you're just like as a human
53:19navigating websites, like things just
53:22rarely are going
53:24as they as they should.
53:26There's like a downtime. There's like
53:28whatever like a page just
53:30reloads without you triggering it.
53:33There's just so many unpredictable things
53:36or sometimes they don't use HTML selects
53:40and you know, reading the DOM, you have
53:42no idea what to like there are
53:44accessibility issues that
53:45that an AI can run into.
53:47There are so so many things. Yeah. So
53:50this is it's whole
53:51different kind of words.
53:53And like honestly, it becomes like a
53:55whole different profession of like how to
53:58how to build systems that like can
54:01automate these things
54:02that we have in mind.
54:04But maybe we focus a little bit more on
54:06the first part you've mentioned where
54:09you're like where you meet people where
54:11they are and like expose sort of like
54:13those more AI native interfaces to them.
54:16Are you also building those systems with
54:18Effect and maybe you can also share a
54:20bit more of like how those are built
54:22which of the Effect's
54:24primitives they're using.
54:26Yeah, we are using Effect for it.
54:28We haven't actually
54:30used the Effect AI thing.
54:32I have wanted to use that but I guess our
54:35team member who's doing it is it like I
54:37said came from the Python world and it's
54:39very like fast iteration cycles.
54:42He was kind of fighting the learning
54:45curve of learning
54:46effect versus trying to get features out.
54:48So we haven't explored that specific
54:51primitive too much. We are using Effect
54:53sort of in the same way we've used
54:55we've just wrapped like the providers.
54:58we're only using one LLM right now
55:00which which I'll refrain from
55:02naming. But you could guess.
55:04Yeah, sort of the same way just just end
55:06to end like wrapping workflows. There's
55:10very much human in the loop sort of
55:12things and we have to ask on a lot of
55:14workflows like for
55:16confirmation from the user.
55:17So there's these like very stateful
55:19flows. So we're actually using sort of
55:22Effect and TypeScript more generally to
55:25kind of pick up these workflows where
55:26they left off and write
55:28like these stateful flows.
55:30Got it. That makes a lot of sense. And I
55:32think it's always like a good judgment
55:34call to see like hey is this is using
55:38Effect here like today. Is that solving
55:41a problem we have or would it potentially
55:44if I pay that learning cost is worthwhile
55:48paying that today or should
55:50I pay it in two months from now when I
55:53have more acute problems.
55:55that's always a good
55:56question to ask and I think that starts
55:59adding up but rest assured that Effect AI
56:02has become a lot more polished and I use
56:06it relentlessly in many
56:08projects and it's an absolute joy.
56:11Oh, I'll have to explore it deeper. Yeah,
56:14like you mentioned, it's hard to justify
56:16when one the person doesn't know it and
56:19two when you don't know what your data is
56:22going to end up looking like and you
56:24don't know if the
56:25project will even survive.
56:27So there is there is this. You know back
56:29and forth between like is the
56:31learning curve worth it
56:32versus I need to ship features.
56:34Yeah, so maybe looking a little bit more
56:37into the future. What are your hopes for
56:41Effect as an ecosystem and what are your
56:44plans for Warp from
56:46engineering perspective.
56:47Good question. I think I'm I've been
56:50super happy with the stuff we're
56:52building. It's been like such a
56:53refreshing experience building the new
56:56way that whenever I'm like digging deep
56:58into legacy code. I'm just like upset in general.
57:02I'm like ashamed of what I've what I've
57:05written in the past in some ways. So I'm
57:08super excited. I'm very excited for a lot
57:10of the things that are marked
57:12experimental to just be like
57:14production ready, so to speak.
57:16Super excited for more things like the AI
57:18package and and also like I mentioned. I
57:20think there's so many opportunities to
57:23get a lot of the ecosystem in better like
57:26documentation states. There are so many
57:28like discord threads with gems that you
57:32know the the person coming to Effect for
57:34the first time will never see for the
57:36thing that they need
57:37I think I'm excited for it to be in more
57:40of the LLM training data. I've seen a lot of.
57:44They spin their wheels because
57:45they don't know the syntax or
57:47whatever. They don't know a specific
57:49diagnostic error. The LSP extension helps
57:51a lot with that. So really, I'm just
57:54excited for it to hit the mainstream more
57:55and and I'd like to you know do anything
57:58I can to support that.
57:59There's a lot of
58:00opportunities for educational content. I
58:02see a lot of your team to their credit.
58:04posting like animations and
58:07different things. So I'm super excited
58:09for the direction it's going and I think
58:11the the Effect team has been great and a
58:14lot of the projects I see written in it
58:16are really cool. I think a lot of a lot
58:17of people I respect are writing it.
58:19And that's sort of
58:21reason enough to try it.
58:23I couldn't agree more. Thank you so much
58:25for sharing your own experience with
58:28Effect today and sharing your
58:30super interesting story of like how
58:32you've come to to co-found Warp. I
58:35think it's very inspiring for the
58:37audience to to show like how with how a
58:39few engineers you
58:41can build like a global system that that
58:44solves like really material problems that
58:47that's that's exactly what Effect is
58:48built for and it's very cool to see that
58:52is working well for you.
58:53Yeah, we're we're super happy with
58:55how it's turning out.
58:56And if if anyone listening wants the
58:59write Effect, come come join Warp.
59:01Please do. Yeah, we're going to put the
59:03link in the in the show notes and yeah,
59:06Adam, thank you so much for taking the
59:08time today and sharing your story.
59:10Yeah, it was great to join. Thank you so
59:12much for having me. Hopefully
59:13we can do it again sometime.
59:14That sounds great. All right.
59:16Thank you for listening to the
59:17Cause & Effect Podcast.
59:19If you've enjoyed this episode, please
59:21subscribe, leave a review
59:22and share it with your friends.
59:24If you haven't done so already, you can
59:26join our Discord community.
59:28And if you have any questions, feedback
59:30or suggestions about this episode or
59:32about Effect in general,
59:34don't hesitate to get in touch.
59:36See you in the next episode.