← Previous · All Episodes · Next →
Everything Old Is New Again & Niching Down Episode 27

Everything Old Is New Again & Niching Down

· 32:27

|

Colin: Welcome to Build and Learn.

My name is Colin.

CJ: I'm cj and hey, we've
officially survived past that

one year point for a podcast.

We made it.

Most podcasts don't make it one year,
and that's because of the podcast fade.

The pod fade.

Colin: I think, that this is one
of those like consistency things.

This is the going to the gym, any habit.

I have a newsletter, I have a blog.

I don't keep them up to date as
much, but I like that we put this

on the calendar and we get to chat.

So especially now that we're not
in the same place anymore and it's

still still something I wanna do.

So I'm excited to hit that.

And, and Transistor has this little fun
badge system that I think it's nice to

just, when you log in to edit an episode.

I just saw it was a year, I don't
think I would've noticed otherwise.

So kudos to the team over there.

Just a little fun, fun, surprise and
delight in the transistor product.

CJ: Yeah, They've got like quite a few
little gamification things built in

that are pretty neat for podcasters.

So there's like lots of little badges
and things you can earn throughout.

So it's pretty neat.

What are you working on this week, Colin?

Colin: I am still a
little bit in calendar.

Hell it's been fun.

If you listen to the last, I think
actually two episodes I've been

talking about Google Calendar, APIs and
CloudFlare Workers and things like that.

So still working on my
Google Calendar bot.

It's been fun.

I've learned a lot about CloudFlare.

Like I, I had to like, kind of like when
you're working with Lambdas You make like

different functions for different things.

And I thought I had to
do that in CloudFlare.

And so I had like six CloudFlare
workers and turns out you can just

put them all in one CloudFlare worker.

So that was the, the big
takeaway for this week.

A lot easier to deploy and manage like
the same resources and stuff, so they

all have access to the same database and
key value store and all that stuff to do.

All the different crons that I have to do.

If you've never worked with the API
before, like you can subscribe to a

calendar's notifications, like new
event, edit event, delete event,

canceled events, but it expires after
30 days, and so you have to renew the

subscription on top of also catching
the events and dealing with those.

So I, I had set it up as like a
subscription renewal worker and

then a subscription like events.

Like kind of route to catch
those web hooks and things.

So yeah, just been playing around
with that, getting that going.

It's quite satisfying to get my
first, like you have an upcoming event

message where it wasn't just telling
me what I had for the day, but it

was telling me like right before the
event that I had a meeting to get to.

So that was kind of cool.

CJ: That's awesome.

So for the subscription renewal
bit can you, is it like you get

a refresh token and then you just
use the refresh token to get like

a new access key or something, or?

Okay, got it.

Colin: Yeah, and, and Google Auth doesn't
last very long anyway, so I had to

build, refresh into the whole system.

So I kind of made like a function
that gets their access token and

if it's expired, Renews it so
you always have a fresh token.

But I also don't wanna refresh
all the time just because you

might be making multiple calls.

So I usually, I, I do a try catch and
if it fails, For token, like in like

Grant invalid, then I do a refresh.

And this is one of those things that I
feel like I have to write over and over

and over again and like, I think like
Stripe and others u like have that built

into the SDKs and stuff these days.

But I usually don't use SDKs and do a lot
of bear rest client stuff, so, or fetch.

CJ: Yeah, I like that pattern.

I know like a, I mean, for a lot of OAuth
APIs, They'll give you a refresh token.

I mean, some of 'em don't
do the refresh thing.

They're just like, here's an access
token that's available forever.

Or like, if it gets revoked, then you just
like have to go through the flow again.

And yeah, I think when you're, when
I was starting out, I definitely

took the route of like, oh, I'm just
gonna refresh these every night.

Like, I'm just gonna run cron
that goes through and re gives

me new tokens every night.

But yeah, I definitely find that it
can be, A little bit smoother to sort

of like lazily refresh, like you said.

Just like wait till you
actually need to use it.

Try to use it.

If it doesn't work, try to refresh it.

Use the refreshed one.

If that doesn't work, then you
like handle your errors gracefully.

But

Colin: It actually, I think it, it helps
clean up the code a little bit too.

It makes it more reusable 'cause
you're gonna be calling it again

after you refresh, you're gonna
make the same call you made before.

So like when I'm prototyping, I don't
necessarily design it that way, and

then it makes me like modularize
the code a little bit and try

catch, and then call itself again.

And I think Google's, they only last a
few hours, so you would want, you wouldn't

wanna like, refresh every few hours if
you're not doing anything with that data.

But yeah, that's, that's kind of
been in OAuth land and lots and lots

and lots of practice makes perfect.

I guess.

CJ: Yep, totally.

Colin: What are you working on?

CJ: Well, a bunch of stuff, but let's see.

So similar sort of AAU thing.

We were, we're building a tool to ingest
a bunch of messages from this like

chat client that we use called Podium.

So we have like a web chat interface
where people can come to the website

and text us and say, Hey, I want
certain rooms painted or walls painted.

And this company podium has an a p I.

For pulling out conversations.

They do not have an a p i for listing
messages related to a conversation.

So you like have to know the
idea of the specific message.

So it was kind of a, it's been a
little bit of a research project

this week to set up OAuth.

And then, you know, try hitting
the a p i to see what we can get.

And then ultimately we had to like submit
a support request to ask for the messages

to be exported, which is fine for our
use case 'cause we want to, right now

we're like working on building out some
data science-y things for a little bot.

But yeah, in the future it would
be awesome to be able to just

like list those messages out.

Also working on building out and improving
like the UX for a bunch of pages in our.

Our like operations tool.

And this week I was adding some tab
views for like the project view.

So if you're like in the sales team,
you look at the sales tab and it gives

you everything you need to know about
the status, the sales status, and

where the person is in the pipeline
and what the opportunity size is.

And the partners are working
with their communication

preferences and things like that.

And then if you're on the operations
side or if you're on the paint

crew, you see different views.

And I was, I was like remembering
back to the bootstrap days where you

could just sort of like drop in some
bootstrap tabs, add some, a little bit

of JavaScript and you were good to go.

And yeah, I mean there's, when you're
working in the front end with something

like React, there's often like, you
know, some library you can just drop in.

And when you're using Tailwind, it can be
really nice to just use the Tailwind ui.

Things that come with React or view.

And so that's what I was sort of
reaching for, but it doesn't fit

nicely in the Rails ecosystem by
default, if you're using sort of

just like the vanilla H T M L E R B.

And so I found Chris Oliver built
a tailwind stimulus wrapper that

has like a bunch of the components.

So tabs was in there and was
able to drop that in and use it.

Effectively, and so that, that like
worked out really, really well.

yeah,

Colin: I would not have thought
that would've been an issue, but

I can see how that would come up.

CJ: right.

Yeah.

It's like I don't know.

I mean, tabs, you could pretty
simply build your own stimulus

controller to just say like, I.

Listen for clicks on these allies
and when that happens, remove the

hidden class from the panel that
you want to display or whatever.

So I think implementing tabs is
a pretty fun little like entry

front end JavaScript problem to do.

But when you're moving, I don't
know when, when I'm trying to be as

productive as possible, I'm like,
I don't wanna reinvent this like

Colin: No, especially with Tailwind,
like gives it to you and then

you're like, I'm using Rails.

I shouldn't be punished for this.

CJ: Yeah.

Yeah.

So I

Colin: another shout out for Chris.

CJ: Yes, exactly.

I, like, I am using so much of his stuff.

It's crazy.

Like the, our, our stack is
like, at least half of it is

written by Chris, which I yeah.

Hugely, hugely appreciate.

If you if you haven't already and
you're a rails dev, go subscribe to

Go Rails, just to like help Chris out.

Colin: Totally.

CJ: Yeah.

But it's fun.

I don't know.

It's like using stimulus.

I, I've really started to
like, enjoy using stimulus for

a bunch of different things.

Just even if it's as simple as
just showing and hiding forms or

you know, little tiny interactions
that you need on a page.

So popping modals or whatever, stimulus
is just so nice to just sprinkle in

a tiny bit of JavaScript where you
need it, and then the rest is, You

know, basically just server rendered
H T M L, which is is very nice, so.

Colin: Yeah.

Yeah.

I actually haven't been touching Rails
front ends since Stimulus really was

a thing like I've mostly been doing.

When I was doing Rails, it
was mostly backend stuff.

More APIs and a more OAuth
fund and stuff like that.

So I, that's an area that's
like a blind spot for me.

So I, I have seen a stimulus controller
and I was like, what is this thing?

If you're coming from like a JavaScript
or like, it's, it's very interesting.

But I could see how you need to like have
that glue between tailwind components

and what Rails is doing under the hood.

CJ: When you were at at orbit, what
was the front end for the Orbit app?

Colin: We definitely had, it
was a, it was a lot of stimulus,

like in our our filter view, like
that was all stimulus, I believe.

So you could like add your filters for
like which member you're looking for.

We had React components, but I
don't know when and where the,

that's where like it gets fuzzy.

Like we have React components, but
how, how you interact with them from

the app I think was using stimulus
as, as the glue between this, if that

CJ: Okay.

That's cool.

Interesting.

Yeah, we, we do like our marketing site is
all built in next jss and we've been sort

of exploring how do we bring some stuff.

Like some React stuff and then just
sprinkle that around the app the

same way that we are with Stimulus.

But I, I haven't gotten
like too deep into that yet.

So that'll

Colin: Well, I, I bet tabs are easier
on the next JSS website, right?

CJ: probably.

Yeah.

You just like drop in

Colin: just JavaScript.

CJ: Yeah, some actually, you could
probably just copy and paste the examples

directly from Tailwind UI or Headless
UI or whatever, and it should just work.

But Things like combo boxes.

We have like a dropdown list where you can
add a specific paint color to a project.

And in the combo box I wanted to show
like a little palette that has the

hex, like a little circle that is
the hex color for the paint color.

Then the name of the color, the
brand, and like its little code, so

like the Sherwin Williams code or
the Benjamin Moore code or whatever,

and building a like really rich.

Each of the options really rich into
just like a select or dropdown box

was made so much easier with with
these little tailwind components.

I'd say, I dunno if you're using
rail stuff, go check out Chris's

tailwind stimulus wrapper.

We've also got sort of a
research project going on.

We have I know I mentioned this
like podium tool that is where we

have our chat widget, but eventually
we'd love to sort of centralize all

of our communication, so we have.

Phone calls, web chat, text message,
and then even other like social

channels, all of that coming into
one source where we can like view

all the past conversation history.

And so I've been digging into Twilio
Flex, which is kind of like, It's

almost like the support agent interface
that lets you say like as an agent.

Yes.

Right now I'm available and I'm online and
I can handle conversations or whatever,

and then it will ring your phone or
it will, you'll get the web chat or

you'll get the text message and you can
kind of like handle each conversation.

And right now, The whole entire UI
is basically just dropped in as an an

iframe and like into our application.

And so over the next couple weeks
something that I want to play with a lot

is like using the Twilio APIs to create
contacts and create conversations and

start to like build mappings between like
what's in Twilio and what's in our system.

Just to see if Twilio's the right answer.

I don't actually know if that's the
way we're gonna go, but yeah, like

Twilio, Intercom, any other sort of like
multi-channel communication platform?

Curious if you've had, do
you have opinions or thoughts

about things we should avoid?

Things we should try?

Is this anything you've
touched before in the past?

Colin: Oh yeah.

I've done a bunch of call center stuff.

I would say avoid Salesforce.

Yeah,

CJ: That's right.

I.

Colin: Sorry.

Salesforce.

But you know, they have a lot of this
stuff built in, but like Twilio feels

like a strong direction because you get
Ss M Ss, you get phone calls, you get

the ability to do reminders and voice
reminders that are automated and all

that stuff, which is really powerful.

If you have multiple agents around the
world eventually, right, like people

answering calls or texting or whatever,
then it's whatever one is enabled.

Like a lot of the tools out there promise
that stuff, but it's like it's promised

that you can go get a consultant to then
implement it, not out of the box, right?

And whereas you guys are already using
the bare metal Twilio stuff, so like you

might as well just extend off of that.

I don't, does Intercom do
text and voice stuff these

CJ: I am not sure I, so I've only looked,
yeah, the, I've only really looked into

Twilio so far and we're kind of still
early in, in the research phase, but I.

It's my understanding that
Intercom has fewer channels.

But yeah, like I, I kind of also expected
that Twilio Flex would have a bit more.

In terms of helping you connect
to your own c R m or like your own

sort of like customer database.

It really just has support
for a couple outta the box.

I think it's Zendesk and maybe Salesforce,
where like those partners of Twilio have

built integrations into Twilio Flex.

And it seems like if you want your C
R M built into this, then you kinda

like have to invent, reinvent all
of the a p I connections, which.

At the end of the day, they're
giving you an interface which

is much better than nothing, and
just having the raw APIs, but,

Colin: Yeah, I mean, this is the tricky
classic build versus buy thing, right?

It's like how close to the
bare metal do you go when what?

What's your competitive advantage?

Right?

And we talked about this in last few
episodes in the past, but the tricky

thing with that is like if you were to,
let's just say you, you, it sounds like

you guys are building a C R M in a way.

have infinite flexibility there versus
if you go use a Salesforce, you will

constantly be running up against what
you're not allowed to do what you can do.

Oh, we have to pay more
to have access to that.

Oh, that seat doesn't
come with this thing.

It's just, and like, Salesforce
is not the new thing.

The whole what's old is new again around
designing like new startups around

old concepts like Paul Jarvis has his
analytics tool, which is very similar

to the analytics tool called Mint.

That was like, 2005, 2006
or something like that.

And it was just better, simpler
analytics than Google Analytics.

And Salesforce was the simpler
c r m against all these huge,

you know kind of incumbents.

Salesforce needs to be disrupted, like
most of the CRMs that I see today.

Either live long enough to become
the villain and they become the

big sales force that they are.

Same for Intercom.

Like I think Intercom will probably
get, you know, there'll be a new

startup-y version of Intercom that is
simpler, cheaper, and they all end up

going upstream to enterprise because
they took so much funding and that

they have to Which is why I'm kind
of excited to see like the calm fund

and tiny seed and stuff like that.

Is that Salesforce would be a pain.

So I would avoid that road.

That's the long way of saying that,
I guess, but, you know, there's

things you could learn from that.

I, I think you guys are on the right
path with Twilio and I'd be interesting

to see what you guys do with it.

CJ: Cool.

Yeah, it is.

We are building some C R M features.

But at the end of the day, we're kind
of just, the goal for this project is

to centralize communication so that
we have a full and complete history

and I mean, there's a bunch of gaps
and issues with our current setup.

Like we're using Google Voice for some.

Text message flows and like if
anyone reads the text message,

then it shows as red and no one
else will know that it was red.

Unless we're all being like
super vocal about like, Hey, I

read the text from so and so, it
meant it said this, or whatever.

So there's yeah, there's definitely gaps.

But lots of opportunity
for us to centralize.

Colin: I like that.

So it's more a shared inbox,
multimodal instead of c r m, right?

Like, yes, there's the who, but you're
not, I mean, you mentioned things

like opportunities and deal flow
and like where they're at and stages

and stuff and, but it's so specific,
like you would spend more time and

money customizing like a real c r
m to do that than just using code.

CJ: Right.

Yeah.

We're, we have like the coach built
process for sales already built

for this small set of states that
we are, that we need and expect.

And what's cool is that now we
can build whatever automations

we want to on top of it.

And whether we're using an a p I to
do some third party thing or we're

building it ourselves, we can do that.

So yeah, it kind of, it gives us
the flexibility to integrate or like

solve problems however we want to.

For instance, we don't have
integrations with a third party paint.

Like manufacturer because apparently
it doesn't exist or like yeah.

So there's not like an a p I
to like order paint from like

Sherwin Williams or whatever, or
as far, as far as I understand.

And so instead we communicate
directly to an account manager at

a certain place, be a text message.

And so like early versions of like
order management, just gonna be like

build the text message that's gonna
be sent as like the order for the

thing which is all stuff that we can.

We can do because we have the flexibility
and we're in a position like that,

we can build everything that we need.

So yeah, I dunno.

It's fun, it's exciting,

Colin: yeah, like pulling back
from the specific use case.

Do you, the thing that I wonder, do you
think a startup could build a C R M.

I don't think the goal is to
become as big as Salesforce, like

Salesforce is just insanely large,
but like to unseat Salesforce.

Do you think that that is possible?

CJ: I think, I definitely think so.

And I think the way to do it is to
niche, like niche down and be like, okay,

we're building a C R M for hairstylists
and it's gonna be like super, super

specific to hair and then you end up with
squire or something like that, right?

Like so yeah, I think it's

Colin: The MINDBODY online type

CJ: yes, yes, exactly.

Colin: CrossFit Gym, c r m.

Yeah.

CJ: Yep.

Yeah, I think the c r m, like c r m
features are just, those are kind of just

features of a system that's purpose built
for a specific niche, and there's totally

opportunity to go out and crush that.

And I think a lot of people are kind
of expecting, they have like more

expectations about software that they're
gonna buy to run their business, that

it is already integrated with a bunch
of stuff like, They're gonna want stripe

out the box and they're gonna want
customer messaging out the box and they're

gonna want whatever, some, some sort
of reminders in the Slack integration,

discord integration and whatever,

Colin: So like the, the Salesforce
a p i costs money, right?

You have to be on a certain plan to
have access to it, and then if you

want to customize it, you have to use
their like lightning and visual force

and like a subset of Java and like
there's just all these headaches there.

So it would be under, if anyone
has not used Salesforce, like the

admin screen is, Millions of pages.

Like it's, you open these toggles,
probably not millions, it's hyperbole,

but you know, you open a toggle and
then there's like 10 more toggles.

Then you open those toggles and there's
like, you like hunt around for these

things and they, they've added so many
features for every use case that you

have to hire consultants, which is
what one of the jobs I used to have.

Just to implement it and then you're
not necessarily happy that you're

paying a fortune for Salesforce
and then a fortune to someone to

make it do what you want it to do.

So it's the c r m one is one that has
rolled around my head for a really

long time, but it just feels, you know,
it's similar to the past where like

if you don't have a lot of funding,
a lot of companies won't trust it.

Because the funding is a signal that
you're gonna be around in some, some

people's eyes once the funding dries up.

You may not be around if you aren't a
sustainable business, but I think like

37 signals used to have high rise.

But that was like kind of
like a Fisher-Price version

of a C R M in my mind.

Like it worked, but it was
like a glorified calendar book.

It wasn't really like a A C R M.

CJ: I think in terms of like customer
support and sales, like really basic

stuff for startups, there's definitely an
opportunity to do something like, Maybe

not as intense as Salesforce, but maybe
closer to something like Zendesk where

you could build a Zendesk competitor
with some Twilio APIs and Jumpstart

Pro and like a few smart things and a
really nice design and a low, low price.

And I think, you know, early
startups would be like, hell yeah.

Like,

Colin: Yeah, the linear of Zendesk

CJ: Yes, yes, yes, exactly.

That's just like,

Colin: these are free
startup ideas for everybody

CJ: Yeah, exactly.

Yeah.

If you're following along at home,
I, you know, so like as I was going

through the the thought process of
Twilio and how I might integrate it and

everything, I was like, oh, you know what?

I think I might record this as a
video because there's enough, like

off the beaten path stuff that I
need to, like, try and experiment

with to see if it'll work.

So if folks are interested in.

Watching a probably a series because it'll
take a while to figure that stuff out.

Like let us know.

Also, going back to the pod fade
concept that we were talking

about earlier, man, it is.

Really, really hard to put
out content consistently.

I know you and I, we took a break.

I haven't put out any videos on my
own channel for like six months.

I know that my former team at
Stripe is like slowly sort of

they don't foresee a ton more
content coming out on that channel.

So there is just, it
is, it is really hard.

I was talking to Aaron Koble from.

Webflow earlier today.

He's also like slowed down on
content for his own channel.

I think a lot of people are just finding
it really, really hard and The point

that you made about falling to the level
of your systems, I thought was kind of

interesting, especially because when,
when I think about my blog and my like

YouTube channel and your newsletter and
your blog and things like that, right?

Like those were only held
accountable to ourselves, right?

At least with this podcast, you and I are
both sort of accountable to each other

that like, okay, yeah, I'm gonna show
up today even if I don't want to do it

because I wanna hang out with Colin and I
want this to be successful and whatever.

And so there's a little bit more pressure.

And I think this is probably
also it's part of the system,

it's part of accountability.

It's part of part of the reason too that
I think YC invests in companies that have

two or more founders because it really
gives you like other people to lean on

and other people to kind of like hold
you accountable for just showing up.

So,

Colin: It's funny you say that
because I don't, did, did you see

the conversation going around about
whether or not you should have

co-founders or not on Twitter this week?

On Yeah, it was of all people.

It was the product person from
Twitter Esther Crawford, who was

saying that of her Angel investments.

The ones that have gone to Zero the
fastest have been ones with co-founders

where they have a co-founder dispute.

And I will say like, yes, those are real.

Like you, when you're starting a company
with someone, like you should not take

that lightly, especially if you take.

Investment, right?

Because you are now not just accountable
to your co-founder who is in weird way,

you're gonna spend more time with them
than your actual partner in some cases.

You also are now beholden to your
stakeholders and then eventually,

hopefully your customers.

There's just so much involved there.

And so I know YC really likes to
have founders who are like first

time outta school, three people who
went to the same school together, but

like they really haven't seen life.

You know, enough of life experience
to to do it well and you know, usually

you see, I think like even with Uber
and Travis Kanick and some of these

others, like it, it was not, Uber
was not his first rodeo by any means.

There were a lot of missteps along the
way and I think they had their share

of founder, you know, drama as well.

So it's always interesting to see that.

Thing of like doing a startup by yourself.

There's just a lot to do.

So like I don't necessarily recommend
that, and there's, I think YC and

Techstars both are like, well, if you
can't convince someone else to come

along with you as a co-founder, then
why do you think we should invest that?

That kind of argument is also interesting.

But there's something to be said about
just being able to build slow and

calm and by yourself and work on it.

But then, like what you just
mentioned, like you're now

only accountable to yourself.

No one knows if you are showing up
today to work on it or not versus having

that, that partner to do that with.

CJ: Mm-hmm.

Are you, so do you, do you have
any updates about your Door app?

We had talked about like you're
gonna take a couple days off

to work on the Reno Collective

Colin: yeah, so I guess this episode's
going to another place that we

didn't expect, but it, it works.

It's good.

'cause this is like the build
versus buy thing, but it's also, I.

An issue with a startup that raised
money and has to go upstream.

So we've been using this tool called
Robin to run our conference rooms at

the collective so that the coworking
space for, for those of you who are new

to this and it worked really great, but
it was getting more and more expensive

and they have to go upstream because
conference room booking as a business

onto itself, when you've taken a bunch
of money and you've gotten really

big and you have a lot of employees,
Is not a full business, right?

People wanna rent desks.

And so the app now touts some really cool
customers that are huge compared to this

measly little coworking space that we are.

And so I don't fault
them for going upstream.

They have to, they're seeing
a lot that they can do.

Around like health, wellness check-ins.

Like when you wanna book a desk and
come into your company, like a Google

or whoever, they want to say like,
okay, you know, everything from your

badging system at Stripe and Discord or
wherever to physical digital security.

Are you gonna have a desk
and a coworking space?

Like a lot of companies have
reinvented their HQs as like glorified

co-working spaces, and so they
built all their tooling around that.

And so like the app for us just doesn't.

It's expensive.

It doesn't make sense for us anymore.

Our members are finding it confusing
'cause they're like, oh, I log in

and it's asking me to book a desk.

I'm like, yeah, don't use that tab.

Go to the other tab.

And we just don't have any control
over the app and the experience.

I've been holding off on just building
my own for a really long time.

But I've also been playing
around with calendar APIs.

So I am, I'm playing around with it.

My first prototype is a React app
that just checks whether or not each

calendar is free or busy right now.

So it'll basically be red or green
depending on if the room is booked.

So that part, surprisingly, will
be like, the easier part, the

harder part is letting people book,

Having the UI to do the booking
and, and all of that stuff.

I think we'll start with just building
it for ourselves with no expectation,

but maybe it'll become a conference room
booking app that's just run by one person.

We'll see.

CJ: Is the Google calendar, a p i?

You can, I assume you can
create events through it.

And even if you're not authenticated
as the, could probably auth like auth

as like, we are the coworking space.

And then just use that auth
token to create the room or

like book the room or whatever.

Colin: Yeah, and you can do things
like with service accounts and

stuff you can actually impersonate.

So there's like all sorts of OAuth
magic you can do with Google.

But the other way to think of it
is that like an M V P would be

having a Calendly to book the rooms.

It requires us to like
create each room as a person.

CJ: Very cool.

Thanks for the update, and
it sounds like a fun project.

I know, like the further I get into my
career, I'm getting a little bit better

at not just like building stuff that I'm
like, oh yeah, that'll be easy to do.

Let me just build some little
web scraper that goes and gets

the data I need for this thing.

It's like, okay, yeah, that that'll work
for a minute, and then like it'll explode.

So yeah, it's, it's, I'm, I'm, I'm
definitely struggling finding a

balance between saying like, no, you
shouldn't build the thing because.

There's existing solutions out there and
the tam isn't big enough and whatever.

And then also just, you
should just build it.

'cause it'd be fun and
it'd be like interesting.

And if it happens to work, great.

If it doesn't work, then whatever.

Like try some other solution.

But yeah, I don't know.

Maybe that's what this like Twilio Flex
plus Jumpstart thing will end up being.

Colin: I think we've talked about
this in the past with build versus

Buy, but like in a way, rails.

Is like a hybrid of the two.

Like you're not building
everything from scratch.

Like Jumpstart gives you so much out
of the box rails is giving you so

much power, and then flex, you know,
literally flexing over here on Twilio.

So like, it's it's good you got,
I think it's a happy medium.

You may go down that path a
little bit and find that it,

it's too deep of a rabbit hole.

And I think like, keeping in
mind like, is this you know,

a unique value prop for us or.

Is it not?

Because I've been at a company where
we were gonna spend like six weeks

on a billing system and it's like, is
us billing our customer unique to us?

No.

Why should we be spending
six weeks doing that?

CJ: right.

Colin: billing is broken in the industry
of getting your house painted, then sure,

but I suspect that's not the problem.

Right.

It's probably getting your house
painted is the bigger problem.

CJ: Yeah, that is great.

I, you know what, when, when I'm
in it too, it's so hard to, to.

Keep that high level view of like, what is
the most important thing for the business?

And I'm sure everyone who's working on
a startup does this and they're just

like, gosh, I want these tabs to work.

It's like, okay, if these tabs
aren't working, if instead you just

throw everything on the page, is
that gonna be good enough for now?

And then, you know, try to prioritize
and focus on the problems that are gonna

really move the needle for the business.

That's tough.

Colin: This gets into like product
management a little bit, which we can

definitely talk about in the future.

But you know, having an appetite,
like, yeah, we want those

tabs, but do we want the tabs?

If it's gonna take us a week
to build them, probably not.

CJ: Right, right, right.

Totally, totally.

I think that's a good spot to leave it.

Thanks for listening to Build and Learn.

As always, you can head over to build and
learn.dev to check out the show notes.

We'll drop links to things
we talked about and yeah.

Thanks for listening.

Colin: Bye friends.

View episode details


Creators and Guests

CJ Avilla
Host
CJ Avilla
Developer Advocate @StripeDev. Veteran. 📽 https://t.co/2UI0oEAnFK. Building with Ruby, Rails, JavaScript
Colin Loretz
Host
Colin Loretz
I like to build software and communities. Building software at @orbitmodel 🪐 Coworking at @renocollective 🎙Sharing software learnings on @buildandlearn_

Subscribe

Listen to Build and Learn using one of many popular podcasting apps or directories.

Apple Podcasts Spotify Google Podcasts Overcast Pocket Casts Amazon Music
← Previous · All Episodes · Next →