►
From YouTube: How Stripe builds APIs and teams - GitHub Universe 2019
Description
Presented by Michael Glukhovsky, Developer Advocate at Stripe
Stripe’s global team builds economic infrastructure for the internet, maintains hundreds of distinct API endpoints, and deploys more than 4,000 API versions per year. In this talk, Developer Advocate Michael Glukhovsky, will share what engineering teams can derive from thoughtful API design—and how Stripe applies these learnings to accelerate product velocity, while maintaining a sharp focus on customer experience.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
2019
marks
the
fiftieth
anniversary
of
the
Apollo
moon
landing.
When
NASA
wrote
the
original
engineering
requirements
for
the
Apollo
mission,
it
didn't
even
mention
the
word
software
in
his
book,
digital
Apollo,
MIT,
Aeronautics,
Professor,
David,
Mindell
wrote.
Software
was
not
included
in
the
budget
and
it
was
not
included
in
the
schedule
but,
as
he
may
know,
Safra
ended
up
being
critical
to
the
Apollo
mission
running
the
ignition
sequence,
automatic
maneuvers
and
onboard
controls
on
the
spacecraft.
In
fact,
you
can
find
the
Apollo
mission
source
code
on
github.
A
Today,
Margaret
Hamilton
joined
the
program
in
1961
to
develop
software
for
the
Apollo
guidance
computer
and
in
1965
she
became
the
team
lead
later
coining.
The
term
software
engineering
by
1968
over
400
people
were
writing
software
for
the
Apollo
program.
Software
was
going
to
help
the
u.s.
get
to
the
moon.
A
A
With
so
many
software
engineers,
NASA
MIT
quickly
found
that
their
biggest
challenges
were
organizational.
They
had
to
manage
communication
problems,
trained
new
hires,
build
unit
and
integration
tests,
and
they
ultimately
designed
their
codebase
as
a
series
of
independent
modules,
so
that
work
could
proceed
in
parallel.
A
set
of
Central
Committee's,
managed
design
and
development
process,
and
each
module
was
verified
in
two
paws
independently.
With
the
Flight
Readiness
review,
there
was
little
margin
for
error
and
real
world
impact
for
human
lives.
For
every
decision.
A
The
Apollo
team
made
code
was
prepared
for
launch
on
a
series
of
punch
cards
and
then
hardwired
into
a
four
read-only
memory
called
core
rope
memory
with
composed
of
ferromagnetic
ceramic
rings.
In
a
fine
wire
thread,
a
1-bit
was
stored
by
threading
the
wire
through
the
core,
while
a
0
bit
was
stored
by
bypassing
the
core,
and
this
design
was
resistant
to
radiation
in
space
and
could
store
about
1,500
bits
per
cubic
inch.
A
A
The
Apollo
mission
is
an
incredible
snapshot
of
how
hard
it
is
to
build
software.
They
had
to
start
quite
literally
from
the
ground
up
and
had
to
learn
all
the
hard
lessons
of
building
infrastructure
software
with
a
lofty
goal
and
an
incredibly
compressed
timeline,
and
in
the
decades
since
the
exponential
rise
in
Hardware
computing
power
significantly
raised
the
stakes,
software
could
suddenly
solve
incredibly
complex
problems
with
the
same
questions.
A
The
Apollo
team
learned
and
needed
to
answer
suddenly
magnified
and
we've
all
been
relearning
those
lessons
in
the
decades
since
which
brings
us
to
how
we
deal
with
this
problem
at
stripe.
We
build
economic
infrastructure
for
millions
of
businesses
around
the
world
and
expose
it
via
an
API
platform.
When
you
operate
infrastructure,
the
decisions
you
make
about
how
to
build
software
impact
everyone
who
relies
on
your
service.
We
process
more
than
250
million
API
requests
every
day
deploy
more
than
4,000
API
versions.
A
A
A
One
of
the
things
our
team
has
discovered
is
the
most
important
principle
is
users.
First,
this
lesson
is
well
learned
by
the
best
product
and
engineering
teams
across
our
industry
always
start
with
your
user.
I
had
to
learn
this
myself
before
starting
stripe
before
joining
stripe,
I
started,
rethink,
DB
a
database
and
developer
tools.
Company.
Our
very
first
release
was
based
on
our
own
system,
software
and
research
development.
A
Vernor
Vogel's,
Amazon
CTO
and
one
of
the
chief
architects
behind
AWS
outlined
their
approach
to
their
approach
to
designing
for
users
in
a
process
called
working
backwards,
where
they
create
four
documents
before
starting
any
project
that
press
release
an
FAQ,
an
outline
of
the
customer
experience
and
the
user
manual.
As
the
name
suggests,
it
may
seem
backwards
to
start
with
the
user
manual
in
the
press
release.
A
With
your
tools:
Donald
Knuth,
author
of
the
legendary
tome,
the
art
of
computer
programming,
the
typesetting
system,
tech
used
by
scientists
and
engineers
all
around
the
world
noted
I
came
to
the
conclusion
that
the
designer
of
a
new
system
must
not
only
be
the
implementer
in
the
first
large-scale
user.
The
designer
should
also
write
the
first
user
manual.
A
If
the
separation
of
any
of
these
four
components
would
have
hurt
tech
significantly
if
I
had
not
participated
fully
in
all
these
activities,
literally,
hundreds
of
improvements
would
never
have
been
made
because
I
never
would
have
thought
of
them
or
perceived
that
they
were
important.
A
similar,
intense
focus
on
users
is
a
core
part
of
stripes
pthose
users.
First
is
one
of
our
company's
operating
principles
and
you'll
often
hear
us
mention
it
in
conversation
with
each
other.
A
It's
also
a
critical
part
of
our
history
back
when
stripe
was
a
fledgling
startup
in
a
small
office
in
downtown
Palo
Alto
building
out
the
very
first
version
of
the
stripe
API,
the
team
sat
with
prospective
users
and
carefully
interviewed
them
on
the
API
design.
It
took
three
major
redesigns
before
it
shipped
and
for
an
early-stage
company.
This
is
an
eternity,
but
with
stripes
focus
on
developers,
we
realized
it
was
critical
to
both
get
the
right
semantics
and
build
something
that
just
felt
good
to
use.
A
Engineer's
wrote
the
documentation
for
each
api
resource
and
in
the
early
days,
every
api
error
would
trigger
an
email
to
John
and
Patrick's
inboxes,
and
every
support
ticket
would
page
their
cell
phones
and
they
often
pair
program.
These
first
stripe
integrations
with
their
users
and
to
this
day
we
still
maintain
the
same
IRC
channel
and
habited
by
our
earliest
users,
who
provide
us
with
key
feedback
on
our
API
designs,
our
most
passionate
users
cement
our
culture
of
investing
in
API
design.
A
For
example,
this
year
we
designed
a
new
set
of
asynchronous
payment
api's
to
support
new
European
regulations
to
secure
payments
called
strong
customer
authentication.
We
sent
a
team
to
London
to
introduce
users
to
these
new
api's
to
spend
time
with
them
in
person
and
introduce
the
documentation
and
writing
the
announcement.
Blog
post
and
the
FAQ
before
starting
a
new
project
or
implementation
is
still
a
very
common
practice
at
stripe
for
product
briefs.
Here's
an
example
describing
new
support
for
paper
checks
and
our
billing
product.
A
We
gather
feedback
directly
from
our
API
documentation
and
the
developer
view
in
the
dashboard
with
a
CSAT,
metric
and
comets.
These
are
then
reviewed
by
developer
experience,
teams
and
funneled
directly
to
product
development
teams.
In
fact,
our
best
products
often
emerge
from
this
ongoing
conversation
with
our
users.
After
seeing
many
users
follow
an
extract,
transform
load
pattern
with
stripe
data
to
produce
custom
reporting,
we
created
Sigma
to
allow
users
to
rapidly
query
the
stripe
dataset
directly
using
the
common
sequel
interface.
A
We
have
multiple
teams
across
the
company
continuously
talking
to
and
learning
from
users,
including
our
UX
research
teams,
product
managers,
deployment
teams,
support
engineers
and
developer
experience
teams.
In
fact,
we
encourage
everyone
within
stripe
to
talk
to
users
in
whatever
capacity
they
operate.
We
maintain
ongoing
lists
of
the
top
asks
from
businesses
of
all
sizes
and
across
geographies
to
provide
a
total
view
on
what
the
platform
needs
to
provide
as
an
infrastructure.
The
foundation
of
our
roadmap
is
built
from
seeing
patterns
of
need
across
these
conversations
with
our
users.
The.
A
Next
principle
is
that
you
just
have
to
spend
time
making
it
good
in
San
Francisco.
We
love
baking,
sourdough
bread
and
it's
a
delicious
metaphor
for
the
effort
that
goes
into
developer
experience.
The
ingredients
are
exactly
the
same:
every
single
time:
flour,
water,
salt,
yeast
and
your
first
attempts
are
going
to
be
disastrous,
but
as
any
true
sourdough
Baker
will
tell
you
over
time,
you
perfect
a
recipe
and
it
kind
of
becomes
really
special.
It's
a
labor
of
love,
and
it
just
takes
time.
A
You
can
feed
the
starter
for
more
than
a
year
and
every
time
you
bake
a
loaf,
it
just
gets
a
bit
better
should
euler?
Should
you
use
more
water,
less
salt,
more
time
to
prove
need
harder
or
need
lighter
you
learn
more.
Every
time
you
make
a
mistake.
An
API
design
is
like
this
to
every
small
decision.
Humid
Lee
makes
the
difference.
A
The
stripe
API
is
often
perceived
as
being
deeply
consistent
and
polished,
and
people
often
ask
me:
what's
the
secret
behind
your
approach,
the
simple
truth
is
that
there
is
no
secret.
You
just
have
to
spend
time.
I
think
that
there's
no
way
around
this
law
of
physics
and
API
design
you
have
to
put
in
the
time
to
make
using
the
API
delightful.
That
means
a
lot
of
engineers
who
understand
our
users
need
to
be
involved
at
all
stages
of
development
lifecycle
for
any
API.
A
A
A
Api
should
be
composable,
they
should
be
additive.
Building
blocks
should
fit
together.
Our
goal
is
that
every
component
of
the
platform
will
work.
Predictably,
with
every
other
component.
Whenever
there's
a
point
of
friction,
we
apply
effort
to
smooth
it
out.
As
you
use
more
stripes
API,
you
gain
a
cumulative
advantage.
For
example,
we
often
find
that
our
users
start
with
our
connect,
API
and
then
steadily.
Add
billing,
then
terminal
then
Sigma
as
their
business
evolves
and
they
seek
to
unlock
new
functionality.
A
Next
is
predictable,
api's
our
infrastructure.
When
you
turn
on
the
tap,
you
expect
water
to
come
out
and
when
you
check
a
Swiss
watch,
it
tells
you
the
right
time.
When
you
perform
an
operation
multiple
times,
you
should
expect
the
same
operation
and
the
same
outcome.
So
we
provide
idempotent
operations
so
that
users
can
safely
rerun
transactions
without
worrying
about
accidentally
duplicating
charges.
A
Each
of
these
design
principles
enables
stripe
businesses
to
reliably
integrate
with
any
number
of
our
api's,
operate
them
at
scale
and
maintain
them
over
time
with
a
minimum
of
effort.
Finally,
api's
should
be
backwards
compatible
by
design.
You
can
continue
transacting
on
stripe,
using
your
existing
technical
integration,
even
as
we
add
new
features
and
involve
our
design.
You
can
then
choose
when
to
upgrade
your
infrastructure
when
you're
ready.
A
A
A
We
have
a
cross-functional
review
team
with
expertise
and
our
platform
operations,
developer,
experienced
front-end,
tooling
security
practices
and
other
areas
across
stripe.
This
group
meets
in
person
to
discuss
questions
like
are
the
changes
consistent
with
design
patterns
across
our
API?
Will
the
experience
feel
consistent
when
using
different
programming
languages
for
different
client
libraries
with
stripe?
How
would
this
look
and
feel
to
someone
outside
the
stripe
organization?
How
might
this
break
user
expectations?
How
might
the
change
affect
API
is
that
layer
on
top
of
the
proposal?
A
A
Our
team
then
irons
out
any
bugs
documents,
the
new
feature
and
issues
a
new
API
version.
When
we're
ready
to
go
live.
We
then
incremental
e
roll
out
the
feature
to
users
across
our
platform
and
keep
a
close
eye
for
any
issues
that
might
come
up.
The
key
to
this
process
is
that
we
introduce
as
many
opportunities
as
possible
for
feedback
from
experts
across
the
company
and
we
avoid
building
our
products
in
isolation
from
our
users.
A
One
of
the
most
important
opportunities
for
expert
feedback
in
that
flow
is
our
stripe.
Api
review.
This
team
of
engineers
encourages
a
culture
of
great
API
design
and
over
the
years,
they've
arrived
at
a
set
of
encouraged
design
patterns.
I'm
going
to
share
a
few
of
them
today,
drawn
from
the
concrete,
checklists
and
guidelines
that
we
use
internally.
A
Here's
a
good
one,
avoid
industry
jargon:
our
users
shouldn't
need
to
be
experts
in
payments.
Stripe
should
provide
familiar
tactile,
parameter
names.
Every
credit
card
has
that
long
number
across
the
front,
it's
known
as
a
primary
account
number
or
pan,
but
we
say
card
number
and
not
card
dot
pan
on
our
API.
Everyone
understands
the
word
number,
but
only
insiders
know
pan.
A
Some
of
these
examples
are
going
to
get
even
more
detailed.
For
example,
we
use
nested
structures
to
group
related
concepts
rather
than
flattening
everything
to
the
top
level.
This
improves
understanding
and
enables
future
extensibility
more
details.
Properties
in
API
are
preferred
as
enums
rather
than
billions.
We
can't
predict
all
possible
future
states
for
a
property
here.
You
can
see
an
example
from
stripe
issuing
if
we
chosen
to
make
cancelled
a
boolean
to
denote
active
or
canceled
states
for
hard.
We
couldn't
have
later
added
the
inactive
state
when
we
later
realized
that
we
needed
that
too.
A
If
an
API
request
affects
an
object
state,
it
should
be
reflected
in
the
response.
As
an
example,
you
can
see.
The
request
here
is
modifying
the
customer's
description
to
hello.
It's
important
that
hello
is
reflected
in
the
response.
So
you
know
a
P
I
request
is
successful
and
did
what
you
expected.
A
We
have
a
consistent
pattern
for
polymorphic.
Ap
is
sometimes
api's
can
return
multiple
types
of
objects,
but
we
want
to
provide
one
generalized
api,
so
we
can
include
a
polymorphic
response
for
each
type.
Polymorphism
and
api's
is
notoriously
difficult
to
get
right
and
the
best
pattern
we've
arrived
at
for
developers
is
to
rely
on
a
type
field
to
easily
disambiguate
what
kind
of
object
you're
receiving
and
provide
parameters
that
are
unique
to
that
type.
In
a
designated
nested
structure.
A
Side-Effects
and
meaningful
changes
should
be
expressed
through
verbs
when
you
are
substantially
modifying
a
core
API
resource.
An
explicit
verb
makes
it
much
easier
to
understand
that
there's
a
state
transition,
for
example,
we
capture
the
payment,
intent
or
mark
the
invoice
is
uncollectible,
and
this
gives
us
a
neat
and
understandable
pattern
for
time
stamps
related
to
changes.
Any
such
timestamp
should
be
expressed
as
verb
at.
A
Finally,
API
review
explicitly
encourages
providing
early
access
to
rapidly
iterate
on
designs
with
beta
users.
A
critical
part
of
our
infrastructure
is
a
system
of
software
gates
that
unlock
new
functionality
on
our
platform.
This
enables
us
to
invite
external
users
to
try
a
new
feature
before
it's
released
to
the
general
stripe
user
base
teams
are
encouraged
to
trial
a
few
designs
with
users
as
have
L
on
the
best
options.
For
example,
the
stripe
issuing
API
was
developed
behind
a
gate
for
over
a
year.
A
It's
also
important
to
remove
these
gates
aggressively
once
the
feature
has
shipped
you
don't
want
to
maintain
multiple
code
paths
for
very
long,
and
so
what
may
seem
like
smaller
details
are
an
aggregate,
highly
impactful.
Of
course,
none
of
these
are
hard
and
fast
rules.
There
can
often
be
a
good
reason
to
make
an
exception.
The
API
review
team
holds
in
person
discussions
to
examine
the
spaces
in
between
and
identify
the
right
solution
for
users.
A
A
The
only
Google
results
for
issue
or
fraud
record
were
striped
documentation
pages,
so
our
product
team,
our
product
team,
brainstormed
some
new
options
and
renamed
this
to
the
early
fraud
warning
API,
which
more
closely
captures
the
essence
of
the
functionality
that
that
API
provides,
and
that's
just
one
example
of
why
an
essential
challenge
and
API
design
is
naming
each
stripe.
Api
resource
should
have
an
easy-to-understand
name
and
we're
obsessive
about
name
naming,
because
it's
for
a
global
audience
names
like
customers,
payment
methods
and
disputes.
A
It's
not
just
that
they
need
to
make
sense,
but
that
users
will
need
to
type
them
over
and
over
again
and
each
time
that
they
do
so.
It
acts
as
a
touch
point
for
stripe
and
names
have
long
lives.
You
can
look
to
the
basic
unix
commands
that
still
live
at
the
core
of
Linux
and
Mac.
Os
servers
that
we
use
today
with
arcane
names
like
CP,
RM
and
mV.
Why
are
they
so
cryptic?
A
A
So
if
you
were
working
the
whole
day,
you
would
really
feel
it
in
your
knuckles
and
that's
the
reason
why
the
UNIX
command
repertoire
has
these
short
names,
because
if
it
could
save
typing
one
keystroke
per
command,
it
really
helps
and
we're
still
using
these
same
Unix
commands
today.
So
we
take
this
very
seriously.
We
expect
the
names
that
we
choose
will
live
on
in
software
systems
for
a
very
long
time.
A
We
also
spend
a
lot
of
time
building
with
our
own
api's
to
experience
any
pain
points
firsthand
ourselves
when
I
talk
to
interview
candidates,
the
one
of
the
basic
questions
I'm
curious
to
answer
is:
what
are
you
building
it's
surprising?
How
many
organizations
operate
in
a
way,
that's
divorced
from
the
product
that
they
build
for
their
users.
A
Microsoft
manager,
Paul
Maritz,
coined
the
term
dog
fooding
inspired
by
Alpo
dog
food,
whose
spokesperson
famously
proclaimed
that
their
product
was
so
good.
His
own
dogs,
loved
in
a
Talpiot
everyday
and
at
Microsoft
merits
insisted
that
all
employees
adopt
the
Microsoft
land
manager,
so
they
can
understand
firsthand
themselves
how
the
product
should
be
improved
and
the
idea
caught
on.
A
A
We
also
produce
focused
reviews
of
particular
api's
or
products,
and
ask
teams
to
write
up
developer
experience
friction
logs.
The
goal
is
to
produce
a
log
of
every
command
that
you
run
and
your
personal
reactions
along
the
way.
Noting
things
like
I
found,
this
section
of
documentation,
confusing
or
I,
was
frustrated
by
the
number
of
steps
this
took,
and
this
captures
the
sharp
edges
in
experience
that
a
typical
bug
report
can't
capture
and
many
stripes
also
run
a
side
project
or
family
business.
On
our
platform.
A
We
encourage
this
because
it
provides
us
with
even
more
first-hand
experiences
using
our
tools
and
platform
and
here
a
few
examples.
One
of
our
engineers,
Johnny
Holman,
manages
cushion
which
helps
freelancers,
manage
their
clients,
invoices
and
projects
and
uses
billing
for
invoices
Sigma
for
analytics
and
Atlas
for
incorporation
and
Barrie
Paget.
A
Our
CRO
runs
a
horse
farm
Koro
equestrian,
who
board
trained
and
provided
clinic
for
horses
in
northern
Washington,
and
they
use
billing
for
invoices
and
at
stripe
we
love
to
get
creative
with
our
emoji,
who
doesn't,
and
so
our
CTO
David
singleton
created
hot
dog
pins
calm
to
sell
custom
pins
for
all
our
favorites,
like
this
skiing,
hot
dog
and
I,
hear
he's
trying
to
meet
his
revenue
goals
by
end
of
years.
So
you
should
go
visit
it
after
the
talk,
and
that
brings
us
to
our
final
principle
design.
Your
organization.
A
When
we
look
back
to
the
Apollo
mission,
one
of
the
emergent
properties
that
they
discovered
was
the
importance
of
setting
up
the
right,
effective
organizational
structures
and
establishing
a
clear
vision.
One
of
the
mythic
stories
from
that
era
is
of
JFK's
first
visit
to
NASA
headquarters,
and
while
he
was
there,
he
noticed
a
janitor
carrying
a
broom
and
he
asked
him.
What
are
you
doing
and
he
interrupted
his
tour
and
and
and
went
over
to
ask
him
this
question.
Excuse
me,
sir,
what
are
you
doing?
Well,
mr.
A
However,
it
was
significantly
harder
to
establish
shared
vision
across
a
sprawling
army
of
NASA
personnel,
MIT
scientists
and
contractors,
so
they
designed
new
organizational
structures
in
the
final
report
of
the
Apollo
guidance.
Oft
wear,
Task,
Force
NASA,
concluded
quote
the
difficulties
in
software
development
will
continue
to
require
top-level
management
attention.
Software
complexity
requires
a
high
level
of
communication
and
participation
by
the
many
organizations
involved
in
that
process.
A
This
especially
holds
true
for
software,
as
we've
steadily
replaced
our
physical
world
with
software
systems.
We
can
learn
a
lot
about
why
software
works
a
certain
way
by
examining
the
organization
which
created
it
as
a
basic
example.
If
five
software
teams
work
on
a
software
system,
there
will
tend
to
be
five
software
components,
but
Conway's
law
has
an
inverse
corollary.
You
can
be
intentional
about
how
you
build
a
software
engineering
organization,
knowing
that
will
be
reflected
in
the
work
you
produce.
A
When
you
look
at
a
map
of
our
products,
you
can
observe
something
else:
spoiler
alert
this
maps
to
our
org
chart.
Internally,
we
have
a
payment
infrastructure,
team
and
foundation
groups
whose
work
building
the
Global,
Payments
and
Treasury
Network
supports
multiple
product
groups
for
everything
you
see.
That
runs
on
top
of
that
network.
A
Stripe
is
a
global
engineering
organization
because
of
our
scale,
it's
important
to
build
cultural
and
communication
systems
that
support
quickly
building
new
ap
is
in
a
distributed
and
parallel
fashion,
and
a
critical
part
of
our
communication
system
is,
of
course,
github.
We
maintain
an
internal
mono
repo
where
most
of
our
daily
work
unfolds,
hundreds
of
thousands
of
commits
code
review
and
adjacent
infrastructure
to
help
us
deploy
thousands
of
versions
of
the
stripe
API.
A
Every
year
we
use
github
enterprise,
not
just
as
shared
infrastructure
for
code,
but
to
enable
everyone
from
API
engineers
to
marketing
teams
across
stripe
to
contribute
to
projects.
We
teach
team
members
to
use
these
shared
tools
as
a
collaborative
environment,
shared
tools,
help
cross
team
boundaries
and
act
as
social
infrastructure.
A
We
extend
this
operating
model
to
how
we
collaborate
and
work
with
hundreds
of
stripe
and
stripe
users
to
build
our
core
client
libraries
like
no
J
in
languages
like
nodejs,
Python,
Ruby,
Go,
Java,
PHP
and
dotnet,
and
we
maintain
these
open
source
projects.
So
we
learn
an
incredible
amount
of
what
our
users
want
by
building
alongside
them
and
whenever
possible,
we
open
source
the
tools
we
create
internally,
so
we
can
share
them
with
the
world
and
improve
the
developer
ecosystem.
A
Most
recently,
we
released
sorbet
a
fast
type
checker
for
Ruby,
which
we
use
extensively
at
stripe.
Sorbet
ism
is
multi-threaded,
checking
millions
of
lines
of
code
by
scaling,
Linda
Lee
across
cores
in
the
CPU
and
comes
with
a
vs
code
plugin
and
is
used
by
companies
like
Shopify,
coinbase
and
Kickstarter
tools
like
sorbet
help
us
keep
our
development
process
safe
and
consistent
across
a
global
organization.
A
The
constellation
of
API
design
principles
and
shared
tools
enable
us
to
support
millions
of
internet
businesses
of
all
shapes
and
sizes.
Every
company
is
unique,
but
by
providing
the
right
building
blocks,
we
hope
to
help
them
shape,
how
they
build
our
organizations,
how
they
communicate
and
in
turn,
build
software.
A
The
lessons
we've
learned
don't
just
apply
to
API
platforms.
All
engineering
teams
can
study
their
own
practices
to
better
understand
exactly
how
they
build
their
product.
Here's
a
few
things
you
can
try
with
your
own
team,
first
build
for
your
users
of
today,
but
consider
your
platform
of
tomorrow
interview
users
carefully
consider
patterns
of
feedback
as
you
northstar,
but
remember
that
every
feature
that
you
build
you'll
need
to
support
for
a
very
long
time.
A
Next,
you
have
to
build
for
builders.
The
best
ap
is
our
building
blocks.
That
creators
can
use
predictably
to
design
a
solution
for
their
own
unique
needs.
Ap
is
our
infrastructure.
You
can't
always
predict
how
users
will
build
on
your
api's,
but
your
knows,
most
novel
products
will
surely
Ammar
emerge
from
it
from
enabling
their
creativity
and
finally
design
your
organization
and
communication
structures
to
support
your
product.
You
can
influence
your
products,
quality
and
design
by
changing
how
your
team
communicates
and
organizes
itself.
So
these
are
the
lessons
that
we've
learned
along
the
way.