Subscribe
Share
Share
Embed
Each episode is a conversation between me, Eli Finer, and a budding entrepreneur, indie hacker, or solo founder.
We focus on the current biggest challenge (hint: it's never in the code) and the best next step to take (hint: it's usually not adding another feature).
If you want to be a guest on the show please reach out to me on Twitter @finereli.
Ken: i'm going to start writing some
of the documentation portions, right?
So I envision more walkthrough stuff
because my experience has been My
persona, the profile that I'm, going
after is a developer that I call Jeff.
Jeff doesn't want to know how it works.
And if Jeff has a problem,
Jeff wants a slide deck.
Jeff wants a PDF to walk through
how to solve that problem.
Eli Intro: /Hey guys, my name
is Eli Finer, and this is "Stop
Building" where I do my best to
get founders to set aside their IDE
and talk to some potential users.
This rarely works, but I love
these conversations anyway.
Eli: Hey Ken.
So why don't you start.
By telling me a little bit about
what you're building why you're
building, uh, uh, what kind of
problems you face in marketing?
Just like a little bit of an
expose on what's going on.
Ken: So right now I'm in the phase of.
spec'd out my MVP, started
building some things, and I said,
Oh, because everybody says that,
let's start marketing something.
so I got on Twitter, and I had it.
Started using it, started posting,
and I guess that's where I am.
in terms of...
what people do is there
a need for this product?
Yes, I work for a very large company.
I still do 95 on that
screen over there with that.
and this is what they would need, right?
I built something very similar for them.
and they moved me to another project.
So now I'm free to work on it.
a similar concept in my own time,
but I'm doing completely different,
call it nine to five work.
So there's no conflict.
so the goal, my goal is to automate.
DevOps configurations, right?
So we have lots of, developers, the
developers have business requirements,
they know data models, they know the
applications, and then somebody comes in
and says, you automate everything now.
DevOps go and we're talking ETL developers
report writers, and they're up here.
They're not configuring, get lab,
you give them a Jenkins log and
say here and make a Jenkins file.
What are you talking about?
I just learned it.
I'm not saying they're bad developers.
I'm just saying that they're
at a much higher level.
From a, what their
understanding is, right?
Their tools are all encompassing.
They work in a workflow, in a
tool, their check ins checkouts
happen within the tool.
They get paid to know business processes.
They don't get paid to know,
they pay claims, right?
It's insurance company, they
pay claims, that's their job.
They know why and when to pay claims.
They don't know anything about scripting.
They know nothing about build
jobs, YAML stages, phases,
They just don't want to know.
the software slash website that
I have is, starting with NET,
because it's the de facto corporate
standard these days, right?
It's the new Java.
you fill out a form, you get a
configuration, probably a copy,
and if you project, you're done.
Oh, that's your automation solving the
problem, not teaching them anything.
The related portion of that is while
they're doing that work, there's going
to be, this is the part that I have to
work on now, the links and stuff here.
This is how you learn this stuff because
they're going to want to learn it.
Maybe, I've been doing for
five years for this company.
One person wanted to learn it.
The rest just wanted to work.
They don't care how it's done.
They just, and in this particular
case, the software that we wrote
doesn't give them configuration.
It doesn't do the, it literally
does it for them, right?
we have a web app, they go,
I got a project, here it is.
And they hit a button, and then
everything is automated for them.
They don't have to do any of the work.
They like that.
That's the way it goes.
I want to deploy to this server.
Button.
So what I'm proposing is similar
workflow, but give them the actual
configuration at the pace that it is.
I'm not a website.
It's not internal clear
infrastructure, like our applications.
Awesome.
So in terms of marketing, I've tweeted
Eli: and how has that been going?
I
Ken: had a hundred followers.
I did, the tweet, what is it?
T S 30 tweet.
TweetStreet30, which is very
good for me learning, things like
that, what I'll call the basics.
and, I picked up a bunch of followers,
I think that are core to what I do.
and then for the past month I've
tried to Don't like, I was doing,
I think, four tweets per day plus a
bunch of comments and it was like,
no, you don't need to comment on it.
You just need to comment.
Forget about your tweets.
I did that for a month and
got exactly what I expected.
Nothing.
So I'm going back to the, core,
because what I was trying to do
is get the ideas across from an
automation perspective, right?
that, people don't want
to learn how to do it.
They just want done because they have
a boss sitting on their head saying
this project has been done by Thursday.
I don't care.
Get it done.
So if somebody can go click, copy, paste.
Done all day.
They'll use that all day long.
Because they do it every day.
Eli: So is your question I got this thing
that I built for a company being used.
It's used well.
How do I market it?
How do I sell it to other companies?
I
Ken: guess my question is like
i'm going to start writing some of
the documentation portions, right?
So I envision more walkthrough stuff
because my experience has been My
persona, the profile that I'm, going
after is a developer that I call Jeff.
Jeff doesn't want to know how it works.
And if Jeff has a problem,
Jeff wants a slide deck.
Jeff wants a PDF to walk through
how to solve that problem.
he doesn't want anything else.
And you give him a step by
step tutorial, he'll do it.
And if it deviates...
scenario deviates from the
tutorial, they'll call you back.
That has been my experience
for approximately 10 years.
these applications that are
going to configure Various
things initially Jenkins only.
net, plus SQL files, right?
So those are the three targets,
that I call them automation.
There's the help on the side
that's going to help them.
That is my plan that is the marketing.
So I have an app that it, here's like a
walkthrough on how to do it in Jenkins.
Here's the walkthrough on, whatever
the tutorials are, get them there.
So my thought process is.
That's the marketing, right?
We support this now.
And here's the, you can break out
pieces of that from the perspective
of, Hey, did you know you could
do this, get all the things.
And that's as far as I got.
Eli: So the features of the
marketing, you build a feature, you
Ken: publish it somewhere.
I think the documentation
is, like publishing of the
documentation is the marketing.
That was my thought that,
cause I can't show, I can show
somebody a picture, right?
Pictures are cool, but I could say, if
you want to do this, follow this, right?
That, on Twitter, it'd be like,
here's a bunch of steps, but then
you can go download the actual thing.
Which would be PDF slash
PowerPoint, whatever the format is.
And that's the so called
marketing again, as far as I got.
Eli: It's a really interesting
problem because you actually do know
the people you are marketing to.
and you've worked with
these people right here.
These are like app developers and
you're the DevOps guy, providing
them service within a single company.
In my understanding.
And after, after doing this manually for
a bunch of time, for a bunch of years,
you built some layers of automation
to provide them that service and give
them that script, those scripts, and
even set up the things they need,
with as little, effort as possible.
It's just a web
Ken: form, they type in some stuff,
Eli: and it happens.
So here's the first, so
here's the first question.
Is your client a developer?
Is it a DevOps person who wants to stop
doing things manually for the developers?
Is it a development manager who oversees
both app developers and DevOps, who wants
things to move quicker and smoother?
Who's...
Who
Ken: cares?
I think there's, the customer is
the director that's buying software.
The user is Jeff, who just found
the website because he's got
to be done, type his stuff in.
And it's nothing, it's like project
name, branch, there's not, it's not
magical stuff, and it just produces
what he needs for the target.
That he would need, Oh, we're
using GitLab, drop down GitLab,
boop, there's the config for that.
he just copies and pastes and
he's done, he gets the job done.
so in terms of paying for it, now
you get into, I don't know, right?
MVP, there's no save button, there's
no anything, it just produces
it, you copy it and move on.
The thought process being that if there's
the associated walkthroughs and help.
the website will gain traffic, right?
There's some, there has to be
some, blog or something that's
going to bring people in.
it gives you that, that exposure,
but in terms of saving it.
in terms of charging for it, the model, I
haven't thought that through yet, right?
I figured, oh, we'd have a save button
because, I didn't even know if people are
actually going to use it, I know they use
it every day because they're in a company,
70, 000 people and, like 10, 000 of them
are developers and they're just like.
I don't want to do this other crap.
That's nonsense, right?
literally, one person has reached out
to be like, Hey, how does that work?
Everybody else just uses it.
They don't care.
And to me, that was like a revelation.
I would be a guy wanting
to know how it works.
what's going on in there?
yeah.
Nobody cares.
They're like, the web app.
Like this field doesn't work, right?
You're like, all right, why are you
putting spaces in your file names?
it's like they don't care.
So I was like, I wonder how many more
people are in the world that don't care.
And my bet is there's a
lot more that don't care.
Eli: there's something, it seems to be a
very big difference between the thing that
you build, for, for a large 000 people
in it, where the marketing for Using
that tool is the dev ops team, right?
Oh, you need to do to get this done.
Here's the link
Ken: Yeah, I don't think
it's a dev ops team.
I think it's not developer.
Eli: Sure other developers you
need to do Yeah, it's not like
it's like it knows how to do it.
Yeah.
No This so here's my kind
of perspective on this.
an internal tool has A certain
dynamic of how it gets distributed
and used within the company, right?
it's still quote unquote, marketing.
People need to learn about it.
but within an organization, there is
both, a little bit of virality or maybe a
lot, like one developer tried to use it.
Oh, it's cool.
And, he tells the other people on his
team, listen, if you need to do this.
Use this link or someone else, on a daily
standup asks, Hey, how do I do this thing?
And it's Oh, go do this website.
You got everything there, right?
So that there's a little bit
of, or maybe a lot of virality.
There's also a lot of trust
because it's an internal tool.
It's built to support the developers
within this particular organization,
It might even be at some point coming
from, through the layers of bureaucracy.
Exactly.
This is how you do these things.
That's happened.
Obviously.
Cause when it works.
It's like quicker than reaching
out to anybody in DevOps or
trying to figure it out yourself.
And like you said, it's a very large
organization, lots of developers,
it's impossible for all of them
to get support from usually a
tiny DevOps kind of expert team.
So this kind of replaces that.
And the leap from that to a
public service, that is online.
Is not clear, right?
Because you have the thing that's
working in an organization is you have
a concentration of people with the same
kind of needs, at the same time in the
same place that are also talking to
each other because they are in meetings
with each other all the time, right?
So there is a lot of exchange of
information going and it becomes
this internal kind of company lore
that this is the way things are done.
so and also it replaces So The
previous method of doing this, which
is asking people and looking for
someone who actually knows how to do
this, which is really bothersome to
the people who know how to do this.
So the people who do know how to do
this have a very powerful incentive
to stop explaining people how to
do this, but to send them a link.
So I imagine the link or the
various links get sent a lot over
Slack or email or whatever it is,
Microsoft teams or whatever it is
that's been carried in use there.
So you have a natural dissemination
of this within the company when you go
public It is no longer the case that you
put something online and people find it.
I, my first startup was,
almost 20 years ago.
we build the thing, we put a web
page, on and people just came to us.
There was no need for anything
more specific than that.
And we get.
About a problem that we needed to solve.
We solved the problem, put up a web page.
It was, it was the good old days.
these good old days are gone because the
barrier of entry to create an app, to,
to build a system, to set up a landing
page, to do all these things is so low
and the barrier of entry to do even like
basic or even somewhat sophisticated
SEO is so low that you're competing.
with impossible odds for people to
find you unless you are you really
understand the niche the people looking
for it like the wording they would use
the whole thing so unfortunately your
initial approach of I'll just put it
out there and I'll add documentation
and bits and people will just find it.
That's not even true for questions
on Stack Overflow anymore, right?
So even that doesn't just work.
You answer a question on Stack
Overflow, people don't necessarily
stumble on it because the search is
not working as well as it used to.
And with the new kind of push
towards, chat GPT and other, AIs.
Search is not even the primary way people
are looking for these things, right?
So these days, like how do I
configure Jenkins to do this and this?
And you can get an answer from shared GPT.
The problem is it's going to be wrong
in subtle ways that you can't figure
out if you don't know what you're doing.
So there's value to what you're offering.
but that's not the way people seem to
be looking for that information anymore.
On the other hand, your experience
and the thing you built.
is actually for very large organizations
with a very painful problem of this kind.
Now, you're a solo guy.
So selling to large organizations
is going to be difficult.
But let's just, but let's just
play around with this for a second
because it's the obvious fit, right?
If the obvious fit is another organization
with, tens of thousands of people and
maybe, five or ten thousand developers
in the organization, maybe a...
and maybe a hundred people who actually
know how to config these things
were busy and working 14 hour days.
So you, just in theory, if you find
another organization and you find an
in and you get them to trust you to
be able to build this out for them
and all that, you basically, you make
two sales in your set for life, right?
That's the kind of, that's
the kind of thing it is now.
You're not just a guy from the street
who just built a thing and thinks
he can sell it to a corporation.
You...
You grew up within it.
You know how it works from within.
Your, your white hair and your
white beard gives you credibility.
it also shows you've been doing
this for a number of years, or
I assume a number of decades.
like I have, and Free to be exact.
Yes, and you have a very successful
deployment of this thing, or let's
say a similar thing, a similar idea,
at a company you have worked So the
simplest way to, to do this, and
that is not what you had in mind.
So push back on it, if you want,
but the simplest way to do this is
to find a way to build a similar
project custom built for a different
large organization that is adjacent.
Adjacent could be in the same
industry or even better if
someone from say the DevOps team.
actually moves from one to the other,
gets an upgrade from being a, whatever,
like a tech person to a lead position,
or a low level, or mid level management
kind of to a higher position at a similar
company, where they would, do, guys, are
you still answering these questions on
Microsoft Team manually sending scripts?
There's a way to do this.
And here I know this guy, Kenneth, who
can build it for us, let's hire him.
he'll set it up, and then we
won't need to do it anymore.
Something like that.
Something where, and obviously,
you'll reuse the code, you'll reuse
the knowledge, and you have built
it for two companies, and then you
can build it for the third, and you
can maybe build it for the fourth.
but these are massive projects.
In terms of, actually in terms
of payment, not in terms of work
necessarily, because the work, a lot of
the work has been done already, right?
You like, you're, and what hasn't been
done, you have thought deeply about it.
So there's a lot of it that's ready.
that's the kind of the obvious way for
this to work, because there's obvious,
I'm always talking about product market
fit and what we as developers do so much.
it's awful to look at, is that we find
something that has product market fit, and
then we say, but I want something else.
Yeah.
and I want something else because I
have this idea of what a startup is, or
what a company is, or what my service
could be like, or what my passive
income is going to be like, right?
Like we're looking for these things.
So we take something that works and we
turn it into something that doesn't work.
And I've done this myself.
Ken: I've done it twice.
Eli: So in this case, what you have
that's working is a custom tailored
solution for a very large organization
that is pushed, and I'm guessing here,
but that is pushed and nudged by the
people who used to do this manually.
Ken: we pushed them.
Because, big org, Windows
server guys, Linux server guys,
like just teams, big silos.
so we were brought in from
development teams and bringing
it up because they were done
Eli: making it.
Oh, so you came in from like the
develop, from the app development
side, but you have, you know how
these things, how to develop.
Ken: I used to be at a small company.
Eli: Where you did everything where I
Ken: did the DevOps stuff hired here.
My reasoning being That, there's
more bigger companies than there
are small software companies, right?
at least where I live.
So
Eli: this is all, did you need to
convince the dev ops team to adopt?
I was hired
Ken: for dev ops
Eli: team.
Oh,
Ken: okay.
Then we built that out to max five people.
And then our company was acquired by this.
And we were about 5, 000,
which was a very nice size.
And then we were acquired by
the very large national company.
So now we're here and they're like,
Oh, you need to do this over here.
Now this project is no longer because
the New York health plan, they use that.
That's not now we're over
here doing other things for.
Much larger groups, right?
so the group I'm in now has
600 developers in it, right?
That's the group.
It's
Eli: yeah, it's big organizations.
It's just the thing is more exactly.
And what worked very nicely in that.
kind of environment when you're,
when you try to translate into
the public sphere, and the public
internet, a couple of things happen.
First of all, the money disappears, right?
getting people to pay, like at the
very least you were being paid a
full time salary to work on this.
But so there was money in it.
And if you were a contractor
or an external company doing
this for them, they would have.
Paid five or 10 times more
because, the necessity is there.
if you can do it for a salary, then
you do it for a salary, but it, if
they hire an outside someone to do it,
then it usually costs just a lot more.
it's also a different pocket , right?
Like head count and actual
business expenses are not the same.
Yeah.
Budget line.
So it's easier to spend more there.
and when you move to the public
sphere and you want to offer this to
every developer, A few things change.
First, like I said, money disappears.
You're no longer tied into what
makes money for the company.
You're just trying, like it's
dev who works for a company.
Like how can, employees typically
don't spend their own money on tools.
So you instantly lose that.
the second thing you lose is
large corporations don't typically
trust the broader internet.
So you're targeting smaller companies.
Smaller companies may not have
the same pain in the same way.
They may not have as many projects
going on at the same time, that
require, the kind of DevOps setup.
And therefore, this does not occur
as frequently, and therefore,
it's not that big of a deal.
you lose that kind of, focus and
the product market fit you had.
and the third thing I think
you're losing is trust.
Because, If when you build it for an
organization, for example, that works
with NET and certain setups and certainly,
paid for certain tools and there's
a certain technological environment
and there's a certain philosophical
environment about how things are set up
and how they're used, then there is a
certain amount of trust that whatever
you built, whatever the website does
and whatever it offers works within
the context of the organization.
It's, even if it's not the official tool,
it's this is the way things are done.
And therefore, people are, and this is
a guess, but I think it's an educated
guess, people would be happy to trust
the system to offer the right scripts.
much harder,
Ken: exactly.
If my stuff breaks at this
point, go, hey, his stuff broke.
Make it fixes, then I'll
Eli: get my job done.
Exactly.
And within the context of, a
public service online, which
again, probably is free.
then the trust is, needs to be earned
and earning trust is a very slow process.
many people need to say that this is
freaking awesome and it always delivers
the right result across a very broad
range of technologies in a very broad
range of circumstances, which brings
us to the fourth point that you now
need to solve for a very broad set of
circumstances, which is much harder.
Because, different companies have
different setups, different ways to
even spin up boxes, even that, everyone
has their own peculiar way, they
have their own security measures in
place, their own philosophies, so the
transition is definitely non trivial.
and that's why my kind of previous
idea was, it would probably
replicate well to organizations in
the same style, of the same size,
who have the same kind of problem.
the problem there is obviously,
the longer sales cycle, the,
how do you get a foot in?
Who do you have the users.
But you have the customers who are
paying, these are different people,
they speak a different language.
Convincing users to use and
convincing managers to pay
are two very distinct things.
and maybe you would even need to
partner with someone who already
sells to organizations like that.
Because going solo at it is not easy.
It's it's just not, I'm
not an enterprise salesman.
Exactly.
Exactly.
And you're not likely to become
one just because you need to.
Yeah.
I, I could teach you how to sell to
small companies and maybe consumers.
I couldn't help you and I don't
think you'd want to, become.
Because, yeah, and the
sales cycles are very long.
Oh, I've been on the buying side.
Yeah, exactly.
Exactly.
Yeah.
it takes six months to approve a
budget and then the year is over
and you're over to the next budget.
And then the whole cycle starts again.
The whole thing is, it's
just, it's a different style.
very few solo entrepreneurs
are able to make that work.
and, but again, if you do make that work.
It's from within, the people within
this organization through your network
and through just your technical
connections and the people, you know,
people in adjacent organizations.
And then you approach them and then, maybe
you make a POC there, which is free and
doesn't require any budget or approval.
And you make it work within a small
team within that organization.
And it's Oh, this is really awesome.
Let's expand that.
So on and so forth, but the other
thing is that in large organizations,
it's never a shrink wrap product.
Like it just never works.
It's always customized.
It's always with, an SLA
and support and all that.
So it's, that's the kind of
thing, you're looking at it.
And it doesn't sound like what you want.
The other.
The other direction in which you could
take this, and this is actually a
little more than we can talk, here,
is to take the thing that you built,
break it down into its individual
features or individual things that it
can do, and then look at every feature
individually and see who it can be useful
for and what kind of circumstances.
and look for completely other ways
this could be used and framed.
Like I can't tell you what that's
going to be because it's a, it's
like an exploratory process.
but what you can find is a reframing
or repositioning of what you've
built for a different market,
for a different kind of need.
And again, it's, I'm being a little
vague right now, on purpose, but also
not on purpose because I don't have
an idea what the result would be.
I have this little five day
course that can, take you
through the steps, if you want.
It's like a short kind of email course,
videos, a little bit of exercises that
can take you some of the way through that.
and the result is oh,
no, here's an example.
I had one client who had, who built,
like an HTML form builder, right?
You can, you build your fields,
you build your validations, and
there is an API you can use to
just submit things into the form.
Fairly standard stuff.
He was trying to sell it for, I think,
20 bucks a month for developers.
Couldn't make it work,
for the life of him.
We worked for a little while,
on this process, figuring out
where things can be applied.
And we realized, together, that, lawyers
who serve as small companies, have a
lot of forms they need to fill out.
They need their clients
to fill out, right?
And usually it's done with paper
forms and PDF forms and so on.
but it turns out that the features in the
form builder were actually pretty close
to being a form, like a legal form thing.
throw in a little bit of pdf
parsing, throw in a little bit of
communication between the lawyer
and their client, and suddenly you
have a completely different product.
And as this guy was talking to
lawyers, it turns out that they would
be happy to pay hundreds of dollars
per month for that kind of setup.
And the difference in the
tech was maybe five or 10%.
So that's the kind of thing
I'm, I'm talking about.
You can use the same ideas, the same
approach, the same thing in a completely
different context that is a much easier
business to, to get off the ground.
Yeah.
and then there is a question
of, how do you market that?
But if you're marketing as a solo
entrepreneur to smaller organizations,
it becomes easier, right?
And then what you're doing on
Twitter, it can become meaningful.
Because right now you're tweeting, but
you're tweeting into the void, because
the kind of people, like a director
of, R& D in a large organization,
you would not find them on Twitter,
because they're just not there.
you might find devs.
Maybe, not the kind of thing that would
get you closer to making this, yeah,
I'm sorry to No, I understand.
It's a conversation.
Sometimes, yeah, sometimes the
thing that we think is going,
is seems obvious, is not.
Ken: I wrote down that the biggest
thing that, aside from the obvious
stuff, yeah, no way was I ever, yeah.
Envisioning selling into
an enterprise, right?
That's not, that's just not right.
but, and the big reason I
wrote down is the trust, right?
Cause that was the key point
that I got from it that, yeah,
I built it in this bubble, there
was trust in the bubble, right?
So you're right.
people go, Oh, set it
up and click and boom.
they got a problem.
They call me.
Eli: That's the other thing, right?
They know who you are.
They know who to call.
You are within the organization.
The kind of the trust is built
in by the fact that you have an
internal email, it's different.
Yeah,
Ken: he's dealing with it now.
His password doesn't work.
Somebody changed it.
In the past 364 days since they last
did the deploy to this database,
somebody changed the password.
It wasn't me.
But now I gotta go find who did it.
And get the real one.
There's a process for that.
It's annoying.
but, yeah, I definitely
have a lot to think about.
I still like the concept, right?
I think, and I'm not being
beholden to a particular...
Implementation of anything,
I like the concept of click.
Boom.
Now I can do a job.
Yeah.
Yeah, sure.
So
Eli: there's a There's an inkling of
value, or, you know what, there's not
an inkling, there's actual value in it.
There's
Ken: value, but, like you said, in
Eli: another place.
In a particular context, exactly.
In a particular context, with
the added, things that you're
there, in person, that changes.
That I'm not gonna be.
Yeah.
I'm not,
Ken: going to the next
Eli: place.
Yeah, I've seen it a bunch of times,
in general, where internal tools become
packaged as something that can be bought
off the shelf, like a lot of things,
monitoring, logging, servers, like all
of these, if you go 40 or 50 years back.
Everybody was building
everything from scratch, right?
The whole idea that you can buy a product
that, that as a database is ridiculous,
or it was ridiculous, back in the day,
everything was built from the ground up.
so the direction is obviously valid.
There is this, there's
a need of some problem.
There is this problem that
has internal solutions.
Can this be solved with a product?
But.
In order for you to know what the
problem is, how it looks like, what
kind of solutions people tried and
what kind of solution people would
buy, you would actually need to explore
multiple organizations of different
sizes to get a sense of what people
do, because in some cases, the world
just isn't ready for a product.
And it's still, it's still
very much an internal thing.
So I don't know.
It's cause the things that you,
the things that you configure with this,
with the system, they depend on so many
internal bits and how things are set up.
That you'd either need to build
something that, what, whatever dev ops
in the company, they need to fill out
the templates or build the templates
themselves because things change
from organization to organization.
And then.
Would they prefer to do that
or build a complete system from
there, from scratch, who knows?
yeah, or you would need to go even
further and build a whole, which is
basically what GitLab have done, right?
They built a whole CI system
end to end that you don't
need to configure these bits.
So they
Ken: Our system integrates
with GitLab nicely because
they've done such a great job.
Such a great job.
Developer goes off.
It enters in a bunch of
information into our forms.
We use their APIs for their projects.
So when they go do a build,
it literally calls our system.
We dynamically generate, their
GitLab YAML file back to them.
And they run and do the stuff.
so developers are like, this is great.
I have to learn crap.
I hit a button, and stuff happens.
Eli: so here's, just
from talking about this.
Here's an idea that...
Could be a product which you sell
as an add on to GitLab and GitLab
Ken: Break things down.
So I was
Eli: you know, exactly like
you just take that, right?
You don't actually focus on dotnet
or whatever you focus on GitLab
and GitLab because of its richness
Also has complexity, right?
So you have so you build something that
the DevOps team can say Okay, these are
the seven tasks people commonly do Here's
the template that connects it to GitLab.
Here's the, and there's a
built in UI for devs to click.
Yeah, hit the button.
And it's, yeah, hit the button.
It integrates with GitLab.
There is SSL.
There's the whole thing kind
of enterprise, but maybe
smaller grade enterprise.
And
because they're already paying GitLab
a chunk of money per month or per year.
For their services, right?
Because GitLab has a free version, but
enterprise is usually used like a paid.
you are also, yeah, you're also playing
in a field that's adjacent to money.
Because it's, money is
already being spent there.
portion of that money, or in
addition to that money, could
be spent on what you're selling.
Which is an extension and
addition, and it's a, yeah.
Yeah, and it's probably a fairly easy
claim to make that, GitLab is awesome,
but for the run of the mill app developer.
Understanding these things and setting
these things up is way too complicated.
So we want to simplify and not have DevOps
do, the mundane click, GitLab to set
these things up and also avoid teaching
app developers how to do this because
like you said, no one wants to do that.
So it's like a middle ground
and that's a very interesting.
Position to have, obviously, in
order to see if that's a valid
thing, if people would want it.
if you
Ken: could get right into it, but yeah.
I like to, like you said, they're
already spending the money.
Oh, we're going to do all this.
Oh, and Joe said, you need that.
Check, it's an extra 10 bucks.
And also, whatever it is.
Eli: Exactly.
And also, your channels become fairly
obvious because GitLab has forums and
probably Discord chats and conferences and
whatnot, like you're focusing around that.
your exit strategy becomes obvious
because it's like a GitLab buy me.
the whole thing falls into
place with just one caveat.
If GitLab are doing something like this
at the same time as well, then that
might not work, but even if they are and
you do a better job, then it might be
worthwhile for them to, to buy you out.
Eli Outro: Thanks for listening.
If you want to be a guest on the
show and talk through the problems
you're facing with your business.
You can send me a message on Twitter
@finereli, my DMS are always open.
And if you're ready for some
deeper work, I can actually help
you find product market fit for
whatever it is you're building.
You can find details about how this
works, how much it costs and what I can
promise you on my website at growthlab.so.
See you next time.