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.
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.