Mike Bifulco: Hello and welcome back to APIs you won't hate.
My name is Mike Biko.
And today I'm sitting down for a conversation with a friend of mine from
actually last summer, which I guess we'll get into in, in a little while here.
But talking a little bit about Sky Verne with Ton Singh from
the founding team of Sky Verson.
How are you today?
Track 1: I'm good.
I'm good.
You know, it's bright and early here.
Mike Bifulco: Yeah, that's it.
Well, are are you on the West Coast?
Track 1: I'm actually in the east coast here.
Yeah.
But it's I live in Canada and we're a nice, like sunny day today, so
I'm pretty, pretty excited about
Mike Bifulco: oh, nice.
Very cool.
Yeah, I'm a fellow East coaster, so at least we're on a similar time zone.
I was worried I made you get up at the crack of dawn for this.
Yeah.
Cool.
Thank you.
So why don't we start here.
Tell me a little bit about about yourself and about Sky Verne.
So let, let's start with Sky Verne.
What's the elevator pitch for what you're building?
Track 1: So Sky is a a browser based automation tool and we
use AI to help like companies automate workflows in the browser.
Specifically what we do is we help companies automate, like really boring
things like form filling particularly interacting with government websites
or generating insurance quotes online.
So really targeting like the back office companies, things that people don't even
know happen in a company, which is kind of why we get, you know, excited about it.
Mike Bifulco: Yeah, the classic startup of of making a boring
problem into a business.
Track 1: that's
Mike Bifulco: cool.
So I definitely wanna talk about that.
Want, want to dig into it and learn more about how you got there and how
like, like many of us, you fixated on an exciting, boring problem.
But before we do that, tell me a little bit about yourself.
What was your background sort of before you.
Started building Sky Verne, what did your career kinda look like?
And, and yeah, I don't know if, hit me with the the exciting, interesting points.
Track 1: Yeah.
So I I was I've been programming for a long time.
I started programming when I was like a, a kid.
My dad tried, actually taught me c plus plus when I was in grade seven because
he was like, this is gonna be the future.
And I was like, okay, sure.
Whatever.
I don't care.
Yeah.
And we made like some really dumb programs back then.
And then when I was in high school, I was really into this game called
Scape, which many, I'm sure many of the listeners are into or into in the past.
And I think I really hit my stride because I started using, I started
writing bots for Inscape, using some like client libraries that were exposed.
And that really, like, I think some of the source codes still
open, open source on my GitHub.
I don't, I don't think it runs anymore, but it's, it's still there.
And I always think back to it is like a really fond memory of when like, I really
like embrace programming and I always loved like solving problems with it.
And, um.
Coding in general, and it just happened that it could also turn it
into a career, which is kind of lucky.
Lucky happenstance, right?
And so I went through university here in Canada and kind of just
fell into programming as a career.
And spent a few years working at a few companies.
And my career really, I would say, took a shape when I started
working at this company called Fair.
Here, here in Canada and I got to own their machine learning platform there.
I got to build it up from ground up having no machine learning background
at all at the time, and it really made me fall in love with what turned
out to be the next wave of computing.
I didn't, I didn't know that back then either, but it turned out to
be the next wave of computing and really helped shape my career.
So I got the opportunity to, to build their search and discovery system
from ground up and make, you know, millions of dollars of impact there.
And I took that learning to another company afterwards, called goPuff
and did the same thing there.
And after that decided to start my own company.
And here, here we're today,
Mike Bifulco: Got it.
Wow.
Yeah.
So it sounds like based on that timeline, you were probably building
ml things like before people were even breathing the word GPT into the air.
Right.
How, how long ago did you start working
with ML stuff?
Track 1: I.
It was like, it was around the time that GPT two was out,
but GP three wasn't out yet.
And so people didn't really know what it was at the time.
Yeah.
And ML was still, you know, like more, less neural networks
and more like other algorithms.
Today, you know, people don't really like the other ones that much anymore.
So yeah, things have changed quite a bit.
Mike Bifulco: Yeah.
Cool.
Yeah.
Oh, that's really interesting.
So you built an ML platforms at, at two companies and then you kind of
made the leap into something a little more entrepreneurial and, and doing
it for yourself from the sounds of
it.
And so what, what was, what's Sky Run's story like what, what was the first
I don't know, attempt at a product?
How did you decide that you were gonna do
Track 1: So Sky's actually our third pivot, believe it or not.
So we've been building startups for a while.
My buddy, my buddy, my co-founder Shu and I, we decided to start a company
together on like one random trip.
We're like going surfing on the car drive.
We're like, Hey, we should start a company and, you know, like, any good stories so
that, that we ended up materializing that.
And the first product we built was actually a tool to help onboard software
engineers because I had recently become a manager at a company, and I went through
the pain that was poor onboarding.
I later learned that that's a very common target ideas for
engineers to build work on.
But we went through the process of building a startup.
We made every single mistake you could imagine.
I.
I think Y Combinator has been very helpful in our career, in our career because
they put out a lot of content online talking about how to build startups, and
we later watched all those videos and they recanted all the mistakes we'd made.
We'd already made up to that point.
So we built a product for us without talking to any users.
We're like, we know exactly what people need to solve this problem.
So we built a solution and then we started trying to find people who'd buy it and
turns like nobody wanted to buy it because we were not really solving a problem the
way that people were having the problem.
And it was, it was not obvious at the, at the outset that that was that, that,
that that's where we're going down.
But I'm, I'm still glad we did it because it taught us, you
know, how to ship code fast.
We're working part-time.
Like, you know, we had, we had our full-time jobs.
We were just coding on the side, trying to get a product out.
And all the lessons we learned after we built the product, like how to
do sales, how to talk to people, how to make sure that the problem
we're solving is aligned with the problem people are actually having.
Were, were things that we wouldn't have learned had we
not gone through that journey.
Mike Bifulco: Yeah, definitely.
I would love to
see, I'm sure someone somewhere has a chart on correlation between
startup founders and having had a, a, a failed experience in the
past, or at least something that didn't go according to plan.
I'm definitely one of those, the, the first couple of attempts at
building a company for me were not not, not successful experiences in
the traditional sense, but definitely in the sense that I took away lots
of learnings from it and like.
Often harken back to the things I did poorly in the past as
I'm making decisions now.
Yeah.
Okay.
So, so you said you're in your third pivot at this point?
Yeah.
Track 1: That's right.
Yeah, that's right.
So after that, we pivoted into something that was much more in our domain, which
was since I've helped two companies build their machine learning platform for,
particularly for search and discovery experiences, to help like marketplaces
increase their revenue I had a, we basically found a company that wanted,
was interested in buying that product.
And so we pivoted so we could build it and sell it to that company.
And we got a commitment very early.
We, we, we actually changed how we did software development.
In this case.
We did sales first.
Made sure the shape of the product made sense.
We were a lot of documents to align with the people who wanted to buy it.
Talked to many other companies along the way.
And then we started building the product.
And so we, we did a hard pivot at that point because we found that there was
actually, this, this problem I had solved at two companies was actually a
problem that many other companies had.
Started exploring the general space of like search and discovery.
Went down a few lanes that other companies had also gone down.
So one very common idea that people who have worked in, in this field go into is
they try and build search as a service.
Like they build like a plugin for Shopify where people can plug, put in a search
engine and make more money that way.
We went down that path, we went down doing the same thing for recommendations,
and it turns out both those ideas are very tough to execute on because
many people have tried before and the value of the product isn't there.
Yet isn't like the shops are too early to realize the value of the product.
And so this, this is I think another area of possible tar ideas.
It's unclear whether it's actually a tar idea today, but a tar idea being an
idea that's seems attractive from the outset, but it's not has lots of people
who've tried it before and all failed.
And so we talked to a bunch of founders who had tried it and had failed with
those and kind of had had some learnings.
So we went down this path of building a different platform.
Yeah.
Mike Bifulco: so why don't you tell me a little bit about the first version
of what has now become Sky Verne and how you decided on that pivot.
Track 1: Yeah.
So we were just to quick, quickly finish the loop on Vern, we built a
product and what we learned was that we actually learned during sales.
We got about three commitments from companies and.
We learned that the companies were excited about our product.
All had a division between their data science team and engineering teams,
which made sales very challenging.
Particularly if a company had that division.
They were really excited about our product and if they didn't have
that division, they were not excited about our product at all, which made
selling the product very challenging.
And so we again, decided to pivot the third time.
This one was way more deliberate.
We had revenue.
We were like, had some some traction, but we decided to pivot again and
we wanted to build something with AI agents and we didn't really understand.
We knew from a technical perspective, okay, we're like, this is cool stuff.
We wanted to build cool stuff with this, you know, as engineers do.
But we didn't really understand how users wanna use this product.
So what we started doing was reaching out to a lot of people to see how
people would wanna use AI agents.
And the thing that kept coming up over and over again was that people were
really excited about the possibility of automating, like basically controlling
the computer to do something in a company.
Okay.
And that something was a big, big question mark.
So we talked, talked to a few companies that actually building products in
the space, but we also talked to a bunch of people who were very excited
about, like excited about this by reaching out to random people on the
internet, like looking at forums, looking at Discords and so on.
And we found a few companies that were really, really excited to automate
workflows in their background.
And the first one we ended up working with was a company who wanted to automate
insurance code generation using AI agents.
You can imagine that's really boring.
But the product they, they sell is, they're an insurance reseller.
You go to their website, you fill out their workflow and then they basically
fan out to a bunch of insurance providers like State Farm, Geico, Allstate, and
generate quotes for you and that stuff.
If anybody, if any of your listeners have experience building scrapers
before, that stuff breaks all the time because the layout changes a little bit.
They have like all these nuances, and so the question was, could
you make that better using ai?
Could you make that better?
Using computer vision and some form of like GPT-4 S things.
And so that's, that's the, we took, tried to take a stab at that.
So at first we asked, the few people we ran into we're like, Hey, what have
you tried to solve this problem today?
They're like, oh, we talked to these companies, nobody solved it for us yet.
And we're like, okay, let's try it out.
And that's kind of how um, was born.
So we ended up working with a handful of these companies.
Just to begin with, just to get the shape of our product.
Right.
And then now we're starting to scale out to more and more companies.
Mike Bifulco: I would imagine that many people listening to this podcast have
tried to write a screen scrapper in the past, either for like a assignment
for a, you know, a course or a code school or whatever, or for the, you
know, some real business reason that they wanted to have something automated.
And I think having done it once is enough to tell you how painful
it can be when things break, and how hard it is to build something
Track 1: And it's funny, I've done it too, you know, like when I was
kid, I was writing, it's the same idea except now using way better
technology, you know, it's, it's great.
Mike Bifulco: Yeah, exactly.
And so you, you pivoted to, to this sort of third place where you're
starting to, to build for automation.
If I remember correctly, you had applied to and gotten into yc.
So this is how we met.
I sort of alluded to this in the intro.
We both went through Y Combinator's summer program last year.
We were in the the S 23 batch.
And at the time you were y Vern, right?
So you were in, in,
your second pivot building marketplace tooling and, and pivoted there.
Can you tell me a little bit about what the YY Combinator experience was like
for you and, and some of the things you might have gotten outta that?
Track 1: Yeah, so the Wes experience is pretty cool.
So I, I, I feel like Wesley's community.
It was just like a bunch of really technical people who
want to build something cool.
And I think that I, I don't really think I real recognize that, but when we
applied, we applied because the videos are very, very helpful to us in our first
pivot journey into our second pivot.
But the experience itself is very cool because you're in this like
concentrated group of highly technical people working on really interesting
problems and that that is like nothing short of inspirational.
Because anytime you meet up with somebody, like even even me and you, right?
Every, when we had our convers, when we chatted, I would just be inspired
to work hard and solve problems and you know, you could talk with people
at a higher level and I think that's something that YC unlocked for everybody.
In terms of my experience specifically, my experience was like a little bit
unique because I actually had a kid during the YC batch, which I learned
I wasn't the only one first of all.
But I also don't recommend if anybody's listening and thinking about that.
I don't recommend going through
Mike Bifulco: I can't imagine.
Yeah.
Track 1: Yeah.
But
Mike Bifulco: So that must have complicated thing.
So your kid was born during the batch.
Track 1: it was, yeah, she was born during the batch.
She was born actually exactly halfway through the batch.
Mike Bifulco: Wow.
Well, first of all,
congratulations.
Track 1: I didn't get, I didn't necessarily get the full experience
of yc, but it was also kind of extra focusing 'cause we really
had time for nothing else.
Like you really had time for nothing beyond startup and, and life.
And that's it.
I think, I think the month after she was born, I lost like 10 pounds
because I was sleeping like three hours a night and just like grinding
during the day and like, you know, baby taking care of the baby at night.
Mike Bifulco: What a wild motivator.
That's really interesting.
I feel like few people in the world can relate to a desire for things to be
automated, like parents of a newborn.
Uh, you know, like if, if everything was just a little bit easier, your life
Track 1: Well, it's funny because like there, there was a whole class
of ideas we were exploring that were like born of that pain, right?
Because I was like, okay, so I'm taking care of baby while programming
or while doing sales, how can I control my computer with my voice?
There was like a whole subset of whole subset of like applications we were
exploring, like voice of text, like, you know, computer automation, all based
on this huge problem where I was just like, my hands are busy, but I still
wanted to, to be productive, right?
And so we ended up not, not going down those paths, but something
similar I guess is what we landed on.
Mike Bifulco: Sure.
Yeah.
Wow.
Well it, it's really interesting.
So you, you definitely had a non-traditional path in yc, right?
Like probably in the per percent of a percent of people that who've
ever been through YC have probably had a kid during the batch.
Track 1: Actually it's more common than you think.
It's more common than you think.
That's what I learned during the batch.
It's when you are in a situation, you find out other people
are also in that situation.
And I learned that it actually, maybe a percent of the batch, I would say is
like that.
Mike Bifulco: That's fascinating.
Yeah, I definitely know some, some friends who I met through IC who
got married before, during, or after the batch, and that's a, a similarly
like life shifting experience.
Usually something that's hard to explain to, you know, a, a potential
partner that like, Hey, I know we're getting married like in a month, but I'm
have to move to San Francisco now.
It's a hard thing to deal with.
like you, I had an uncommon YC experience in as much as my, my company craft work
is very, very geographically focused.
Right.
We are in Charlotte, in North Carolina, and so I spent all
summer flying back and forth to San Francisco for for meetings because
our business is so importantly here,
um, I can definitely relate to like, not fitting the pattern.
Exactly.
Okay.
So, so you made it through yc, your pivot into skiver.
Then was was also during yc or was that after the batch ended?
Track 1: It was after, so it was about a month after.
So what happened during the Bachelors were, were.
Basically one thing YC focuses you a lot on is like picking one
metric and growing that metric only.
And so the metric we we had picked was revenue.
And so we're like singularly focused on growing, growing that metric.
And what happened during the batch was we had one customer that was paying us like
some amount of money and we had actually.
One commitment from another customer for a bigger amount of money.
So we're very excited.
Things are going well, and after the batch, we got a third commitment.
So things are going amazingly well, right?
And we're like, yeah, this is gonna be a big product.
It's gonna be huge, you know, amazing.
But what happened was right after that, we started looking into our sales data.
See, okay, so now that we have three commitments, like what is
repeatable about this process?
Like what is common in these customers?
What is un uncommon in the cus common in the customers that rejected us?
So we can start like selecting earlier, if that makes sense.
And that was about, like, that was about three weeks after the batch.
And we, in digging into that data, that's when we realized that commonality where
the companies that were excited about our product were ones that had like
their data teams and engineering team structure in like a very specific way
where they didn't communicate effectively.
And if you look at the total number of companies like that in the
world, one, there aren't that many.
And two, even if there are many, it's, it, it, it becomes a much less exciting
problem to solve when you're not able to help many companies, you know?
Be more effective.
And so that's why we actually
pivoted.
Yeah.
So it was
after the batch, it was
about a month after the batch.
Mike Bifulco: the scale story is, is dramatically different
if you're targeting, you know, half a dozen companies or less,
uh, you may still be able to reach an exciting revenue number, but harder.
Track 1: Yeah.
And then when you're pivoting, you start asking yourself questions.
Right?
You're like, okay, well is there a way, is there a shape of the product that I can
build that maybe appeals to more people?
Right.
Or is there, is there, or is can we work on this problem somehow?
But I think the question that we always ask ourselves when we're pivoting is,
do we wanna still go after this market?
Do we still want to go after this thing?
If we are thinking right, do we take one step back or do we
wanna take this full step back?
I take the full picture and this entire time, you know, we saw the, the evolution
of language models we're getting more and more excited by it and had a lot of
experience with it because I'd worked in search and language models have been
part of search for, for pretty long time.
I would say transformers was, you know.
Created to help with natural language processing, which is like
core to Google search algorithm.
And so that's why we decided to take a leap forward and
and do the full pivot instead.
Mike Bifulco: Yeah.
Okay.
And so now we're in the world of Sky Verne and you're
automating things with AI agents.
, from what I can tell, the point you're at right now is sort of early on
in the product building experience.
And so can you tell me a little bit about what, the current version of HelloWorld
looks like for someone using Sky Verne?
Track 1: So we're at, we're at a stage where we're actually manually
onboarding customers because the user interface is something we're
still trying to get, like correct.
We're looking in the process of onboarding.
We're learning about how people would want to interact with our product.
But today, sky Ver is an API that you call.
It's a pure API product.
And what you pass it is basically a URL you want to go to.
So we have four customers that are live.
They all pass us to different URL.
The insurance reseller passes us something like echo.com.
Other customers pass their own URLs and and then they pass us
what we call a navigation goal.
And that basically tells our Charles Skiver to go do something.
In the case of generating an insurance quote, it's like, Hey, go, go generate
an auto insur or auto insurance quote.
Don't generate a home insurance quote.
You're done when you have gotten to the quote page.
And then what?
What we're able to do is take that instruction and basically
start@geico.com and just keep going until it hits that goal.
So it just takes a look.
Look at every action that's possible on a screen and just decides,
hey, this is the most likely thing to get us towards this goal.
Over and over and over again until it gets there.
So it'll click on auto, it'll, you know, fill in, fill in information.
And then what we also ask our customers to pass in is basically some information
that's necessary to complete the goal.
So in the insurance case, all of your information basically.
And then we just keep using, mapping that information to whatever's on the
screen in real time and just like.
Boom, boom, boom, until it gets to the goal.
So to go back to your original question, which is where are we
in the development lifecycle?
So we have four customers we're live with today, and we're looking, we're,
we're onboarding about three a month at, I would say, at this, at this point.
Mike Bifulco: Are there so that's a reasonably small sample set, but
in terms of the customers you're courting right now or talking to,
are there commonalities between them?
Track 1: No, actually, and that's by design.
That's actually by design.
So whenever you build a product that has like too many applications, you
always hit this like decision point where you wanna have you wanna onboard
people, like you wanna solve one problem well and onboard lots of people
in that, that are in that vertical.
Or do you wanna solve a lot of people's problems?
Kind of all, and we're actually in the second, we're doing
the second one on purpose.
And the reason for that is as you can imagine, interacting
with the web is very messy.
Every single website is like, designed differently.
Some, like we talked to this one customer where their workflow in
involved interacting with this like website in in, in India, like the state,
state government website in India.
And halfway through the workflow to refresh the page five times
to get a button to show up.
Like, how do you, how do you instruct an agent to do that?
You gotta like, you know what I mean?
Like how do you instruct, how do you instruct any AI to know that,
okay, you gotta to this page, you don't see a button you need to click
on, you gotta refresh the page.
Like, wow.
But
the reason, the reason we're going horizontal though, is to, to kind
of learn about cases like that.
And what we found with our product is every time we onboard a new case,
we actually end up solving like 10 other cases we didn't know about.
And so as we onboard more and more websites.
Our coverage increases, and that's kind of the thing we're going after right now.
And there'll be a tipping point, whereas coverage will be, you know,
maybe 50% of the web or 70% of the web, where then we can start
onboarding customers extremely fast.
We can open it to everybody.
They can have a recent, like a moderately good experience that you
would expect, and that's kind of what we're pushing towards today.
Mike Bifulco: Oh, that makes a lot of sense.
I, I think you, you're more likely to get more broad feedback than to focus
on, you know, just solving problems for the, the insurance adopters or
whatever it may be in the world.
Okay.
So let, let's talk about this from the perspective of, of an API
developer knowing that our audience for the podcast is generally people
who are building and designing APIs.
I'm kind of interested to hear, two, two things from you.
One is like, what's an interesting use case for for using Sky ver that
might stand out to API developers?
And then I, I want to ask essentially the same question, but about building
Sky ver things you've learned about APIs, but, we'll, we'll do that next.
Tell me about like what's an interesting use case for an API developer
that they might use Sky ver for
Track 1: Yeah, so.
I would, I'm gonna answer this question from, from the perspective of an API user.
So I would say an API developer would be looking to, you know, build APIs on
things that don't already have, have APIs.
Right?
And actually, if we were to distill why like Sky Run's goal down to what it's
actually trying to do, we're trying to solve that exact problem, which is
how can we build an API for websites that don't have APIs and might never
have APIs.
And might never have APIs.
And then there's two categories of websites that are like that, right?
One is, maybe, there might be more, but two, two big ones that I think about.
One is websites that don't want you to have an API.
And then there's obviously like, like you could, you could put like insurance
code generation in that, right?
Geico probably doesn't want to expose an API because even though they
have to make the algorithm, they, they used to generate quotes public.
They obfuscate it because they don't want people to replicate it.
Right.
So they, so there's a lot of websites that don't want to expose an API, LinkedIn
might be this, you know, Twitter's recently become this with their, the
way they charge for APIs and, and so on.
So we can help companies interact with websites that
don't want you to have an API.
Obviously, we don't wanna violate any terms of services or anything like that.
So we, we make sure that the, the use cases are reasonable.
And then the, and the second type is the websites that.
Can't have an API and, and that's like generally I would
consider government websites that fall in that category, right?
Like legacy websites that are relatively unmaintained.
We, we've been talking to like a bunch of companies that are like
dealing with old school, like supply chain procurement companies, right?
And they have like these content management systems they were using
for their purchase orders that were built in like the nineties or the two
thousands that are unmaintained, but.
You know, or the definition of a moat where your data is so far in
it that it's so hard to get it out that nobody's gonna do it, which is
like the textbook definition of what a good software moat could be like.
Right?
So those are websites that would never have an API.
And so we really are trying to solve the problem of building an a
p on websites that don't have one.
So from an API developer's perspective, it's like how do you
develop an API that is the API to any website that doesn't have one?
And that's a challenging problem, right?
That's a really challenging problem.
And how can you like build an interface that.
Conforms to the, the peculiarities of every website.
And what we landed on was actually we just have four fields that kind of, and we use
language models to do everything else.
So we have one field that's the URL, where, where do you wanna start?
Second field, which is what we call navigation goal, which is what
do you wanna do on the website?
So what navigation actions do you wanna take?
And then third is what do you data extraction goal, which
is what do you wanna extract?
Then fourth is what we call payload which is what data do I need to do
everything that you asked me to do?
And so since, since the last three fields are unstructured, they are
like, like natural language fields, we can then use language models on
the backend to map whatever they pass in to things that need to be done.
And so the API from from the user perspective is actually very simple.
All of our customers use the same one.
The things that passed in are totally different, and then we kind of map it back
and that creates its own challenges, of course, but I'm happy to get into that as
well.
Mike Bifulco: yes.
I think I definitely would like to, this is, this is very juicy and I think
you've just given me the title for this episode of you're building the
API for websites that don't have APIs.
That's like very, very juicy and very good.
Okay.
So that, that's a perfect dovetail actually into the next step then.
So like you, you have a, a wildly simple at least shape of your API, but three
of the four fields are NLP fields.
What is
it like to build something where you're asking someone for a very abstract input
and trying to map that to a real goal?
Like how, how do you build around that?
Track 1: This is something we're actively iterating on because the problem with the,
the benefit of abstract inputs is that the demos are very, very attractive, right?
You, You, can make, you can make,
something work pretty effectively, but how do you make it work a hundred percent.
And we found that the more precise you are in the goals, it's same
as when you talk to like chat pd.
The more precise you are with what you want to get done, the more accurate it
is that being able to get that done and then you can start abstracting that as
concepts a way to like more deterministic things like I would say the most of our
time is not spent iterating on how we understand the logic coming in from,
from our customers, but it's, it's.
How do we make sure everything that's happening with this thing that is
not deterministic, every binding to it is deterministic, and how can we
conform it to be more deterministic?
So all of our time is actually spent in like massaging, I guess the,
the, the HTML, the, the JavaScript that you see on a, on a browser
that, that runs in a browser.
To conform to what the language model can interact with and how it
relates all the way back to a goal.
And so we spend a lot of time helping our customers, one, create the prompts
and create the payloads they wanna send to us, but two, finessing the
language model to output a specific way.
And actually, if you look at how like GitHub copilot is
made, they do the same thing.
Like most of their remote, I would say is not really the language model.
I mean, of course they benefit from improvements in it, but it's how do you
force the language model and, and have all these like edge guards in place.
So that the output is productive,
the output is very productive.
Right.
It's like extraordinarily productive.
Yeah.
Mike Bifulco: I, I love this sort of problem for, for so many reasons that
like, this is, to me, the core problem of dealing with large language models right
now is the non-deterministic angle of it.
And I'm sure you've seen articles that have come out recently about I think
it was Ford who had a customer ask for a car for free or something like that,
and they were like legally obligated to give away a car because their, their
chat bot on their site said they could do that.
And I think.
If there's maybe an airline that did something similar recently and, and
all of these things that are coming up that is like the real consequence
of using something non-deterministic is that you can offer up a result to
someone that is completely not based in reality and, and be legally bound to it.
And there's a lot of really challenging things that come along with that.
I was talking to another founder recently who, who was musing about LLMs and,
and was saying something like you know, trying to imagine themselves as a, as
a kid picking up their first program and trying to imagine how they got
from like adding up the perimeter of a square to you know, something where
it's like, ask an abstract question.
I'll do anything you want is, is a pretty wild response.
And it's some of the magic of where we're getting to today, but definitely
like, involves a, a reasonable amount of, of risk and sort of uncertainty.
And maybe that's why someone building a, a startup like you are
is isn't a good place to tackle this.
That you can kind of deal with that uncertainty and take chances that
probably like, I don't know, Delta Airlines or whoever it was, probably
shouldn't be taking right now.
Track 1: Yeah.
. Just to, just to touch on that a little bit, the other side of risk
management though, is like also thinking about how the thing is used, right?
Mike Bifulco: Mm
Track 1: Like, and, and that's the part that we, we think about a lot internally
is like, you know, the cost of getting an insurance quote wrong is low.
It's like, it's not, it is not like you're processing a transac transaction.
It's not like you are, you know submitting like a birth certificate where the cost
of an error is like catastrophic, right?
And so we generally steer ourselves and ourselves and of course our customers
as well to handling use cases where the cost of an error is low and the air error
error is not necessarily in like the particular text you input, but the, the
result of the combination of effects.
And so one thing we don't do, for example, is we don't do deal
with any transaction events.
Like if you wanted to, for, if you wanted to use our product to go buy,
automate some procurement pipelines on websites that don't have APIs,
and you wanted to order hundreds of thousands of dollars for the product,
we would say we'll build a card for you.
We won't check out, you know, we won't check out.
And, and that's like a reasonable safeguard to put into place because
then the value still generated for you where you don't, you don't have to go
through the effort of building a cart for your procurement pipeline, but, but
the risk, you can still have a human in the loop to do the final validation.
Which is something that is necessary today.
Maybe, maybe in five years it might not not be necessary, but today certainly is.
Mike Bifulco: Yeah.
Brilliant.
That, that is a great way to handle risk and that's actually
a lot of, of how I talk to.
So in a past life I worked at Stripe as a developer advocate.
And this was the, the conversation I would have with a lot of people building early
stage products is that essentially around credit card information specifically,
like you don't ever wanna store a credit card number in your database, and Stripe
has a massive team of very qualified people worried about data privacy, and
that's why you should offload it there and like trust that stripes the holding
of your customer's credit card information is better than you could ever do it.
You're almost the inverse of that, where it's kinda like, well, we just
wanna do the things , that we are relatively sure the consequence of
it is, is reasonable both for, you know, sky ver and for your business,
but for your customer's business too.
Yeah, I love that that's, that's nuanced and valuable perspective to
give to your customers along the way.
In terms of use cases for skyr, so you've got a small amount of customers onboarded.
Are there use cases that are interesting to you, or ones that you would like to see
customers jump on board with that you're maybe particularly excited about or you
think are creative or uses for skyr that, that are maybe non-intuitive at first?
Track 1: Yeah, I think we've found a bunch of use cases.
The one that we're actually actively focused on right now is
in the general field of interacting with government websites.
So you're a founder when you were, when you incorporated, you can imagine
the delusion paperwork you had to fill out with the state of Delaware
with, you know, state of California.
And we found that there's like a bunch of companies like
accounting firms, law firms.
Banks even that ha, that have this like back office that either has
people doing it or they have like really haphazard pipelines that
automate it, where they just interact with those government websites.
So something that is probably on top of many founders' minds right now is
trialing for Delaware franchise taxes.
It is due in seven days.
I haven't done it.
I don't know if you, your company's done it yet, but you know, it's on
my to-do list, but it's something you have to do, and if you do it wrong,
you're gonna end up paying like tens of thousands of dollars worth of taxes
that are not necessary or get fined.
Mike Bifulco: Right,
right.
Track 1: people have to do manually.
Right?
And, and the question, is it, does that have to be something
that people do manually or can it be automated in the future?
And so that, that whole area of use case is something that we were very excited
about very excited about automating, which is kind of funny because like,
who would be excited about that?
Right?
I, I certainly wasn't from like a user perspective, but from a
a business perspective, I'm very excited about automating that stuff.
Yeah.
Mike Bifulco: That's, that's the thing.
Those are the automations that, that are most valuable is the ones that
people want to do the least or that are the most painful for them to do.
Super cool.
That makes a ton of sense.
I, the thing I always I.
Tell.
Well, so the, the first thing that came to mind for me when you said automating
government websites is something that I've had to do a few times, which is
baffling when you have to do it is looking up an EIN for a company you
own, but you've misplaced and that is so painful to do and such a nightmare,
and you can understand all the red tape involved in all this stupid
government websites you have to navigate.
But I've certainly lost hours of my life to just looking up a eight
digit code or whatever that is.
Yeah.
that's a great use case.
I'm super into that.
, and looking forward to seeing, you know, the realities of
what you're building there.
, can you tell me about your team?
So like, how big is the company and what is your stack, what's
your architecture look like?
Track 1: Yeah, so we at the end of yc, we did raise like a small pre-seed
round for Wyvern before we pivoted.
We ended up stopping the fundraising after that.
But we are a team of three people right now.
All three, three of us are co-founders.
We are all technical people, so we all write code every day.
Which is, which is cool.
Obviously the, the responsibilities are not equally distributed.
Like I, I also write code, but I tend to write the least amount of code because I
spend most of my time doing sales as well.
Mike Bifulco: Yeah.
Okay.
Track 1: yeah, from an architecture perspective.
So we decided to keep our product relatively lean as, as it is today.
This might change.
This will definitely change in the future.
And so our product is entirely in the, in Python.
It's an API product.
We actually don't have a user interface.
I think this is the truth about startups that people don't necessarily talk
about is many companies don't invest in things that aren't necessary.
Like we haven't had a user interface for four months now.
We've been onboarding customers and it turns out there's a subset
of customers out there that are okay with that, that are actually
totally okay with not having that.
And so we didn't build it yet.
We'll build in the future when we have more time and more, more, you
know al time allocation to build it.
But our stack is fully in Python today.
We use like Fast API as our primary API driver.
And under the hood we use Postgres just as our database, super
base, as our database data store.
We run everything on AWS Nothing too
crazy.
Mike Bifulco: Certainly familiar shape and clever application of, of the tools
that you're using to build towards something that makes a lot of sense.
I.
Okay.
And so you're at the point, you've, you've onboarding customers,
you're starting to ramp that up.
So tell me about what's next.
What is the next milestone for Sky Ver that you're looking towards?
Track 1: Yeah.
So something we've been thinking a lot about internally is how can we solve a few
very specific problems that actually have come up in, in our sales conversations.
And so there's two, two problems that are pretty, that stand out a lot.
So one is.
I talk about interacting with government websites a lot as like a use case, but
one that I didn't touch on is a vertical that has another set of problems,
which is the healthcare vertical.
Particularly healthcare and health tech companies do a lot of boring
form filling as well, largely because of like compliance requirements.
So they have like disparate systems that each store data, and
because of compliance, they can't actually like, share, share data.
So they have like processes that involve taking data from system
A and transcribing the system B.
And the problem with these systems is that they require.
Every vendor to be compliant, like in some way, whether it's HIPAA
compliance, whether it's SOC two compliance many actually even
require a self hosted solution.
And so an idea that we've been going pretty far down is actually open sourcing
a product to one, solve that problem.
But two, also just share the cool stuff that we're building with the world.
You know, as a developer, playing around with a tool that can interact
with the web would be pretty awesome.
I mean, there's some websites that certainly wouldn't work
for, like if you try to use it on LinkedIn, it just doesn't work.
We don't, we don't allow that.
But, but there's many websites where it would work for and very cool.
So one, it shares the cool of the product with the world and gets developers
pretty excited about what we're building.
And two, it actually solves a real problem that we've experienced talking
to our customers is how do we create a self hosted, reliable version
of our product where our customers actually have full transparency on
how it works, and open source actually solves that problem completely.
And so we're pretty excited about launching an open
source version of our product.
Mike Bifulco: Wow.
That's, that's really cool.
That is super exciting as a not only a founder of a startup, but I tend to
get into like dangerous side projects on the weekends when I have a silly idea.
And there's probably half a dozen things that have floated across my
brain as you and I have been chatting.
That'd be like, man, I would love to have an automation solution
for this thing that I is a, a part of my life for whatever reason.
I think open source is a really interesting angle for this too.
'cause no doubt you'll see people with creative ideas that you haven't
even thought of yet for feature additions or, you know, tweaks
to the API and functionality or shape or whatever the case may be.
Track 1: One thing we're really excited about open sourcing specifically is as I
mentioned before, like one of the problems we have is the coverage of, of the web
with our product is increasing over time.
And the truth is we are limited, right?
We have three people working.
We can only talk to so many people and experience so many websites.
One thing we are excited about open sourcing is that maybe that
you will try it out for this idea that you had over the weekend.
And you'll find an issue with the website and maybe you'll fix it.
Right.
And that then, then we can really like harness power of the open source community
to build a really cool product that can interact with the entirety of the web.
Right.
That is like the dream we're going towards.
And, that could be possible, right?
With the, with the open source angle.
Yeah.
Mike Bifulco: You're enabling a feedback loop for more of the intranet to, to
make things more broadly applicable.
I would love to be able to, to poke with that.
And so you're, you're opening up some open source projects.
Presumably those are gonna be based on similar stacks, so Python,
uh, fast, API and Postgres in whatever shape.
That's really great.
And so what about in terms of your team?
Are, are you thinking about hiring?
Is that something that's gonna come into focus for you anytime soon?
Track 1: I, I think probably in six months we'd be looking to hire some people,
but for now we're trying to stay lean.
Mike Bifulco: Sure.
Track 1: we're actually like optimizing for high, high frequency communication
and like just when you have a small team, you have only a small number
of projects you never work on.
And, and that
small number of projects actually for startups can be a benefit
because it really makes you focus on what is good or bad.
And that's something that people don't necessarily always talk about is like
the, the real advantage of the small team, which is high, high amount of
ruthless prioritization is needed.
Otherwise you end up working on things that don't matter.
And if you work on things that don't matter to startup, then you
launch things next week instead of launching things this week.
And that effect compounds negatively.
And so we are actually quite a.
Happy with how lean our team is today.
Obviously it won't be sustainable as we ramp up sales and acquire more customers.
You know, there's some use cases we're solving for right now that are one
of the companies we're helping with.
We help 'em apply to like, job applications online and, and at night
we'll wake up and we, and some jobs will fail and we have to manually
resubmit them, you know, and so as we acquire more customers, we won't be
able to scale that side of it forever.
So we'll definitely need to hire for some help, but that's not something we're
planning any time in, in the short term.
Mike Bifulco: that's really good perspective too.
A lot of the successful founders I've spoken to are really good at that
prioritization and things like cutting scope dramatically is like a real skill.
And just like you said, shipping this week is always more important than
shipping next week, especially if you're able to learn from it and sort
of iterate more quickly as a result.
That's great.
So for folks listening to the, the show right now where's the best place
to go to get started with Sky Ver.
Track 1: So if you go to sky.com, you'll see a link to our GitHub.
I would recommend checking it out and you know, if you could clone the
repository, play around with it, try a couple websites, maybe open a bug report,
that would be super helpful for us.
Also, any stars are of course, always appreciated.
, Mike Bifulco: for people who may be interested in sort of like.
The customer side of things.
So if, if people are working on teams that they feel like might be a candidate
for someone who would be a good customer for you is there a place to reach
out on, on the website there as well?
Track 1: Yeah, so if you go to our landing page, there should be
a button where you can actually book a meeting directly with me.
Feel free to feel free to do that anytime, even if you don't have
any customer use, 'cause I'm always happy to chat and share and talk.
But if you also wanna get in touch with me, you can always email me
at ton at we or@sc.com, so@sky.com and I'll be happy to respond.
Mike Bifulco: Okay.
Well switching to thank you so much for joining today.
It's been a pleasure talking to you.
I'm really, really excited to see that you're opening up some open source angles
for, for the community to tackle here.
And I wish you the best.
Please feel free to, to come back and join us anytime if you have
other things you wanna chat about or if you have launches upcoming.
And tha thanks a lot for joining me today.
I appreciate it.
Track 1: Oh no, it was . Great.
Mike Bifulco: Sure.
Talk to you soon.