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.