►
Description
In this talk, Josh Kalderimis tells the story of how Travis added an Enterprise offering to their existing hosted Continuous Integration service, the bumps they hit along the way, and what they would do differently now.
About GitHub Universe:
Great software is more than code. GitHub Universe serves as a showcase for how people work together to solve the hard problems of developing software.
For more information on GitHub Universe, check the website:
http://githubuniverse.com
A
It's
a
good
afternoon,
wow,
that's
loud
I'm,
quite
loud
or,
as
we
say
in
my
native
homeland,
kiora
I
want
to
do
a
little
I
guess
a
little
listen
before
we
start.
We've
just
had
lunch.
Everyone's
full
I
want
to
make
sure
energy
doesn't
dissipate
in
the
seat.
So
could
everyone
just
stand
up
for
a
second
if
you've
got
a
laptop
put
it
to
the
side?
This
is
an
important
lesson
as
well.
Ok,
stand
I,
see
two
people
sitting
down
with
the
laptops.
That's
good!
That's
good!
Yeah!
A
A
A
Well,
I'm
from
this
tiny
little
island
called
New,
Zealand,
okay,
we're
known
for
our
sheep
I,
think
there's
more
sheep
than
people
and
we're
known
for
our
hobbits
there,
our
second
largest
export
and
for
our
business
time
I
come
from
the
city
called
Wellington
capital
of
New,
Zealand,
middle
of
the
middle
of
New
Zealand,
but
bottom
of
the
North
Island
and
beautiful
at
night.
Absolutely
fantastic
City!
It
is
the
inventor
of
the
flat
white
I
am
calling
Wellington,
the
inventor
of
the
flat
white,
also
known
for
our
flying
skills.
A
It's
also
one
of
the
windiest
cities
on
the
world
or
consistently
windy.
This
is
not
a
abnormal
landing.
I
have
been
on.
One
of
these
I
now
live
in
this
fantastic
City
called
Berlin
in
Germany
known
for
a
lot
of
its
history,
a
lot
of
it.
So
if
there
any
github
is
here,
they've
probably
got
a
season
pass
to
bergheim
and
also
for
the
wall,
but
I
actually
wanted
to
bring
up
an
important
point.
A
How
many
people
here
are
American
I'm,
yep,
okay,
good,
so
I
love,
you
guys
and
all,
but
you
gave
us
death,
David
Hasselhoff.
You
gave
him
a
platform.
So
as
a
I,
don't
you
can't
see
it
very
well
here,
but
David
haven't
has
all
have
became
incredibly
famous
in
Germany
for
singing
on
top
of
the
wall
as
it
was
coming
down.
A
In
fact,
it's
set
at
the
number
one
position
for
eight
weeks
in
Germany
and
four
weeks
and
Switzerland,
but
it
was
ranked
by
AOL
radio
as
the
98th
worst
song
in
the
world
and
he
quotes.
It
testifies
to
the
power
of
music,
horrible
horrible
music
to
unite
and
uplift
us
all
and
look
he's
still
going
today.
So
thank
you,
America
for
playing
a
big
troll
on
us.
A
So
I'm
back
to
the
talk.
My
name
is
Josh
Cal,
Remus
I
work
for
this
company
called
travesty.
I
am
one
of
the
cofounders
there
and
I
want
to
talk
about
SAS
and
enterprise
and
how
you
can
become
an
enterprise
product
from
your
SAS
product.
So
essentially,
what
I'm
really
talking
about
is
what
we
learnt
by
building
Travis
CI
Enterprise
enterprise.
You
say:
Travis
CI
enterprise.
A
Yes,
it's
like
Travis
for
the
enterprise,
it's
kind
of
like
this,
that
for
the
enterprise,
so
a
little
bit
of
background
I
think
the
best
way
to
kind
of
understand
how,
with
built
an
enterprise
product,
there's
also
by
understanding
some
of
the
pains
and
things
that
we've
gone
through
a
lot
of
our
learnings.
So,
as
I
said,
I'm
one
of
the
co-founders
here
we've
now
become
a
team
of
23,
fantastic
people
where
half
our
team,
a
remote
half
a
based
in
germany
and
the
other
half
a
woman.
A
A
We've
got
about
last
as
I
last
checked,
about
200,000
users
on
our
open
source
platform
will
get
about
300,000,
tested
repositories
and
of
that
we're
doing
about
2500
250,000
jobs
per
day
across
a
dot,
org
and
calm,
and
all
of
this
came
from
the
sky
here
with
his
fantastic
and
mustache.
You
might
even
recognize
him
from
a
lot
of
the
stickers
that
we've
got.
Stem
Fuchs
was
the
original
guy.
That
kind
of
came
up
with
the
idea
of
Travis
CI.
A
He
wrote
a
blog
post
in
2011
right
at
the
start
of
the
year
and
I
emailed
him
the
next
day
and
I
said
how
can
I
help
and
he
gave
me
commit
access
straight
away.
What
we
wanted
to
do
is
just
helped
open
source
I
was
an
open
source
project
to
help
open
source,
and
primarily
at
that
time
we
were
Ruby
developers.
A
What
we
wanted
to
do
is
we
wanted
to
allow
developers
to
test
against
multiple
versions
of
Ruby
with
ease,
because
if
you
were
to
do
this
yourself
back,
then
you
would
spin
up
a
Jenkins.
You
would
create
a
very
horrible,
convoluted
config
file
and
then
you'd
have
to
do
this
for
each
project
you'd
be
doing
it
yourself.
There
was
no
isolated
environments.
A
What
we
wanted
to
do
is
make
it
as
simple
as
123
for
testing
your
software,
but
what
we
really
wanted
is
to
help
people
build
better
applications
by
testing
those
libraries
and
having
people
use
those
libraries
that
are
tested.
You
can
be
at
least
a
bit
more
certain
that
your
code
is
of
better
quality,
because
that
code
that
you're,
using
as
better
quality,
so
it
was
two
people
and
two
people
was
not
really
doing
to
achieve
what
we
needed
to
achieve.
A
A
We
decided
to
do
things
a
little
bit
differently
as
well.
We
wanted
to
do
a
crowdfunded
company,
and
so
what
we
did
is
we
created
a
website
called
love,
Travis
co.org,
where
people
could
donate
companies
and
individuals
and
they
could
donate
to
us
wanting
to
achieve
some
goals
quite
similar
to
a
Kickstarter,
but
we
rolled
our
own
hooked
it
into
stripe
and
over
about
a
six-month
period
we
raised
about
140,000,
so
this
got
us
going.
A
It
allowed
us
to
contract
a
little
bit
on
the
side,
pay
what
we
needed
to
pay
the
bare
minimum
that
work
on
the
product
work
on
Travis,
so
we
could
provide
a
better
product
in
you
know,
service
to
our
users
and
customers.
We
had
all
these
great
customers
donate
and
what
we
kind
of
figured
out
from
this
is
a
lot
of
these
people
were
emailing
us
asking
to
test
their
private
code
on
Travis,
so
Travis
CI
dog
was
our
MVP.
While
crowdfunding
was
our
confirmation
that
we're
onto
the
right
track.
A
So,
as
I
said,
I,
centcom
and
daughter
organ
pay-per-view
views
Travis.
At
the
moment
we
have
got
two
different
domains:
everything
open
source.
It's
on
Travis,
CI,
dog
and
everything
private
sits
on
Travis
CI
calm,
and
this
is
a
really
important
thing
that
I'll
come
back
to.
So
we
have
two
different
and
production
environments.
It's
not
too
different
domain
names
leading
to
the
same
application.
It's
two
different
deployments.
In
fact,
it's
even
two
different
staging
deployments:
two
different
production
deployments.
A
Everything
started
as
one
rails
app,
but
for
us
to
scale
and
to
meet
that
demand
of
running
all
of
those
jobs
per
day.
We
do
about
17,000,
HTTP
requests
per
second
or
so
per
minute,
and
it
quickly
grew
into
a
semi
solar
based
application.
It
moved
off
as
well
to
being
Ruby
and
a
bit
of
ghost
we
use
go
as
our
worker.
Ruby
is
very
prolific
and
help
product
and
platform
code,
but
of
course,
for
us
to
focus
on
building
a
good
application.
A
We
embraced
sass
as
well
we're
big
big
supporters
obsess
and
we
love
pass
as
well.
So
we
decided
we're
going
to
use
Heroku.
We
use
to
Roku
for
all
of
our
deployments,
and
on
top
of
that,
we
used
a
lot
of
providers
for
things
like
database
Redis,
memcache,
amqp
and
file
storage.
We
didn't
want
to
recreate
the
wheel.
Why
do
that
when
we
can
just
buy
it?
A
So
here
is
essentially
our
architecture.
This
was
created
by
two
of
our
juniors
that
joined
earlier
this
year.
I
believe
it
was,
and
with
this
idea
of
creating
a
trainee
project,
I
love,
seeing
all
these
phones
out
taking
essentially
a
picture
of
a
very
complicated
architecture,
diagram.
There's
a
lot
going
on
here.
There
are
two
databases:
logs
and
production.
Our
main
database
we've
got
rid
of
being
used
heavily.
A
We've
got
separate
apps
for
lots
of
different
smaller
tasks
like
Travis
listener
listens
to
the
events
from
github
stores
them
on
to
read
us,
which
is
in
processed
by
gatekeeper,
which
then
updates
the
database.
We
had
a
scheduler
that
were
then
pop
these
jobs
onto
rabbit,
which
the
workers
will
pick
up
logs
are
sent
to
Travis
logs,
which
processes
in
sends
him
to
pusher
and
to
a
database.
A
Then
we've
also
got
tracks
hub
with
the
updates
and
then
task
since
no
two
notifications
at
the
end,
along
with
Travis,
live
with
using
pusher
and
subscribe
to
channels.
There's
a
lot
going
on,
and
we
did
this
because
we
would
do
it
we're
trying
to
scale
it
organically.
You
don't
go
out
and
create
an
app
saying:
oh
I'm,
going
to
create
a
service
and
instantly
I'm
going
to
create
20
different
apps.
This
happened
over
time
and
naturally
so
of
those
apps.
This
is
all
of
them
in
an
addition
of
an
admin
one
at
the
bottom.
A
All
of
these
are
two
apps:
are
open
source,
so
I'm
just
going
to
remove
the
Travis
pat
remove
some
of
the
noise.
Now
one
thing
that
you
might
not
have
noticed
in
that
architecture
diagram
was
that
these
four
apps
API
gatekeeper
hub
Edmund,
will
just
kind
of
put
into
a
special
category.
That's
for
helping
our
support
staff.
They
share
a
library
I'm,
going
to
use
the
polite
term
library
and
not
bundle
of
mud
called
Travis
core.
It
was
our
way
of
sharing
business
logic
and
models
between
our
apps.
Again,
it's
a
natural
project.
A
He'll
put
natural
progress,
but,
on
top
of
that,
as
I
said,
we
run
travis
CI
calm.
That
also
has
travis
pro
core.
Now,
when
I
sit
with
separate
deployments,
we
actually
also
have
additional
code.
When
we
were
developing
calm,
we
weren't
prepared
to
do
everything
out
in
the
open.
We
wanted
to
try
and
figure
out
to
get
things
right
and
then
figure
out
how
we
can
merge
everything
back
and
have
a
more
open
code
base.
This
also
meant
that
we
had
some
pro
apps.
A
A
So
if
we
think
about
Travis
hub,
for
example,
it's
using
Travis
core
now,
we
think
of
pro
hub
and
it's
using
these
dependencies.
Now,
let's
say
we
decide
we're
going
to
work
on
a
new
feature
and
it
requires
us
to
update
Travis
core.
What
will
then
have
to
do
is
do
a
bundle,
update
of
Travis
hub
and
then
what
we're
going
to
have
to
do
is
see
if
we
need
to
make
any
changes
to
Travis
pro
core
and
then
we're
going
to
have
to
bundle
update,
Travis
pro
hub
to
get
all
of
those
updates.
A
It's
not
great
for
development.
So
that's
why
we've
been
working
hard
to
remove
that
I
told
this
to
someone
in
heels
like
this
is
way
too
much
information
Josh.
What's
going
on
with
your
development
and
you're
right,
because
what
I'm
trying
to
show
is
nothing
is
perfect
in
everyone's
code,
we
make
a
lot
of
these
decisions,
naturally
in
progress
over
time.
A
Well,
where
do
I
start?
There's
a
lot
here
at
that
time,
when
we
had
our
first
enterprise
customer
approaches,
we
were
seven
people,
we
were
still
building
our
SAS
product
and
we're
going
through
some
fantastic
growth
with
everything,
but
an
opportunity
was
there
and
the
big
question
is:
is
there
something
that
we
should
do
now?
What
we
did
know
is
github
enterprise
was
a
successful
product.
A
It
was
a
very
much
big
part
of
github
and
we
looked
at
them
as
an
a
bit
of
inspiration
because
the
way
I
were
but
the
way
I
like
to
look
at
it
is
people
with
an
enterprise's
developers
within
enterprises
should
have
to
have
the
opportunity
to
use
the
tools
that
they
want
to
use.
There
was
people
there
were
people
asking
us
for
Travis
CI
enterprise
because
they
wanted
to
use
it.
I
know
it
sounds
really
stupid
and
simple.
Essentially,
our
advocates
that
liked
using
org
were
asking
to
use
it
within
another
company.
A
A
Now
the
problem
is
distinguishing
distraction
from
opportunity,
you're,
seven
people,
and
now
we
have
to
figure
out.
How
do
we
do
the
development?
How
do
we
do
sales?
How
do
we
do
customer
demands?
How
do
we
set
expectations?
What
you
need
is
the
entire
team
behind
this
there
needs
to
be
buying
from
everyone.
A
This
should
not
be
one
person
project
so,
and
on
top
of
that,
you
also
need
to
make
sure
that
you
can
pick
the
right
price
to
make
sure
that
this
is
I,
guess
a
profitable
endeavor,
if
that's
the
right
way
to
say
it.
So
what
were
our
goals?
What
we
need
to
take
a
step
back
when
we're
building
enterprise
software?
There
are
a
couple
of
things
that
are
just
Givens.
It
needs
to
be
easy
to
install
your
production
system
can
be
as
complicated
as
you
like.
A
You
can
have
a
million
scripts,
but
you
need
to
package
this
your
enterprise
product
in
a
way
that
anyone
can
install
it
the
higher
the
experience
required,
the
less
people
that
are
going
to
take
the
OP
of
the
take
the
time
to
try
it
out.
It
needs
to
be
secure
not
only
for
us
but
for
them
so,
for
example,
they're
holding
it
on
running
up
behind
their
firewall.
But
for
us
we
need
security
for
our
code.
A
A
A
Then
there's
a
question
about
scaling.
We
knew
how
to
scale
Travis
to
200,000
users
and
125
running
projects
per
day
on
dot,
org
and
calm,
combined
250,000
about
2,000
jobs
running
at
once.
What
about
enterprise
well
I?
Think
there's
an
important
thing
here.
Scaling
for
us
was
a
secondary
concern.
We
believed
and
I
think
it's
actually
a
fair
assumption
that
any
Enterprise
installs
will
not
be
as
big
as
our
own
installation
straight
away.
It
might
grow
to
that,
but
at
least
with
our
first
customers.
A
We
should
stay
away
from
anything
that
will
be
of
equal
size
of,
although
we're
handling,
17,000
requests
per
minute
on
dot,
org,
just
dot
org
alone.
Do
we
need
to
think,
or
at
least
assume
that
enterprise
will
be
the
same
amount?
So
we
took
a
reasonable
estimation
reasonable
assumption
that
our
first
customers
were
going
to
be
listening.
So
we
put
this
onto
the
back
burner
now.
This
is
all
during
the
time
that
docker
was
coming
out.
In
fact,
at
that
time
it
was
dr..
0.8
docker
was
the
new
hotness.
A
People
were
like
tattooing
docker
on
their
chests
I'm
sure
it
was
happening
and
docker
is
all
about
single
processes.
So
let's
have
a
look
at
this
again.
Our
architecture
diagram.
If
we
were
to
break
this
into
the
docker
way
of
working
every
service
and
every
application
would
be
its
own
container,
every
container
would
have
to
be
linked
up
to
the
services,
so
they
can
talk
to
each
other,
and
now
you've
got
a
lot
going
on
with
something
that's
quite
new.
Our
initial
trying
out
of
the
doc
way
of
doing
things
was
just
not
working.
A
We
spent
a
lot
of
time
and
effort
to
do
at
the
dock
away
and
especially
when
you've
got
to
think
about
process,
monitoring
and
log
aggregation.
It
was
just
not
mature
enough,
so
what
we
decided
to
do
is
go
for
the
miguk
taner,
it's
a
cheat.
We
were
using
docker
for
orchestration
downloading
images,
starting
things
up,
but
what
we're
actually
doing
is
starting.
It's
been
in
it.
That
is
essentially
starting
an
entire
virtual
machine.
It's
starting
everything!
It's
not
the
entire
operating
system.
You
start
up
start,
you
can
use
it
like.
A
A
Now.
On
top
of
this,
we
need
to
think
about
installation.
The
good
thing
is
it's
mostly
just
docker
pool
that
was
great.
A
lot
of
people
could
understand
that
now
daughter
was
still
new,
so
we
had
to
have
comprehensive
documentation.
You
still
had
aufs
and
different
execution
drivers
coming
out,
and
then
we
had
to
think
about
configuration.
How
do
people
configure
this
so
we
had
bash
scripts
so
what
we've
got,
and
on
top
of
that,
we
then
had
the
our
license
yellow.
So
we
had
to
build
our
own
licensing
at
this
time.
A
A
A
So
we
had
something
that
worked,
but
what
we
really
wanted
was
something
more
something
simpler,
something
that
gave
our
uses
an
easier
installation
path,
easier
maintenance.
So
then
we're
very
lucky.
Someone
called
us,
there
was
an
introduction
and
it
was
replicated.
I
was
supposed
to
have
their
beautiful
faces
here,
but
you
can
find
them
at
the
back
and
what
they
did
is
that
we're
making
a
piece
of
software
that
made
packaging
and
interpret
packaging
and
shipping
enterprise
software
easy.
A
So
the
idea
was
that
it
was
built
on
top
of
docker
was
integrating
with
docker,
and
it
gave
us
a
lot
for
a
little
gave
us
all
of
these
extra
features,
with
no
extra
development
and
very
little
integration
costs.
In
fact,
to
be
honest,
I
then
said
to
them:
oh
I'd
love
to
try
this
out.
Can
you
help
us
with
the
configuration
the
next
day?
Grant
one
of
the
co-founders
said?
Oh
here
it
is
it
works
and
I
said:
oh
great
I've
just
sent
this
to
to
customers
and
they
loved
it.
A
It
was
that
literally
quick
and
simple
for
us,
and
what
we
got
out
of
it
is
an
easy
way
to
install
the
software
where
you
could
upload
a
license.
You've
got
an
admin
panel
with
graphs
for
CPU
and
memory.
You've
got
to
even
see
the
next
release.
That
was
there.
You
got
to
start
and
stop
it
quite
easily.
You
got
an
entire
setting
screen.
We
didn't
have
to
build
any
of
this,
and
then
we
also
got
you
know.
A
When
is
your
license
expiring
and
an
audit
log
which
is
incredibly
important
people
logging
in
and
making
changes
you
need
that
logged,
so
they
can
see
if
maybe
someone
else
on
the
team
made
a
change
which
broke
it
and
the
all-important
support
bundle.
Now
this
isn't.
This
is
I,
guess
a
thing
that
we
learned
in
that
when
you
get
a
deployment
out
there,
you
know
how
to
fix
your
own
production
environment.
A
You
know
what
logs
to
check
where
to
check
status,
monitoring
page
pingdom,
all
of
that
now,
if
a
user
has
a
problem
and
that
you
can't
get
to
that
installation,
what
you
ask
them
for
what's
files,
do
you
say?
Can
you
please
send
me
so
I
can
check
what's
going
on,
so
the
support
bundle
is
the
idea
of
a
concept
of
zipping
all
of
those
important
needed,
debugging
files
together,
sending
it
to
you.
So
then
you
can
debug
it,
and
on
top
of
this
we
also
got
a
vendor
panel.
A
So
we
could
see
what
versions
we
head
out
there.
We
had
three
different
channels
stable
for
our
customers:
babel
have
beta
and
unstable
for
development,
and
then
we
had
all
of
our
customers
as
well.
We
could
see
which
licenses
that
expired
when
we
granted
it
and
the
current
status.
So
we
got
a
lot
of
a
lot
for
very
little,
and
all
of
this
happened
in
configuration.
So
it's
a
yemen
configuration
and
then
later
on
and
had
a
preview,
so
you
can
even
test
your
github
authentication.
You
can
test
your
SSL
please.
A
So
what
did
we
really
get
out
of
this
I'm?
Not
the
strong
is
definitely
not
about
hey.
You
should
just
use
replicated,
which
I
mean
you
should,
but
what
is
it
that
we
actually
got
out
of
this?
Well,
we
got
a
solid
installing
experience.
What
we
wanted
to
provide
was
a
great
install
experience.
We
got
it.
It
dealt
with
install
update,
set
up
everything.
A
We've
got
a
lot
of
extra
features,
so
audit
log
release,
notes,
licensing,
expiration
channel
management
and
they
also
had
an
API
for
doing
automatic
deployments
or
automatically
release
management
as
well.
So
we
could
tie
this
into
Travis,
build
a
container
and
then
upload
the
configuration
to
them
and
then
even
better.
We
can
then
upload
it
to
one
of
the
beta
servers
and
do
smoke
tests
on
it.
So
it
was
an
enabling
us
to
provide
a
better
quality
product
and
and
cheese
early
enough
I'm,
a
cheesy
man
deep
down
under
it
was
it
for
me.
A
It
was
an
extension
to
our
team.
There
were
people,
I
could
talk
to
and
ask
for
help
and
ask
for
features
instead
of
just
buying
a
product
off
the
shelf.
Now,
that's
just
a
more
important
part
of
the
purchasing
process.
I
can't
believe
I
actually
used
that
in
a
in
a
presentation,
I
I
feel
like
I've
come
a
long
way
now.
I
got
to
have
a
team.
That
I
could
say,
could
you
add
a
feature
or
even
better?
A
They
added
a
feature
for
someone
else,
and
we
got
it
too
and,
most
importantly,
it
was
a
tool
to
help
us
focus
on
our
product.
So
the
idea
is
I.
Don't
want
to
have
to
build
that
management
you
I
I've
got
better
things
to
work
on
for
our
customers.
Anything
that
gets
into
our
common
dog
comes
to
enterprise
shortly
after
so
the
big
thing.
What
did
we
learn
along
the
way?
Well,
I.
A
Think
very
most
importantly,
if
you're
going
to
go
down
this
road
of
building
an
enterprise
product
taking
your
sass
packaging,
it
up,
you
need
to
find
the
right
early
customers
and
users.
Now
I
mentioned
earlier
that
we
had
someone
knock
on
the
door
and
ask
for
it
and
funnily
enough,
we
never
actually
got
to
sell
it
to
them.
They
decided
it
wasn't
right
for
them,
and
it
was
because
we
weren't
ready
for
licensing
and
the
legal
implications
we'll
get
to
that.
A
On
top
of
that,
the
second
customer
that
came
to
us
also
didn't
end
up
using
it.
Customers
will
come
and
go,
but,
more
importantly,
if
you're
going
to
build
an
enterprise
product,
you
can
take
that
team
time,
you're
going
to
take
the
resources
away
or
spin
the
money.
During
that
it's
just
money,
you
need
to
make
sure
you've
got
the
right
customers
to
do
it
for
as
well
you're
learning
from
them
and
they're
learning
from
you,
but,
most
importantly,
you're
learning
from
them.
A
Pricing
is
hard,
and
this
is
I
say
this
in
every
talk
egg
of
these
days,
pricing
is
really
hard,
but
do
not
undervalue
your
team's
work
and
then
undervalue
your
product.
So
we
cheated
a
little
bit
get
up.
Enterprise
was
out
there,
it
was
in
the
wild
and
it
was
5000
us
/,
20
users
and
we
said
cool.
That's
how
benchmark
now
we'll
use
that
benchmark
and
add
a
little
bit
more
and
we
add
a
little
bit
more
because
we
had.
We
were
growing.
A
A
team
we
had
a
lot
of
moving
parts
and
we
also
knew
it
wasn't
just
one
server.
It
was
lots
of
servers.
We
had
parts
to
take
into
account
there
as
a
little
bit
of
pricing
advice.
This
was
advice
was
given
to
us
by
a
seed
and
Vesta
of
a
competitor,
and
it
was
pick
a
number
and
keep
doubling
it
until
you're,
uncomfortable
and
double
it
again.
Okay,
I'd
like
to
also
give
a
small
warning
site
licenses.
There
are
so
many
different
license
types
you
can
head
out
there.
A
A
Larger
deployments
will
take
a
little
bit
more
time
to
get
everything
set
up.
It
takes
a
longer
sales
process.
Make
sure
that
you
build
into
your
pricing
to
have
different
tiers,
and
I
would
I
would
recommend,
trying
to
stay
away
from
site
licenses
as
well
always
be
closing.
Okay
sales
I
thought
I
got
one
laughs.
That
makes
me
feel
good
sales.
Take
a
long
time
now,
I'm
a
developer
I.
I
started
Travis
with
spin
I
started
it
in
2011.
A
I
was
the
second
developer
on
it
doing
Ruby
and
all
along
the
way
I've
had
to
change
what
I've
done
to
try
and
you
know,
as
we
grow
this
company
and
to
grow
our
team
and
for
a
long
time
I
was
the
main
sales
person.
I
would
be
the
one
jumping
on
calls
replying
to
emails,
figuring
out
how
to
make
things
easier
and
sales
take
a
long
time.
You'll
have
someone
say
how
excited
they
are
and
then
about
six
months
later,
will
you
actually
get
the
paperwork,
processed
and
payment
received?
A
Okay
sales
take
a
long
time
be
ready
for
that.
But
on
top
of
that
there
are
some
things
to
make
it
a
little
bit
easier.
Now
we're
a
German
company
based
in
Berlin,
and
because
of
that
we
ask
people
to
do
wire
transfers
now.
Wire
transfers
are
just
inherently
a
little
bit
more
complicated,
apparently
for
organizations
or
an
especially
on
the
American
side.
So
what
we
did
is
we
decide
to
accept
credit
card
payments
as
well,
and
this
was
created.
It
was
great,
I
won't
name
it.
The
company
name
that
darkness
who's
sitting.
A
Everyone
here,
who's
a
developer
in
the
audience
awesome.
Everything
here
is
doable.
Everything
here
is
technical.
There
are
always
solutions
for
technical,
it's
illegal,
that's
the
hardest
stuff,
and
there
are
two
things:
I
want
to
kind
of
point
out.
First,
one
is
audit.
Your
code,
every
line
of
code
needs
to
be
audited.
You
need
to
find
out
what
libraries
you're
using
on
what
licenses
you're
using
in
those
libraries
as
well,
because
that's
going
to
lead
to
the
next
problem
of
unlimited
liability.
A
A
All
of
that.
So
if
they
go
after
the
big
company
and
say
they
go
to
court
and
all
these
legal
fees
they're
going
to
come
after
you
for
reparations,
I
would
just
implore
you
to
look
into
this,
because
it
also
leads
me
to
another
point
that
customers
are
going
to
ask
for
changes
to
their
licensing
agreements.
A
You're
going
to
come
up
with
a
licensing
agreement
with
your
lawyer,
that's
going
to
cost
you
time
and
money,
and
then
customers
are
going
to
come
to
you
and
ask
you
to
make
some
amendments
and
changes
that
fit
their
needs
based
on
their
lawyers,
red
lines,
you
don't
need
to
make
them
all.
On
top
of
that,
don't
do
it
for
everyone,
especially
the
smaller
license.
What
you
need
to
do
is
make
sure
that
you're
covering
yourself
with
these
costs
as
much
as
they're
covering
themselves
with
these
changes.
A
Customer
requests
are
a
really
interesting
one.
Now
there
are
good
ones,
there
are
really
valid
ones:
backups
h
a
special
api's,
but
then
there's
going
to
be
something
that
is
just
very
custom
to
them,
and
should
you
make
it
well,
you
don't
want
to
make
one
or
feature
editions.
Generally,
that's
a
maintenance
nightmare
you're
going
to
create
maintenance,
state
technical
debt
if
you
do
have
a
config
based,
but
also
don't
fork
your
code
for
a
customer,
don't
have
different
copies
of
your
code
and
don't
have
different
release
channels
at
most.
A
A
All
of
this
comes
down
to
teamwork.
It
requires
your
team
to
be
in
agreeance
agreements
agree.
They
have
to
all
agree
that
you
want
to
do
this
because
it's
all
going
to
be
development,
there's
going
to
be
support
and
then
you're
gonna
have
to
do
releases.
You
also
have
to
make
sure
there's
your
team
all
right
with
you
growing
as
a
company
to
do
this.
Do
you
need
sales?
Do
you
need
sales
support
engineers?
A
One
recommendation
I
can
make
is
focus
on
having
sales
support
engineers
before
its
sales
people
and
that's
because
a
lot
of
this
will
be
about
installation
and
maintenance.
When
you're,
very
small
and
you've
got
a
couple
of
customers,
three
four,
maybe
you're
growing
you
can
do
the
sales
process.
It's
going
to
be
new,
it's
going
to
be
a
little
bit
out
of
your
comfort
zone,
but
it
can
be
done,
but
sales
support
is
going
to
be
something
that's
going
to
take
your
time
and
then
you're
going
to
be
saying.
A
A
Communication
to
enterprise
customers
and
enterprise
trial
customers
is
a
little
bit
different
from
how
you
communicate
to
your
normal
customers.
Well,
your
normal
users.
Maybe
you'd
use
a
very
wide
mailing
list,
maybe
you'd
use
blog
posts,
but
for
this
you
need
to
keep
really
good
change.
Log
notes
and
release
notes.
A
You
need
to
have
lots
of
Doc's
about
installation,
frequently
asked
questions
problems
you
may
encounter
and
having
a
mailing
list
even
for
the
people
that
sign
up,
saying,
I'm
interested
will
allow
them
to
keep
tabs
of
when
you
have
not
only
a
new
release
out,
but
maybe
you've
got
a
new
release
where
it's
addressed
a
problem
that
stopped
them
from
buying
it
in
the
first
place
and
really,
most
importantly,
most
importantly,
if
you
don't
have
to
build
it,
don't
just
buy
it
now.
What
I
mean
here
is
the
whole
replicated
set
up
for
us.
A
We
did
that
we
create
our
own
installation
and
setup
process
initially,
because
we
had
to
there
was
nothing
out
there,
but
when
something
came
and
came
and
became
available,
we
took
the
chance
we
leapt
and
we
used
it.
We've
embraced
it
we
use
close
I
owe
as
well.
It's
a
great
sales
platform
for
our
team
replicated
for
licensing
and
installation
is
great.
On
top
of
that,
I'd
like
to
make
a
special
mention
for
a
blog
post
by
beer
metrics,
if
you're
not
using
them,
also
a
fantastic
product.
A
Now
it's
called
build,
it
don't
build
it
buy
it.
So
it's
it's
doing
a
cost
comparison
of
what
they
spent
building
an
internal
tool.
Only
to
then
not
have
it
work
out,
they
spent
a
lot
of
money
and
it
did
not
work
out.
Having
read
about
it,
it's
a
great
way
to
think
about
how
you
build
your
internal
tooling
as
well.
A
A
You
want
to
build
that
community
because
it
will
let
enterprise
come
to
you
and,
more
importantly,
if
Enterprise
does
knock.
If
someone
says
I
would
really
love
to
use
this
behind
our
firewall
make
it
a
team
decision.
If
you
answer
that
knock,
it
is
definitely
something
that
requires
team
buying.
It
is
not
something
for
one
single
person
to
go
and
do,
and
that's
everything.
Thank
you
very
much.
A
And
as
a
little
special
easter
egg,
I
don't
know
if
you
know
this,
but
our
little
mascot
is
called
travis
he's
mr.
t
to
us
and
who
knows
Bob
the
Builder
yeah,
so
Bob
the
Builder
has
a
character
called
Travis.
So
when
Travis
was
first
built,
it
used
a
tool
called
Bob
which
did
building
so
Travis
was
an
add-on,
so
Travis
was
named
after
a
character
off
Bob
the
Builder.
Thus,
when
you
look
at
a
mr.
t,
he
use
a
construction
person.