Scaling your Startup from PoC to ProductionA tale of technological and human struggles

Johann Romefort, Tech Evangelist @Stylight

Hi, I’m Johann!

● Tech Evangelist @Stylight

● Since 3 years in Munich

● A certain passion for building communities

● Before: 7 years in San Franciscobuilding startups

Program ● The Technical Cheat Sheet of Doing a Startup● The Human Cheat Sheet of Doing a Startup● Scaling your team & Building your network

The Technical Cheat Sheet of Doing a Startup

The Craziness of Building a Tech Startup

● Compressing time● Getting on the roller-coaster● Living in a bubble

PoC? Prototype? MVP? Production?

PoC: Demonstrate/Validate an idea - no UI required

Prototype:Get a step further and build something that people can play with

MVP:Get one step further and get it in the hands of future audience

Production: Shit gets real and so is a myriad of problems :)

Some deadly technical mistakes and oversights

1/ Premature Scaling

Premature Scaling 1. 74% of high growth internet startups fail due to premature scaling.

2. No startup that scaled prematurely passed the 100,000 user mark.

3. Startups that scale properly grow about 20 times faster than startups that scale prematurely.

4. 93% of startups that scale prematurely never break the $100k revenue per month threshold

70% of the startups are scaling prematurely

Source: Startup Genome Report - Data based on an analysis of about 3200 high growth internet startups

What’s premature scaling?

2/ Over-engineering

On the cutting edge of technology

Our product runs on Kubernetes, with fully containerized Rust microservices talking through a Kafka messaging queue, with a VueJS frontend.

We have 10 users, and growing fast.

Exotic tech stacks,just because you can

I built majestic monoliths for a living

Sounds cool!

What’s a Monolith and how do I build one?

● A whole system in one giant black box

● Much easier to build than distributed application

● You generally build one without even thinking about it

When does it make sense to build a monolith?● Proof of Concept ● Prototype● Early production

WHY?

● Because anything else before Product-Market fit is *NON-SENSE*

On being CTO at hot startup in San Francisco

My first year as a CTO● Put a monolithic prototype in production● With no monitoring● No continuous integration● No continuous deployment● No testing● … and kept adding features...

Codebase after a year

● Failing from everywhere

● Fixing one part created more bugs

● Developers scared to touch it

Deployements became HELL

● Bringing down the site for hours

● Lighting up candles

● Praying

● Rolling back

● Felt like russian roulette

Me, 10 years ago...

Oops, I crashed TechCrunch :)

How do we fix this? We patch it!

Hire a QA Manager● Create Testing/Staging

env.● Test > Stage > Deploy● Feared by the Devs● Hated by the CEO

Add an “Ops” guy● Create the build● Prepare the deploy● Locks everything so

devs can’t play with prod

● Wake up when servers on fire

● Also feared by the devs...

Impact of poor code base on developers

● Frustrated of slow release process

● Chain of Command way too long● Feeling powerless and scared● Low trust & Autonomy● High hit-by-the-bus factor

Impact on Product ● Frustration of slow

execution● Frustration of having to

ask for everything● No autonomy● Don’t understand

developers

Introducing:

BIG-BANG REFACTORING

Let’s rewrite everything from scratch!● Developers love it (they get rid of their tech debt)● Your CEO will HATE YOU.● Your Customers will HATE YOU.● You might never catch-up with your legacy system● You might just crash the company into the ground

What you should do instead

Break down application into smaller autonomous units, piece by piece.

Break down team into smaller autonomous units

Automate what can be automated Continuous Integration and Deployment, and devops your way to success.

Let’s get back to Microservices

● You’re in production ● Start to extract on well domain-defined part of your

monolith (ideally you did a preliminary work on that by designing your code in a modular way)

● Run it alongside your monolith, and have them communicate.

● Rinse & Repeat

An example of domain-defined microservices

Storage in Microservices

Servers in Microservices Architecture

30-seconds meditation on Conway’s Law

Introducing Cross-Functional Teams

● Autonomous team● Different set of skills

but working together● Own metrics and KPIs● Own software/DB● But new challenges...

Microservices + Cross Functional teams = Lean Enterprise

● Unless you don’t have Product-Market Fit - then it’s premature scaling :)● It’s not Unicorns and Rainbows either● The bigger the monolith & the more rigid the organization, the harder it is●

</microservices>

Looking for money? Let’s talk about Tech Due Diligences ● It’s a risk assessment of your technology● You need to prepare for it● Most likely you’ll be locked one full-day

giving details about your technical choices, your engineering team, etc..

Things to watch out for:

● Are you using any GPL code?● Do you have licences of all the products

you’re using● Ability to give a clear picture of the

architecture● Being transparent on technical debt and

your PLAN to reduce it.● Know where are the Single Points of

Failure in your architecture and have a PLAN.

● Is there any engineer that detain unique knowledge about a part of the code?

● What happen if X is hit by a bus?

Designing your architecture for scale

○ Simple tools for simple tasks○ Automate, automate, automate: CI / CD○ Make sure your code is 90%+ Tested○ Monitoring everything early on.○ Measure everything: Analytics are vital.

The Human Cheat Sheet of Doing a Startup

Managing Expectations (your own and other’s)

○ Energy Management vs Time management

○ How to say NO to your CEO○ Technical debt○ Virtues of being honest

with oneself and transparent with others

Things you always forget

The value of mentoring

Keeping focus

Sleep Paying it forward

This is where you ask me questions!

Scaling your team and building your network

Why is Hiring Tech People so Hard?

Source: StackOverflow Insights Survey 2017

Source: StackOverflow Insights Survey 2017

Source: StackOverflow Insights Survey 2017

Hiring the right people○ Let’s talk about Divas○ Slow Experts vs Scrappy Doers○ The “Hit-By-The-Bus” factor

Distributed Team or Onsite Team?● I’ve managed a team of 60+ engineers all over

the world:

○ Multiple US-location/timezones○ Bucharest○ Singapore○ France○ Germany

Where to find talents?

1/ Your employee network

2/ The network you’re building

3/ Recruiters? Eerr no thanks.

PAY IT FORWARD

It will eventually come back to you.

How can I help?

@romefort

johann.romefort@stylight.com

http://linkedin.com/in/romefort