Hello and welcome back to APIs You Won't Hate.
I am
mike Biko, one of the co-founders of APIs You Won't Hate here
sitting down for a chat with my new friend, Manu ing from Anvil.
Manu, thanks for joining today.
Why don't you tell me a little bit about yourself,
and I'd love to hear the elevator pitch for Anvil too.
Awesome.
Thanks for having me on the podcast today.
Mike, it's.
It's always a pleasure to do these.
So a little bit about myself.
Like Mike, Mike mentioned my name's Span ing.
I am a founder, the founder of Anvil, and prior to that I worked as a
software engineer for many years.
So previously I had worked at companies like Dropbox Style Pad Flexport, and
then also a small company called Loom.
Not the video recording one that everybody knows about, but it, they did own loom.com
and then that was acquired into Dropbox.
So been in the startup space for quite some time.
My background that kind of led me to Anvil was both personal and professional.
I will say in my personal life I was just, dealing with adult stuff,
like applying for a mortgage and getting infinite numbers of PDFs to
fill out that I had to then send.
Over email to bankers so that I could get a quote for a mortgage rate.
So that was painful.
And then in my professional life working at Dropbox, there was obviously
a lot of documents at Flexport.
What you don't realize is that most shipping is just generating
documents along the way with some data that you have.
Flexport system was essentially a system of record for the data
and it would generate the correct documents as your shipment, cross
borders and got onto different ships.
And every time there was a PDF that needed to be created somebody had to hand code
a template of that PDF in HTML, and then we'd render it and then generate the pdf.
So that's why we created Anvil.
Anvil is, frankly speaking the.
Easiest way to build software for documents, whether that's generating PDFs,
filling out PDFs, collecting e-signatures, or the entire document process where you
gotta collect information, generate a certain set of documents based on some
rules, and send it through E-signature.
And the nice thing is that Anvil's completely embeddable white labeled
and has a very robust API, which is why we're on the show today.
right on.
Lots to get into there.
Really interesting.
I know Flexport does a lot of
Wild logistics stuff.
I guess it totally makes sense that you're generating PDFs left
and right 'cause there's bills of record the whole way through for
shipping that are really important.
That's fascinating.
So you were,
I guess in, in the world before Anvil existed,
I'd imagine you felt the pain of
Those PDFs in one way or the other.
What was the thing that made you go
Hey, like I'm a smart engineer, I should really dive into trying
to make this a better thing.
Smart engineer might be an overstatement.
I was an engineer.
Fair enough.
Yeah.
I've met very many engineers that are much smarter than I am.
Let's put it that way.
I think it was just, I knew I wanted to work on my own startup,
my own project at some point.
So that was always in the cards for me.
I had been a part of many startups before starting Anvil, right?
Like Dialpad, I was like number seven Lu I was number seven as well.
And then Flexport and Dropbox was there during the growth stage
is when it was like 500 people.
So gotta see that spectrum.
Sure.
so that's maybe the starting point.
And then I was really looking for a problem space that I felt was both.
Large enough and painful enough, and also impactful enough that really
would be something I'd be willing to commit to for the next, five,
10, however many years to tackle.
So I think those are probably the two driving forces.
And then it was just really happenstance, like I was going through a period of my
life when I was starting a company, where I just had a lot of documents to do.
Like I was doing all the life stuff that you don't do when you're
working, 'cause you put it off.
And so it just was like an aha moment where everything clicked together.
I think hindsight's 2020 always, but
Sure.
I.
In my experience, I've been lucky to meet a lot of founders
by way of podcast interview and,
having friends
With similar,
Mental states to my own, who found themselves in
The founder seat one way or the other.
And
There are a
Few buckets that founders tend to fall into.
And,
There's always something interesting talking to people who've like really
felt the problem that they're trying to solve before, before solving it
because it's so much more deeply.
Like
You feel it to your core, but you know when it's success because
past you would've loved this,
To an extent.
Yeah.
That's really cool.
I,
I'd imagine a lot of the folks listening to this, I'd imagine virtually everyone
on Earth has touched A PDF in some way.
I'd imagine some of the people listening to this have tried to do what you
described before with PDF templates or pulling structured data from a document or
putting structured data into a document.
my experience
Is somewhat limited.
But I can tell you that,
I still have nightmares about trying to deal with some of the
Biggest company in the world, like
Their APIs and tools for building PDFs.
Tell me about
What the process is like.
What's the hello world for someone,
Onboarding with Anv look like
Yeah.
So typically the first thing you do is just sign up.
You go grab a PDF form that you're trying to automate.
So typically it's a blank form, right?
We actually ask you to upload blank forms.
And you upload it into Anvil.
Anvil will automatically run through the PDF and use computer vision
to find all the blanks for you.
Does a pretty good job.
I'll say not perfect, but does a very good job.
And then we'll run it through an LLM to label and tag all the fields for you.
So it'll do things like.
Give each field a readable name.
It'll give each field a specific type.
So we have address types, social security number types, short text, long text,
all that kind of stuff, check boxes.
And it will also associate the fields together.
So address fields typically are compound fields.
There's line one, line two, city, state, zip.
Anvil will associate those together so that when you go to
populate this PDF, it's like a data structure that makes sense.
It's not just a bunch of fields that are not interrelated,
even though they should be.
So that's pretty much it.
If you have a schema already that you're trying to map to A PDF, you can pass
along the keys and we will also try to associate your schema to specific
fields on the PDF automatically.
That just makes it easy for you to normalize data across multiple documents.
And then you make an API request.
We automatically generate a restful endpoint for you to fill this out.
There's a payload of data that gets auto generated and you just make a request
to that endpoint with your API key.
And you should receive a filled out PDF.
I'm a little,
Gobsmacked right now.
Having had tried to build something on,
DocuSign,
APIs in particular, like
The complexity that large companies can inject into a process like
this can be pretty mind numbing.
And it's hard to see when you're that big.
I've worked for great big corporations, I've worked for
n equals one corporations, and,
No fault in either direction.
But like that, what you've just described sounds like the dream I needed,
When I was working on this the last time.
And
It's a really interesting tool.
Like that is something that I think fundamentally, anyone whose business
has some overlap into the real world where a printer might be involved,
Can use this
And has some value for it.
I'll actually maybe give you an example from my world.
Outside of APIs, we won't hate or run a startup called Craftwork.
We're a vertically integrated home painting company, and one of the things
we deal with a lot is we get invoices and receipts from a paint supplier.
So a paint store.
We go and order paint for a project.
It'll have
The associated.
Project that it's with.
So it might be like Mike's house,
And here's the 10 gallons of paint we ordered and the four paint
brushes and the primer and all the other stuff that's needed there.
Those per company are generally pretty standardized.
However, that's like another form of oddly unstructured data in that
it's an invoice that can have,
One or 10 or 50 rows.
And I don't necessarily have, let's call it like
A blank version of that.
In, in your world, is that
Should I go
And find a way to regenerate that sort of template with a blank?
Is there a story for that with Anvil as well?
Is that something that,
Is a use case you're interested in?
Yeah, absolutely.
I think when it comes to extracting data out of PDFs, we
don't actually do that today.
Our thesis has always been, and I said we don't actually do that today.
Actually, I don't know if we'll ever do it, let's be honest.
Our thesis has always been that we already live in a world
of a lot of structured data.
And instead of destructuring it and putting it into a PDF, and then
having somebody pull that unstructured data out of a PDF with OCR and lLM
text extraction methods it should just be structured the whole time.
Like the PDF becomes an artifact of the process.
And so one way that I would think about your problem in this ideal future is
when an invoice is generated as a PDF the actual data that went into generating
the PDF should be attached in the PDF as metadata that is structured.
And so if you're like receiving the PDF instead of parsing it out with computer
vision and whatnot and overcomplicating it with this Rube Goldberg machine that
you've created you just go read the data out and parse it into your system.
And so this is actually like a hack week project that I did, which was I really
wanted to take that structured data.
Concept to the next level with PDFs.
And Anvil does a lot with collecting data.
We have a workflow tool, we call it.
It collects data on the front end with a web form.
It's dynamic.
There's lots of logic, and then it generates the corresponding set
of documents that you need, right?
But really what I want to do is embed all that data as metadata
alongside as the PDF, so that anybody could go pull it out if they knew
it was a anvil generated document.
Or hopefully this becomes like an open standard, and then PDFs
literally become packets, right?
It's like it's, there's like the internet packets and then there's
like the packet that like the average, normal lay person would think of.
It's like a packet of PDFs that then get passed around and the
data can just be extracted.
So that, that's our take on it.
But we live in a messy world and there is a lot of a lot of.
Unstructured data living in PDFs today, and I think there's lots of really
great companies that are tackling it.
From the, the legacy OCR companies and RPA companies to the newer crop of 'em
that came along in this gen AI world.
The idea that A PDF might have structured data embedded in
it right now makes me wanna go
Dive into my hex editor
And figure out what I've been missing this whole time.
Like genuinely, that's never crossed my mind
That's even possible
they, the funny thing is they don't, most of them do
Yeah.
it was really, actually, I, as far as I know, nobody, the, all of the
metadata that gets embedded into the PDF is not the data that's on the PDF.
It's it's oh, this person signed the document.
It's that kind of information.
But why not take it a step further?
I don't understand why nobody's really done it that way, but
That's
No different than putting an image in a document.
That's crazy.
That's such a good idea.
I really like that.
You also mentioned documents,
Signing as well.
That's something that you serve.
So it feels like you've got a
Pretty complete picture for
Populate this thing and then go ask for a signature.
Is that right?
Yeah, absolutely.
We found that was like a very natural point for Anvil to move towards after
building the first version of Anvil.
We really think of paperwork as.
Both a mechanism for data transport, like moving data between individuals and
organizations, but also a mechanism for describing a business process, right?
A lot of times a business operates on a set of documents and they
have to be completed in a certain manner, in a certain order.
And that essentially is a codification of what that company does and
people leave, people come, but like the process stays the same.
Yeah.
It sounds like you've been through a few different phases.
I don't know if you mentioned before, how old is the company?
We're about seven and a half years so been around for a hot second.
Back to the statement earlier about something I wanted to work on for five 10
or maybe even longer in terms of years.
Yeah.
I'm curious then, like
You've evolved over the past seven years.
What did your first crop of customers look like and how did you find them?
And then what do they look like now and
How has that changed?
yeah.
Our first crop of customers we were really targeting non-technical people.
The whole premise was, Hey, we're gonna create a set of tools.
We actually, so we actually built the workflow tool first.
A set of tools that where you can take documents.
And upload it into Anvil and Anvil, then automatically create an online
form for you that you can then share with people to collect the data.
So the premise was TurboTax, anything.
So our first customer was actually they're a great customer,
still a customer of ours.
First Ascent.
They're now part of geo wealth.
They are a giant, kinda like wealth management.
Back office firms.
So wealth advisors would choose them to manage all the documents and
paperwork and they would handle the account opening documents, they would
handle the transition, all that stuff.
As well as like investment strategies and stuff like that.
That's, that was our first customer.
We effectively built Anvil around their use case.
They were like a design partner, which was.
Honestly a really lucky first experience, right?
There was just so much about the way paperwork works and the way companies
manage documents that, was so much more complicated than what we had anticipated.
I think the most telling thing for me is like there's just a
lot of tribal knowledge that lives in individual's heads that.
If you're trying to codify it and translate it into a workflow you really
need to like, pull it out of 'em.
Oftentimes they don't even realize it's tribal knowledge and because
it was such a complex use case, we actually built a pretty robust system.
Fast forward a couple years, what we realized was.
A lot of our friends were building companies in these legacy industries and
they were running into this problem where they had to generate documents and they
kept coming to us asking us for an API.
So we just decided to productionize our own internal APIs, expose
'em, make it easy for kinda like technology customers to use us.
And nowadays the vast majority of our customers are actually
like early to growth sage technology customers that find us.
Read our APIs may maybe the lms the agents read our APIs and then
implements us into their system.
So yeah, we're pretty deeply embedded into organizations and
we generally power like a pretty important stack and their business.
Yeah.
I will say, yeah, definitely.
As someone,
Building tools for a old industry that's a early to growth stage
company, I think that's like.
I can draw a lot of circles around things I need that are document driven right now.
It's a really interesting problem to solve.
And I can imagine many types of companies that would be into that.
I'm curious what you can tell me about how the software is built.
So from architecture to,
the types of engineers that work for you.
What are, how are you building this?
And,
I dunno, what does your team look like?
Yeah.
So from a technology stack perspective, it's a pretty standard stack.
It's no js.
GraphQL endpoints and react on the front end.
We also have a fairly robust like PDF library that we it's an open
source library that we've then wrapped in this nice web experience.
So there's a lot, a fair amount of Java in our code as well.
For better or worse, and.
Yeah so that's the joke is always oh, it makes sense that the
ultimate enterprise file format is also written in the ultimate
enterprise language, which is Java.
Of course.
And so that's the stack.
In terms of our team, we're a very lean team.
We're a team of seven and it's about half engineering and.
Half non-engineering.
Everybody's fairly technical, I will say on our team.
And I say half engineering 'cause I count myself as half an engineer,
so that makes it exactly half.
And yeah and so it's, we run pretty lean.
The nice thing is our product is, generally speaking, very self-serve.
We tried a heavy sales motion early on, but just given our ICP, which
is engineers and product people.
didn't want to get on sales calls.
We just, they just wanted to have access to the docks.
They wanted to have a dev sandbox.
They wanted to kick the tires.
And that's how a lot of our customers come to us.
They start paying us 5 cents, 10 cents, a hundred dollars, $2,000 a
month, and then it just becomes like a real, it becomes a real account.
Yeah.
Yeah,
I,
Am guilty of diving into your docs and looking at things,
as I've been like preparing for this interview.
And,
A few things stood out to me that
are very bright green signals for me as a developer is, I'll start by saying that
if you're listening to this podcast, you should go check out Anvil's docs pages.
'cause they're so well organized.
They're beautiful, they're like in
Thought out.
They have nice API reference.
It's like whoever worked on those, give them a high five for me.
That's,
What I would say is do that and then think of any other PDF, like API you can
think of and go look at the difference.
And
As an engineer, I feel like you can feel the difference.
If you're selling to engineers, in my eyes, that sells itself.
I've, I'm also like really happy to see that,
Your pricing is pretty transparent.
Do you wanna talk a little bit about the pricing strategy?
Yeah, absolutely.
It is pretty much pay as you go.
It's 10 cents A PDF generation.
It's a dollar 50 for a completed signature packet.
And I say completed because.
All of the other, or not all, but 99% of the other e-sign providers,
they charge you on send regardless of if the signatures were completed.
And so we really want to align value there.
And then it's a dollar for a workflow submission.
So a workflow is a web form that can be pretty complex or multiple web
forms that then populate multiple PDFs.
We do also have some kind of like platform fee type fee pricing.
Specifically if you want like white labeling or some high, more advanced
features, those are a monthly platform fee or an annual platform fee.
And then enterprise is similar.
It's a larger platform fee.
You have more advanced features, you get more support, and then of course, as usage
scales, you're able to buy discounted.
Usage.
So overall we want to scale with you.
We wanna make it easy for you to start and not pay a bunch up front, but
if you do start using us a lot, we don't want to be nickel and dimming
you at retail prices, essentially.
What I like about that is,
It's predictable.
If you can look at that and understand how it fits into your
world as a team, building something,
But also accessible enough,
If I want to test it and see if,
My first a hundred documents,
Makes sense and work and fits my team's use case, that's
not a insurmountable thing,
The first a hundred documents will actually be free.
'cause when you plop on a credit card, we give you a bunch of
free credit for production usage.
So I believe it's don't quote me on this.
I believe it's a thousand PDF generations and.
Like 50 workflows or 50 signatures.
I'll have to double check, but it is pretty generous.
We do want you to I think we want you to build as a developer and use
the dev keys and all that stuff, and that's pretty much the full experience.
You get access to pretty much everything When you flip into production, we remove
the watermarks and stuff like that.
We do want to give you enough credit to actually.
Run it into production in a meaningful way so that you have confidence that you
can build your business on top of this.
Yeah, I like that too.
I walked right into
Your free tier as well.
I,
Promise I
Didn't try to do that, but
That's true.
And so from what I remember, looking through your docs,
You are GraphQL and rest endpoint
Driven, right?
So there's like
Our API,
Homies listening to the podcast will be really interested in what that all,
Looks like.
Do you have,
is it,
Primarily like rest endpoints
In GraphQL?
Do you have,
Client SDKs in, written in,
Java, whatever c
Node languages Or is it,
Or documentation around
Send a request that looks like this and this is what will happen.
Yeah.
So we do have client sks that we've written and we publish.
They are, I believe there's a JavaScript one, a C one, there's a Python one.
And we generally try to be pretty good about maintaining them.
Occasionally we do get some people writing in and then we dive in there and go fix
it, and we do ask if somebody has a fix, please feel free to open up pull request.
So we do have a lot of pre-written libraries.
They're mostly just like client wrappers.
Our API is pretty hopefully pretty, pretty simple to understand and integrate with.
And so I think that.
If you're just making web requests it's pretty easy.
The client libraries do nice things like handle multi-part uploads for
you if you're uploading a large PDF to be templatized or handle,
like automatically handle rate limiting four, two nines for you.
And using your encryption keys and stuff like that.
So it's really just like nice helper functions to, to get you started faster.
One of the other things I wanted to mention too is you have quite
A broad list of like open source things published on Anil's,
GitHub, which is really cool to see.
And also nice that
You're,
Open to and willing to like, accept community driven,
Changes and whatnot.
Especially,
Keeping up with lots of languages can be a challenge and,
getting the, like developer flavored change
Is often.
Really useful, especially,
If it's like not your specific native language,
Yeah, absolutely.
Absolutely.
And I'll say, actually just a quick call out.
If anybody out there is looking for a documentation reference docs generation
system for GraphQL check out spectacle, that's S-P-E-C-T-A-Q-L that is the
system we use and we op, we open source for generating our reference docs for
very cool.
It was a fork from a previous project that kind of got abandoned and we updated it.
And yeah.
Now whenever we push a new endpoint or change something it just
automatically compiles and creates a new reference stocks for our endpoints.
I will make sure
That shows up in the show notes.
So if you're listening to this, you can scroll down to the description of
your podcast and get right to that too.
Can you tell me like
Where your team is headed?
What are the kinds of problems you're looking at next?
Oh man.
So many.
I think there's one to start maybe revisiting the pricing question earlier.
One thing we did last year was.
Make any usage of Anvil from our online experience free.
The goal is really to make Anvil accessible to
non-technical people as well.
So your ops team can send out a signature packet and have that be free.
And so that kind of plays into what we're thinking about in 2026,
which is we want to bring anvil to places that people do work.
And this is I think, a pretty strong counter position
against other e-sign providers.
Other e-sign providers think of themselves as the platform and then
say, Hey, come to us and we will be your one place to manage documents.
And the fact of the matter is like nobody's working out of DocuSign.
They're working out of Salesforce, they're working out of HubSpot.
And so what Anvil's trying to do is make it so they can connect
Anvil to your Salesforce account.
And then from within Salesforce, let's say you can just say, generate us a sales
contract and automatically generates it.
You review it with our embedded components all within Salesforce,
and then send out for signature.
So we wanna do this for Salesforce, HubSpot, all of these like touch points
where teams generally get work done.
And a big one of, for the, for that in the, forward looking
is really MCP UI apps, right?
Yeah, sure.
chat, GPT, Claude Cowork where somebody can say, I need to get this
document signed, upload an anvil's system automatically tags and labels.
And they say here's a payload of data.
Go fill it out.
Send it out for signature.
That's one aspect.
The flip side of that is how do we prevent agents from just randomly
signing a bunch of stuff like we need to know it's a human.
So we got some pretty fun stuff fun projects up our sleeves to create
a frictionless way to identify an individual as a human, not an agent.
More on that to come, but that's something we're working on
probably in, in Q1, Q2 this year.
And I think we'll be the first ones to really tackle that problem beyond like a.
Hey, set up a video camera, a video call and notarize and have
a notary or do one of those like crazy face scan things, right?
That nobody seems to like doing.
So that's another one.
And then the last project, which is the bid project is goes back to
how thinks of ourselves as a data company, not so much a PDF company.
Like the data, just the PDF is an artifact and it just happens
to be how the world operates.
But one thing we do today is again, you can upload your keys when
you're tagging A PDF, and we will automatically match your key schema
to the schema of the document, right?
So that makes it easy for you.
Then create data payloads that are easy for you to manipulate in your
code and have that rendered onto A PDF.
With.
new project, what we're trying to do is go beyond mapping a schema to A PDF.
Imagine a world where you could grab a payload of data in any schema
and tell us the target schema.
And an and anvil just automatically translates that
data into your target schema.
So you can use it in whatever system.
It could be a PDF, it could be another application database,
it could be your snowflake.
So we already have this general concept in Anvil.
It's just very PDF oriented.
Sure.
The goal is to build it out so that you can effectively install anvil
in front of your application or, wherever and just use it as a pass
through for transforming data on the fly to be consumed in another system.
So that, that's really what we're looking to, to work on
in this year and in the future.
It's a really cool use of the tools and
Expanding your borders a little bit.
And becoming the translator between,
Adjacent,
Namespace is a really interesting idea.
I have spent a lot of my career, and I'm sure a lot of people listening
to this have spent a lot of their career doing exactly that, where it's
I don't know, we just get this.
Garbage format from some COBOL program from 700 years ago, and
We need to convert it into this new thing.
And so I'm gonna spend the next,
Nine weeks writing a, an intensive like JSON schema thing
to translate things around.
And,
A lot of the world we're living in now makes that easier and more interesting,
And more capable for
Everyone to do.
That's super cool.
I really like
Yeah.
Did I say the words AI yet, or the word AI yet?
The part of the reason of doing this is actually, if you think about is actually
really good at these types of matching problems where it's you have this thing
here and you have this thing here.
And like a human could look at it and be like, oh yeah, that makes sense.
This field obviously meet matches this key.
But to do that derma deterministically is quite difficult.
You'll never run out of rules to have to implement, but to do
that with ai and lms, it's a lot.
Easier.
And so now we actually have this tool that allows us to do that, and we think
we have a unique data set that allows us to do that better than anybody else.
And we can actually fine tune and tr, make these models work for this use case.
That I think is actually a pretty good moat as we build up this feature.
Yeah.
Definitely.
Yeah, that sounds really interesting.
You'll have to send that my way as soon as it's available.
I'd love to play around with it.
I definitely will.
Couple more small things for you.
Is your team expanding?
Are you looking to hire anytime soon?
Yeah, absolutely.
We are hiring specifically looking for engineers.
We are planning on hiring two-ish, two to three-ish engineers, so if anybody's
interested, please do check us out.
I believe the jobs are posted on, found, also known as Angel List.
Anybody has deep experience with AI ml and wants to be a full stack, just
like a builder, I don't wanna say you're not just focused on AI and ml,
but you can be building the entire application and be close to customers.
Yeah, come check us out.
We have some we have some open roles there.
Very cool.
Yeah,
I will be sure to,
Stick that link in the bottom here too.
The last thing I wanted to ask you about is you host a podcast as well.
Can you tell me about that?
Gimme the pitch for your show.
Yeah.
Thanks Mike.
We host a podcast called Build First Buy and we get product leaders founders
on our show to talk about their decisions when they're building a
new company, creating a new company.
Their decision making around whether to build something or buy something
and specifically around technology.
And I think there is a strong bias to building in Silicon Valley.
I think one guest that came on made a very good point that like people
in Silicon Valley are rewarded for building but fundamentally there are
just things that you probably shouldn't.
Build if you're really trying to move fast and launch.
That's the conversation we have there.
We've had 26, 27 episodes now with some really great leaders.
Many of them are people that I've been fortunate enough to work with in the past.
And yeah, would love for people to check it out.
It's bill verse buy look it up with Anvil in the Google search.
Or ask Claude to look it up for you or something.
Yeah.
And.
Hopefully you guys enjoyed listening to that podcast as well.
Yeah, definitely.
We'll make sure to link that through too.
Build versus buy is the perpetual question,
For all of us.
And
I agree with you.
I think a lot of Silicon Valley rewards building when like money
works to make things happen too,
We see that now as well, right?
Like the whole premise around like Clause is gonna build everything.
You're just gonna prompt claw code and know SaaS is dead.
Maybe we'll get there.
Maybe that is the future.
But I think as of the current state, Claude is great at building
MVPs and actually, and great at editing existing code bases.
I think that's what it's really good at and it is very powerful.
I use it every day, but to productionize something to make it scalable and reliable
and resilient and you honestly have to go through a couple fires and feel the pain.
No.
And then get a bunch of phone calls and then, yeah.
So we, I think we've battle tested and battle hardened our
system quite a bit at this point.
You're speaking to my heart.
I feel that deeply right now, without a doubt.
Right on.
Manding, thank you for joining.
I really appreciate having you on the show.
Before I let you go, where's the best place to find you online and
how do people find Anvil Online?
Yeah.
Best place to find me online is LinkedIn.
Mange it.
Just plot or just like Google, me, my name's unique enough that I'm, I think
I'm the first two pages of results.
I most active on LinkedIn, I will say.
And then Anvil is use anvil.com.
We also have a YouTube channel.
We have a TikTok and Instagram, which you might think is funny
for a B2B SaaS company, but there's some funny videos there.
I would say we, we work with a really great agency.
So check those out.
Hopefully they're entertaining and yeah, hope to hear from you.
I'll maybe on LinkedIn or on one of our social.
Right on.
That sounds great.
We'll make sure to tag you there when this,
Goes live too.
Mange, thanks for joining me.
It was really great getting to know you and super cool to chat about the product.
I'm excited to see where it goes from here.
Thanks for having me on the show.
It was a lot of fun.
Of course, we'll catch you soon.
Take care.