Mike: Welcome once again
to APIs you won't hate.
My name is Mike Balco.
I am co-founder of APIs You Won't
Hate and host of the podcast.
I'm here today talking to, my
new friend, Constantine Schreiber
from Fast Gen Constantine.
Thanks so much for
hanging out with me today.
How are you doing?
Constantin: Thanks for the invitation.
Doing very well.
How are you?
Mike: Yeah, I'm good.
Thanks.
I appreciate it.
We've, we've had a long wait to get to
actually talk to each other, and I'm
really interested in what, what you're
building and what Fast Gen is doing.
But why don't we start here?
Why don't you sort of introduce yourself
and tell me a little bit about your
I don't know, your, your history
what you've done before fast Gen and
how you got to where you're at now.
Constantin: Sure.
So I guess my passion for creating
things started when I was quite young.
as a child, my, my first like green
job was to become an inventor.
Not necessarily in the digital space.
I thought of it more as a, like crafting
things and building like robots and stuff,
but I think it's this like curiosity
that led me to explore coding at a
quite young age and web development.
So I taught myself how to do pretty basic
web dev stuff, with back in the day, like
visual basic and all that kind of stuff.
And.
Mike: Yeah.
Constantin: When it came to the
site for college, I went into
a slightly different direction.
I decided to study economics and
management cuz I just wanted to get
like a broader understanding of business
and the dynamics of various industries.
And the time I thought that it would
compliment my technical skills and help me
to become a more effective entrepreneur,
which kind of was the end goal by then.
But during my time at business school, I
quickly realized that all the other that
were entrepreneurial and wanted to have
found something were extremely limited
because of their lacking tech skills.
So I decided instead of being
the guy that has to a tech
guy, I want to be the tech guy.
So that kind of.
Led me back to computer science,
moved to Berlin enrolled to a new
kind of university called Code
University which was very practical
and allowed us to work on exciting
projects with companies like Porsche.
So, built autonomous drones with
them and really explored all kinds
of different science aspects.
There are.
And it was at that time where that our
first company together with two dear
friends that I had met at business
school, which was a company called Blair.
And we were doing income
share agreements in the us.
Went through yc raised in total over
a hundred million in equity, in debt,
and sold that business or the assets
of that business at the end of last
year and, During our time at Blair,
we, were kind of looking for a tool
like fast Gen to get us off the ground
faster and as I essentially like a
platform that would use us to friction
and allows us to just ship quickly.
And yeah, after talking to a couple
of hundred users and validating
that there might be others that
are interested in a similar thing.
We went back through a drawing
board and started working on Fast
John, and that's where we are now.
Mike: Yeah, very, very interesting.
So already I can feel a few
things we have in common.
I also started my coding journey
with Visual Basic once upon a time.
, and though I, I did study
computer science in undergrad.
I also studied mechanical
engineering thinking it would
make me a more well-rounded.
Whatever I am.
I don't use mechanical engineering
much anymore, but certainly the
calculus I learned along the way
comes in handy from time to time.
Yeah, that's really interesting.
So sounds like Blair had a,
had a pretty interesting ride.
Certainly being admitted into YC and going
through that program is really exciting.
a second time founder now with Fast
Gen, it sounds like you've also
learned from sort of the basics of the
beginning stages of starting a company,
which is talking to lots of people.
Validating your idea before you go
and hide away for weeks or months or
years and build a product that you're
hoping people are interested in.
That sounds familiar too.
I, I probably should have mentioned as
well, I'm, I'm a repeat founder myself,
so that brings us to fast gen then.
What's the, the pitch for fast gen?
What do you tell people when you're
first introducing it to them?
Constantin: Yeah.
So Fast Gen is a low-code platform
for crafting APIs and workflows.
And an analogy I like to use for maybe
some of the less technical people is
we kind of want to become what Webflow
did for the front end, for the backend.
So we.
Are really focused on creating
a experience that is less
limited than, than other tools.
As and I have to mention like
we are builders at heart.
We have four great
engineers apart from me.
And when we looked into existing
solutions, we were always really
annoyed at the lock in or.
At the fact that there's just a limited
complexity that you can build with it.
And that was one of the core
reasons why we were always kind
of skeptical about employing any
kind of low-code tool in our stack.
so with fast Gen, it is really at the
core of our mission to try to allow people
to build as complex things as they want.
are definitely not there yet.
but yeah, really working
hard on incorporating that.
Mike: Yeah.
You've already said a few things
that I think are really interesting.
Obviously the audience for the show
are API developers, so I think I
wanna pick your brain about the
api generation side of things.
But one thing that I've experienced
over the past year or so is that a
lot of developers seem to wanna lean
away from low-code tools because it
doesn't validate their desire to be
deep in the, the weeds moving around
zeros and ones, and, you know, being
the smart guy, building smart things.
And I feel like there, there's a round
of tools that are coming in this sort of
revolution of like focusing on DevX and
productivity as opposed to focusing on
the genius behind the keyboard, so to say.
That's, that's a really
interesting, like shift in mindset.
So what I'm curious to hear from you
is, have you found it challenging
to explain to, to sort of hardcore
developers that low-code tools are
something they should play around with?
Constantin: Yes and no.
So, in my experience and after talking
to couple of hundred deaths about
this, there seems to be a pretty
clear distinction between two types of
developers in my experience at least.
The one type of developer is.
More focused on the outcome.
So, so more of the like
maker type, I would say.
They don't necessarily care too
much about how they get there.
All they care about is getting there.
So for this group, it's extremely easy.
Usually there's very little
skeptics about local tools.
But then you have the other group.
, which is what I maybe would call the,
the coding purists who are really
in love with architecting with like
thinking about I don't know, how can we
refactor it, is to make it like even more
efficient and for them it's definitely
more, more difficult, I would say.
but I think as soon as developers
realize that you are like pulling on
in the same direction and not trying
to work against each other things
are becoming much, much easier and.
Also like we are not product guys
that kind of stumble into this.
Like again, we are builders and
programmers at heart ourselves.
So we are kind of building this tool
for ourselves as an audience as well,
and wanna build it in a way that
yeah, we would've wanted to use it.
So, yeah, really trying to, to
incorporate that feedback that we
get, especially from the second group.
Mike: Yeah, that's really solid.
I think the hardcore sort of coding
purists are a really interesting
audience too because they are
really good at sniffing out tools
that are valuable for them and.
Maybe it's just getting over that hump
of like, you're not just being sold
to, but you're being given something
that multiplies your powers is a
really interesting thing to do there.
So can you tell me a little bit about
the API generation side of the house?
What exactly can Fast Gen do?
Constantin: Yeah.
So with Fast Gen you can essentially
create APIs at a click of a button.
So the first thing a user sees when he
opens our interface is kind of this drag
and drop interface with a flow chart.
And so you can select from any type of
arrest endpoint that you wanna build.
You can manage your authentication.
We do input validation and
then you can start pulling
in your what we call actions.
And there are different types of actions.
So, One are the flow control blocks,
conditions, if else switch for whatever.
Then we have native integrations.
So you can up your own
server and put it in there.
You can send General HTTP requests
to third party services, which is
extremely powerful if you want to
integrate something where we haven't
built out direct integration with yet.
And then that's the third part you pull
in the direct integrations we have.
So say you wanna send an email with
SendGrid, you just pop in your API
key, pull in the block into the
builder and then do what you wanna do.
And then all that's left as you
hit deploy and you have a life
endpoint that will return whatever
logic you've built inside it.
And I think one thing I want to
add here is that again, trying
to be really developer focused.
Right now we are working on
allowing you to and also ride all
of this in kind of a conflict file.
So similar to how with Terraform you
would specify your DevOps logic and code.
So yeah, developers are not
limited to using the interface,
but can do so if they wanna do.
Mike: Yeah.
I see.
So there's some sort of, I don't know,
edited in your it edit in your ide
opportunity here with the config files.
I imagine that probably allows you to
use source control to manage the state
of your workflows, APIs within fast gen.
Is that right?
Constantin: That is exactly right.
So there's two options for users.
One, we offer versioning
directly in the tool itself.
So every time you're save your endpoint,
you deploy it, it automatically creates a
version and so you can easily roll back.
But if you want to, you can totally
version it yourself as well.
Mike: a little bit of
something for everyone there.
I think that works well with the
ethos of kind of being low code too.
Don't necessarily have to require
folks to have a full, you know, get.
Support system strung up there.
Okay, so you're generating API
endpoints for sort of whatever I might
need as, as kind of your end user.
What are some of the typical use
cases you're seeing for this?
Constantin: Yeah, so they are, we
have really diverse use cases, so
and that's also worth mentioning.
We do have customers that are not
even focused on the AP API part,
but also on the automation part.
So, We have started or launched
only I think a month ago
now pretty much to the date.
And very selectively picked 15 design
partners that we let on the platform
and that are currently building with it.
And there we have from the small startup
that are actually building their.
MVP with us as a, as their full backend.
Two more enterprisey organizations
just building not around their car but
like for example, notification flows.
We have on company doing that right now.
And then the third type of,
of user is for agencies.
This also seems to be pretty
interesting, empowering them to.
Build stuff that they couldn't
before, was more more complex before.
Yeah, from APIs to simple automations.
Pretty much yeah, wild
Mike: Yeah,
Constantin: things right now.
Mike: certainly.
Yeah.
That . It's interesting because it
feels like that gives you so many
different directions you can go in.
So what does your onboarding look like?
What is the hello world of, of something
that has so many potential use cases?
Constantin: Yeah.
so because it has so many different
use cases and because it is such an
open field currently when onboarding
a customer, we talk to them beforehand
directly and trying to figure out what
are you actually trying to use this for?
And we even go a step further
and pre-build the first.
Flow or the first automation or
the first a p i for the customer,
with the customer together.
So, that way they get to see
how things work on the platform.
They directly get like, support for
whatever they're trying to build, and
then they're off on their own pretty much
to, to further build out these things.
Mike: Yeah.
Okay.
So I want to know a little bit
about how you're building this.
What, what is sort of powering fast gen?
Like what is your engineering team using?
Constantin: Yeah.
So the backend we, this
time we chose to go with.
Using fiber, which for those not
familiar, is super similar to
Express, which we were using at Blair.
Took a bit of time to get used to
go coming from JS, but yeah, I think
it's worth it in terms of speed.
Then front end we're using View
have been using that at Blair.
Had a great time there
and continued using that.
And then in terms of our for the
backend architecture, we are.
Heavily using Centri, FUO
as a messaging server.
Rabbit mq In terms of our event service.
We have built that on our own.
We are thinking about temporal
or integrating temporal.
Not sure if we'll go for that yet,
but yeah, that's like a rough overview
of what we are doing in terms of
Mike: Yeah.
Okay.
I'm, I'm hearing a lot of
folks lately exploring go for
performance benefits alone.
And I think that's something that
a lot of developers are starting
to have in their quiver, at least
to have some experience with it.
For a lot of reasons like that.
And I would imagine when you're doing
things like powering workflows that
need to be both fairly performant and
also, you know, like dead reliable go
is probably a good option there too.
Constantin: Yeah, that was
exactly our line of reasoning
for why we went with that.
Mike: So switching back then to the
API generation side of things you're
generating rest endpoints, presumably from
your the API builder are the I'm trying
to think of how API devs will, will sort
of want to validate this, this themselves.
But I'm, what I'm curious
about, I guess are two things.
Is are your APIs sort of compliant
with something like Open api?
Is there a way to spit out a
spec or something like that?
And then is there a way to test the APIs
that are generated by fast Gen to make
sure that they're working correctly?
Constantin: Yes.
So first question we are not
able to, users are not able to
generate their API specs with it
yet, although that is definitely.
on the roadmap and has been requested
from our design partners already.
When it comes to testing we just launched
that feature yesterday, which is with what
we call the debug mode which allows users
to like just toggle into a different mode.
And then you can see, you
can test run your APIs.
You can test it with different
input data and you visually see,
how it goes through the flow.
If one of the actions errors
out, you directly see it, you
see all the context data of all
of the actions within that flow.
But if you don't wanna use our
tool again there's just one
button to test with postman.
and so you can, you can do that
as well if you're more used
to that or preferring that.
Overusing our debugger.
Mike: Okay.
That at least feels like you know,
the process of building these things,
especially on the, the like drag and
drop experience for building our APIs.
I think a lot of people wanna see
kind of, Like viscerally see that the
data is flowing through as expected
and you know, have things turn red
on screen or whatever it may be when
things aren't working correctly.
Yeah, that's really interesting.
So why don't we talk a little bit
about the workflow side of things too.
What are some of the, I don't
know, the interesting things
about the workflow product.
Constantin: Yeah.
So with the workflows right now,
we offer two different types of
workflows and they are differentiated
by what kind of trigger they use.
So one is a pretty simple
chron, you just select whatever
interval you want it to run.
And the other is a event-based workflow.
And how that works is.
In all of your APIs or in your workflows,
at any point, you can emit custom events.
So then in the workflow side, again, you
can create a workflow that listens to
that kind of event to run a workflow.
And that kind of allows users to
further modularize their APIs,
their workflows, and, kind of, yeah,
pull things apart a little bit.
But apart from that, It's really
similar to the API builder, so you
have the same kind of logic available.
You have the same kind
of actions available.
I think right now, honestly, the
only difference is that you are not
available to send like success or error
responses as obviously you don't need it.
Yeah, apart from that, really
similar to, to the API builder,
Mike: Yeah.
Okay.
So when you say event-based, that
is essentially saying that I can
send an H A T P request to trigger
one of these from something else.
Is that right?
Constantin: Well, yeah.
Well, yes, for that, I guess I would
rather go with an api just have an
Mike: Right.
Constantin: app and
then just trigger that.
Right.
But,
Mike: Of course.
That makes sense.
Yeah.
Yeah.
Constantin: but yeah, you can, you can
emit events within your, your flows
and then when that event gets emitted,
another workflow can get triggered.
It listens to that event
that gets submitted.
Mike: Yeah.
Okay.
It seems to me that it's probably
likely that fast gen is using fast
gen for some interesting things
on, on your side of the defense.
Is that right?
Are you using fast gen
for automations at home?
Constantin: Yes.
Mike: Yeah.
Constantin: it for, for
automations internally.
We are not using it to build the
core product of course, as I don't
think that would be a great idea.
Mike: It'd be a little challenging.
Yeah.
Constantin: but obviously all of
our other automations that we have,
like tons of slack bots that we
built with fast gen, I don't know,
simple things like auto archiving or.
PR channels, stuff like that.
But yeah, obviously
heavily using our own tool.
Mike: Sure.
Yeah, I think that's probably a
good sign that you like what you're
building, but also you know, forcing
yourself to experience both sides of
building and using it is, is a good
thing for iterating on the product too.
So what things are you working
on right now for fast gen?
Constantin: Yeah.
So a couple things that
that we have on our mind.
One, as I already mentioned
auto generating your API
docs is, is one of these.
then I think another feature that
would be really interesting to many
of our users, Is having templates or
recipes, I mentioned before, everything
you build with fast gen you have
a conflict file in the background.
And what we notice is that a lot of
our customers are essentially building
the same things just adapted and
Mike: Yeah.
Constantin: for, for their own company.
So why should we force users to build
the same thing over and over again?
Why don't we just offer it as
like a template or a recipe.
So they have like a library of
different, already existing or
pre-built APIs or workflows.
They can browse, they can search through,
and then just add them to the project,
change out API keys or whatever they
need to change to make it work for them.
And then built with that.
And then another feature that
I find is really interesting.
Is I've been experimenting a bit with or
with allowing users or allowing you to
generate APIs based on natural language.
So obviously with the whole L l m
hype and everything going around,
Mike: right.
Constantin: that got us thinking
as well, and surprisingly it works.
Pretty, pretty well already.
So that's something to
look forward to as well.
I think that you can just say, I want
an API that does that, and then we
give you a pre-generated workflow and
you just added and adapt the little
things that you need to change.
Mike: I can imagine a whole lot of
people who are listening to this
would be very interested in that.
That sounds super
interesting, especially for.
, gosh, I mean, everything under
the sun from like developer
advocates just wanting to show off.
Here's how you would do
X with Y platform, right?
Like implement a weather thing
in view or a to-do list in,
you know, laville, whatever.
But certainly sometimes it's just easier
to say what you wanna do than to envision
how you might connect the dots together.
Especially for educating people and
building you know, fresh products.
That's, that's, that's super cool.
I'm really interested in seeing that.
So at this point, fast gen is in, you
said it's a closed beta at the moment.
Constantin: It is, yes.
Mike: Yeah.
Constantin: working towards opening it up.
It will take a couple more weeks, but
I expect that by probably middle to end
of May we will open up to our open beta
where people can sign up themselves.
Mike: Okay.
Yeah, I think that'll be really exciting.
What sort of feedback are you looking
for from developers who may be
interested in the product at the moment?
Constantin: Yeah, so, so that's
actually one of the, the key
things we're looking for.
We've obviously greatly value the feedback
of customers and potential customers.
and we, we'd love to hear about the
specific aspects that fa fast gen that
they find most valuable, and obviously
any feature that they think would
make their experience even better.
And additionally to that we're
always interested in learning
about the unique use cases that
customers might want to use it.
You mentioned it before a lot of
different that you could use fast gen for.
But the more we hear about what kind
of things people want to, to solve and
what kind of specific challenges they
have, where fast gen might come in,
that usually is really helpful for us.
Mike: Yeah, I'd imagine things like your,
I forget the exact word you used before,
maybe direct integrations, things with
like your, your coach built integrations
with say, slack or whatever it may be.
I, I'm guessing you'll probably get a mile
long list of those from people, things
that they wanted to talk to natively.
Constantin: Please.
Mike: I.
Constantin: I'm, I'm looking forward
Mike: Yeah.
Yeah, I think so too.
Oh, what about trying to think of
like, people who are building the
services that might make sense to
be an integration for fast gen.
Is there a process for that?
Constantin: Yes, absolutely.
So if you are building a service
and would like to see yourself being
created to fast gen, please reach out.
We have Member that is exclusively
focused on, on building out the
integration side of things right now.
And obviously we do
have a backlog already.
but yeah, which is prioritizing
on, on what gets requested the
most and then going through and,
and trying to, to build that.
Mike: Sure.
Yeah, that makes a lot of sense.
I, I feel like that is, will be an endless
list and especially people who find value
in this will have pretty good feedback
for you on the things that they're
interested in or missing or whatever.
Yeah.
Okay.
So let's see what else, what, what
what are, what do you see as sort
of the long term future of fast gen?
What are you trying to, I
guess solve in the long run?
Constantin: the major idea
is, is to empower people.
And by empowering I I not
only mean like and non devs.
Which it certainly can use the platform.
Obviously it's very helpful for them, but
also empowering developers and reducing
the friction between members in the team.
So I would imagine a future where, both
the devs and the maybe the ops team are
using fast gen and the same platform.
For, for different use cases, but
also able to reduce the, the friction
and the borders between teams.
And what I mean by that, like a common
example would be we, we saw before
that whenever you limit ability to look
into stuff or change stuff bottleneck
it on, on the developers, becomes
much slower and much more of a drag.
Mike: Yeah.
Constantin: allowing a non-techie to just
observe or see what a kind of workflow
does or an API does, or maybe even allow
'em to make changes directly greatly
reduces friction in teams internally
greatly reduce friction for us internally.
And that's what I hope fast
gen will be able to achieve
for other companies as well.
Mike: Sure.
Yeah, that makes a whole lot of sense.
I, I bring this up fairly often on
the show, but I in a past life I
worked for Stripe as a developer
advocate doing payments things there.
And one of the things that I found
doing advocacy work for payments
is that Payments sound very simple,
but there are like a lot of things
that can happen in the workflow
of a payment that can go wrong.
And so it's really helpful to give
people a visualization for here's,
here's the entire workflow of what, what
it takes to swipe a, a credit card and
move money from one account to another.
And.
. The really, the easiest example of
that is if you swipe your credit card
and it gets declined, what do I do?
Right?
There's a workflow there
that has to happen.
And one of the things that I was exploring
as part of like the educational stuff
I was doing was just showing people a
diagram of the workflow of, of here's
what your payment process looks like.
That can be applied to any other
sort of workflow based problem
solving, but thinking about your
template Recipe product that you're
starting to build out here too.
Those recipes will also sort of
become like a checklist for teams
that these are the things that we need
to get done to implement X feature.
And showing that here's the shape of
the workflow to a PM or to a business
stakeholder, something like that
puts a lot more perspective into the
scoping process, into making sure that
we know what the dev team is going
to need to do to get this all done.
Or even just, you know, the low-code
integrator team, whoever that
may be building this stuff out.
. It's very, maybe it's not surprising, but
it's very interesting to see how people.
Think through problems differently when
they have visuals placed in front of them.
And for me, that's one of my favorite
things about low-code tools is
that you know, constantly you and
I are fairly technical people.
We've probably spent a lot of time yelling
at computers and trying to get that
console logged to show what you want.
But for someone who's never done this,
it's really hard to convey what the
problem space looks like and what you're
actually doing when you're sitting at
your computer all day, you know, downing
red Bulls and, and scratching your head.
. I think that's a really cool
opportunity and I think it's
something that a lot of folks who've
built things can identify with.
Often you feel like you're under the
gun, you know, to get things done
faster than is realistic because it just
seems so simple to go take a payment.
I think there's a big
opportunity for you there.
That's, that's really interesting.
Constantin: Absolutely.
I couldn't have said it better.
You chose way better words than
I would've used to Describe that
Mike: I.
That's right.
I won't take credit for it.
Actually one of the things that I'll share
in the show notes in addition to fast
gen contact information and where to find
you and things like that at some point
in the past I wrote along diatribe on why
developers should embrace low-code tools.
And I think that's a really valuable
thing just to kind of like have in your
back pocket as like, it's empowering.
It's really cool to see, and it makes all
of our lives easier to a certain extent.
So Constantine, I believe, did I
see that you are currently in YC in
the, the winter program for 2023.
What, how long does that program last?
What, what comes at the end of that?
Constantin: At the end of the program,
demo day comes, which already happened
actually last week or the week
Mike: It did.
Yeah.
Okay.
Constantin: So we are, we are through
with our, our second wife Iran now.
But yeah, as always was a extremely
valuable experience and yeah,
couldn't recommend it more due to
maybe any listeners trying on the
edger on the fence about doing we.
Mike: Yeah.
Got it, got it.
Well, congratulations.
I'm sure that's quite
the thing to run through.
For the folks listening to the show,
what's the best way to find fast gen
and what's the best way to find you?
Constantin: Yeah.
So to find fast gen, really
simple, just go to fast gen.com.
Feel free to reach out to me directly.
My email is Constantine
with a c fast gen.com.
And that's also where you find me.
I'm not really that
active on social media.
You'll find me on LinkedIn.
I have a Twitter account, but
not really active on there.
Yeah, best way would
probably be via email.
Mike: Sure thing.
Yeah, that's great.
I'll make sure I include all
of that in the show notes.
And Constantine, it's been
super, super cool talking to you.
I'm really interested to hear
sort of the future of your product
and would love to have you come
back and chat with us anytime.
Especially if you've got launches
and things like that to talk about.
I think it'll be really
interesting to see.
And I'm, I'm definitely interested for
the folks listening to the show and
hearing what you think about the product
and uses you might have for an a low-code
tool that helps generate APIs as well.
So p please feel free to to
get in touch with us on the
site APIs you won't hate.com.
You can email me, Mike APIs you won't
hate.com, and I'm also on Mastodon and
LinkedIn in a bunch of other places.
Constantine Schreiber, thanks
so much for being here.
It's been a real pleasure.
I've had a great time chatting with you.
Constantin: Thank you Mike.
Thanks for inviting.
It has been a pleasure and
Mike: You
Constantin: a good day.
Mike: of course.
Take care.