What is it like to launch a company in 2018?

Honestly this is easier than ever, thanks to new laws that have been able to bootstrap a whole ecosystem of startup focused on easing your “administrative” tasks as a founder!

1- Legal Setup

The time of gibberish forms and endless back and forth with the administation is over, you can now start a company 100% digitally - without hassle — and have everything ready in 3 to 4 days maximum!

For that purpose we used LegalStart.fr

The big plus is that even if you are new to entrepreneurship, LegalStart provides you with very good information and advice — definitvielty a great source of knowledge.

2- Banking

One big part of the process of setting up a company is to open a bank account (it’s mandatory) — and sadly banks are usually a huge hassle. On the consumer level a lot of new options are now available (N26, Revolut etc.), but don’t worry entrepreneur have not been forgotten!

You can now open a bank account, have an IBAN and Credit Cards in few clicks, no phone call, no paperwork and most importantly no opening hours!

For that purpose we use Qonto.eu

The nice thing is that Qonto and LegalStart are partners, making the whole capital process very simple.

Disclaimer: As of today these solutions are not yet fully comparable to “traditional” bank offers, meaning that if you plan to keep lot of money (for ex. with a VC round) you will probably still have to open a traditional bank account later. That said it might change with the future opening of MargoBank and still it’s a great solution for many.

3- Office Space

Working remotely is definitively a great option in 2018, still you might want to get an office, meet with co-workers or simply don’t feel working alone.

In France, renting an office is legally very constraining (“bail 3/6/9”), expensive, subject to taxes and therefore not flexible. That’s also changing thanks to CoWorking Spaces that boomed in the last 18 months.

If you live in Paris, there are literally dozens of very nice co-working spaces. You can rent — without any commitment — from a single desk to a 2 or 50 people closed office in a matter of hours and be ready to work asap (Internet, furniture, meeting rooms, kitchen, coffee etc.- all included).

There are even startups handling that search & find process for you!

For that purpose we used Kowffice & LeoSquare and ended-up renting at At Home.

4- Employee Pay & Health Insurance

Now that you are ready to hire people you need to manage what we call “The Pay” and everything that goes with it. Remember France is a welfare state, meaning it doesn’t come free of charge and administrative complexity!

That said this complexity is now a thing from the past — you don’t need to read the entire labor code anymore or hire dedicated people to manage it.

For the pay we use PayFit
Payfit is even able to manage employee’s expense report and obviously link that to the monthly pay. They handle every possible scenario which is highly impressive.

For the health insurance we use Alan
The nice thing is that PayFit and Alan did partner and the link between them is automated!

What else do you need to handle?

Accounting — There are startups that try to ease that part (Fred), but at the end it is a person’s job where trust is key.

Legal — Same apply to lawyers, and probably even more. Legal is about lot of different highly critical topics — corporate legal, IP, employment law etc. — that you don’t want to underestimate! The best idea is to have someone that can coordinate all those different aspects for you.

Insurance — If you have an office you legally have to get insurance and besides it’s a good idea to get one for the company. It’s fairly easy with lot of private offers, some are now even focusing on startup like YesAssurances.

I hope this post will make you want to start a company in France and even help you, remember we now are a Startup Nation!

How to start a company in France — 2018 was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Who didn’t try Docker? But who succeeded in setting-up an efficient and clean development environment with it? Sadly a lot less :(

Using docker in development is a lot trickier than running it in staging or production from a functional standpoint (let’s not start a :troll:). Let’s see in this article what are the issues, how to circumvents them and finally how to make everything easier with the Dockrails Gem!

Common issues

1- Docker Compose

Your application is probably not just a simple app container, but chances are you will need one or more databases (mysql, pgsql, redis etc.) and even a job container or more. This is where Docker-Compose comes to play, by using a docker-compose.yml file you get to describe your containers and their link between each other.

2- Code sync

In development you code on your docker host machine (Mac etc.) with your favorite editor (Atom, Sublime, Vi etc.) and instantly refresh/run it — something that docker is not intended for. To be able to perform this sync you need to have your code base shared as a volume between your host and your container (both ways), sadly docker shared volume is so slow that it makes it unusable for this task!

Luckily a very smart guy, Eugen Meyer, came up with a tool called “docker-sync” that provide near instant sync. This tool come with a built-in command docker-sync that sit on top of docker-compose.

2- Data persistence

Each time you restart a container it does lose all its previous data (containers are stateless), meaning your databases get lost, your Gems too etc. To enable persistence you need to use a docker volume and mount the desired folder(s) to it and then reference everything in docker-compose.yml.

3- Live debugging in the console

If you’ve tried it yourself chances you discovered that it wasn’t straightforward to be able to use Pry or ByeBug while running your app in a container. The solution is to use docker-attach with the container image name and add a few lines in your docker-compose.yml.

4- Git/SSH Access

Did you find yourself needing to access a Git repository or perform an SSH session, from a container? You probably don’t want to add yet an other key that might get lost or changed at the next container reboot! The solution is to share your host SSH keys with your containers and possibly deal with the known_hosts message in advance.

5- Commands hell!

If you are not familiar with docker it can get a bit messy and add a lot of overhead for your day to day workflow. Most of us are used to a set of commands in development, like bundle exec rails start, bundle exec rake db:migrate etc. and we don’t want to add complexity because we are using Docker. In addition to the docker command we introduced docker-compose and docker-sync, now go figure out which one to use and how to combine them with your development workflow!

Let’s introduce Dockrails!

I strongly believe in simplicity and automation, after discovering and circumventing all the above issues I was very satisfied with my docker environment for development. Finally, I was able to ditch Vagrant and the heavy Virtual machine.

To make all of this much easier I designed a simple CLI (through a Gem) called Dockrails, it provides an interactive command to build and run your environment without falling into the commands hell!

Now you don’t have any more excuses to not use docker in development and build a reusable environment!

Get Dockrails on Github: https://github.com/gmontard/dockrails

If you liked this article please consider clicking the ❤️ below so more people could read it, thank you!

Using Rails and Docker in Development — making them play nice together! was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

It takes a lot of time, a whole lot of time!

I never thought about this before I started, obviously it takes a lot of your day to day time but more importantly it just takes time as in years. It took me almost 10 years and I honestly don’t know if I would have signed for it if I knew. By the way 10 years is the average time for a successful startup adventure.

Hiring is key and yet you will do many mistakes and it’s OK

You have to hire, but the truth is that it’s damn hard and not only in tech jobs, in any jobs! I found this hard because you end-up always looking for the five-legged sheep and even when you found it chances you will need someone different in a year or two because your company changed so much.

Why would the best work for you?

Like I said previously hiring is hard and yet people always say something like “I’m looking only for the best” but did you ask why would those people work for you? Honestly we weren’t Google, Uber or the next Unicorn and chances are most startups aren’t either. You won’t hire “only the best” and it’s OK, you probably don’t need them and won’t be able to handle them anyway. At the end of the day I often even traded really good technical candidates by other I found more as a match with the company, the mindset and that I could help grow with the company. More than hiring people you are building a team!

Taking decision will become natural

Sometimes people ask me how do you do to take such decision without looking back or doubting? Build a company and you will understand! Decision have to be taken everyday and the truth is that usually this is not the decision that matter, there is no right or wrong, only knowing why you took it really matters.

You never have enough money, never!

As a founder you crave to raise fund because you need it to hire people, invest in the product, marketing etc. so once you raise money you think this is it. In fact, no and it only gets worse, money call money and the life of a startup is the non stop growth, in other words more money.

It goes fast, but never fast enough

Building from scratch a company, create a new product, hire dozens of people, make millions of dollars etc. this is amazing to do this in only 10 years! Building a startup can feel like a sprint with a marathon distance, but even that feel too slow when you are in because you always look for the next step.

Focus is key

Everybody says it and yes it’s so true!
I felt this is a schizophrenic thing to do because you need to be open, for instance to get the right business model or market or product fit, but you need extreme focus in the meantime because it’s so easy to get yourself lost in endless path. It’s also very hard for technical/product people because today it’s easier than ever to build almost anything and that is a dangerous thing!

This is the best learning adventure possible

Looking back my 10 years, I learned so many things that I don’t even know from where to start. If you like this feeling of not knowing anything about a topic and starting to catchup time after time, this is just amazing.

It’s a lonely job

Most people don’t talk about it, but I really do feel that way. Usually we create friendship and sometimes even more at work, the place you spend most of your time, but as a founder I don’t see how you can do this and yet it takes 10 years.

Doing it alone would have been impossible

I had two co-founders and I consider this the best approach, I wouldn’t start a company only by myself. Having co-founders help you keep the motivation and brings X times more skills/time on the project which is truly invaluable.

The grass looks always greener on the other side

Don’t read TechCrunch, it’s as simple as that! I’m only half joking, there is sadly a lot of bullshit in this economy so don’t spend too much time listening or you will end-up frustrated for nothing. Focus.

Sometimes you wish you’d have stay small

Crazy right? You spend you entire time growing and yet you do feel it was better once you were only a few. I felt this at about the 20th employees and once you don’t even remember everyone first name then it gets bad, but this is the game.

Your company feels like home

Imagine a place where you spend 50% of your time for years, where you know (mostly) everyone, they all know you, you have all your habit, etc. doesn’t it sound a bit like home?

Exit is the accomplishment you looked for!

When you start a company and raise money you know there will be an exit (good or bad) and this is how most people measure success in this economy. I felt the acqusition of my company as a recognition for all that time and hard work.

Yet an Exit is still an Exit

An exit means you are gone one way or another, this is no longer your company and chances are you won’t work there anymore very soon after. Usually you don’t really control that timing, which is maybe what makes it harder to grasp.

What to do next after such an adventure?

Personally it is still an open question, but I don’t see how not to start something else, it’s probably an addiction!

Below the slides that support this talk.

If you liked this article please consider clicking the ❤️ below so more people could read it, thank you!

What I Learned Spending 10 Years Building a Startup was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

I would like to thank my co-founders, Gabriel and Xavier, with whom this journey would never have happened. Thanks to my amazing engineering team at Vodeclic that I enjoyed so much working with along those years and finally the Skillsoft team, especially Percipio project.

I won’t forget all the people I came across along those years, co-workers, partners, investors, etc. It was a fantastic journey, a once in a lifetime experience!

Anyway it’s time open a new chapter, but not first without some long overdue relaxing vacation :)

Guillaume.

The End of a Great Story was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

For those that don’t know Jekyll, it’s a simple and yet powerful static blog engine, used by Github Pages for instance. I decided to move to Medium and needed a migration solution.

Medium let you import your old blog posts (by keeping date, tags etc.) but there is one small gotcha, it only works with Wordpress! In fact Medium ask you to export your posts with the Wordpress export feature which produce a custom XML file.

Jekyll doesn’t offer export feature, but by using Liquid markup I knew it was going to be possible to reproduce the same export file. Indeed, the solution was simple and took less than an hour to build.

Now time to get hands dirty, start by creating an export.xml file at the root of your blog, use code snippet below which use Jekyll template and liquid variables (you may need to adapt those to your own Jekyll config), download the XML output and use it in the Medium import tool.

Simply put, it works great!

The Markdown -> HTML -> Medium text conversion is fantastic, your old URL are well 301 redirected, tags are presents, images, subtitle etc. the only downside is for code block that I ended-up rewriting quickly after the import was performed.

Below the full Jekyll export file, enjoy!

If you liked this article please consider clicking the ❤️ below so more people could read it, thank you!

Migrating from Jekyll to Medium was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Yesterday, Facebook finally unveiled Workplace, their « enterprise » Facebook offer. By making this move Facebook is entering in a very new and different market, B2B SaaS and it is no small thing even for them!

Do you know a company that is successful on B2B and B2C altogether at a major scale? Chances are that not and this is for a very good reason, it’s damn hard!

Most companies that play in both fields are usually in a transition period, they start as a B2C offer and shift to B2B, but try to keep the B2C revenue along the way. Eventually they kill their B2C offer because they find out that even if the product looks the same, the rest is so dramatically different; from Sales to Marketing, Branding and even Technology (security, deployment, support etc.).

With Workplace Facebook is betting against the odds!

I’m confident that Facebook is not going to reinvent itself and neither loose the consumer model or change its technology or its core principles like the famous « Move Fast and Break Things » (even if they sort of did) and this is exactly why we are about to witness a very interesting journey in the B2B & SaaS landscape.

How does Facebook DNA, deeply linked to B2C, is going to play in the Enterprise?

Take a few topics like data privacy and security? Currently, Workplace doesn’t offer true data isolation between customers and neither offers regional datacenter of your choosing (more info here). All those things are what Enterprise customers tend to ask more and more lately, is Facebook simply going to be able to tell them to forget about it? Even the pricing model is pretty bold for SaaS, MAA (Monthly Active User) is not the norm at all and this is only a few examples.

As of today Workplace is mostly a thin layer on top of the “normal” Facebook.

Facebook Workplace is a bold move, not because the product is a revolution, it’s not, but if Facebook succeed it’s going to affect the whole B2B SaaS ecosystem.

I’m thrilled.

If you liked this article please consider clicking the ❤️ below so more people could read it, thank you!

Facebook, welcome to B2B, seriously! was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s imagine a feature you are launching is bugged (no this never happen!) or is not yet fully ready, but your product team is pushing for a release? This is when it starts to get messy and developers don’t like that!

Starting digging into this problem I found out I wasn’t the only one (shocking!) and also that a whole concept to manage those problems called Feature flipping existed. Let me explain you some of this concept, then dig into real use cases and eventually how I tried to tackle it with my own Ruby Gem Helioth

Feature flipping concept

As I said this concept is not new, in fact it was (first) introduced by Flickr in 2009 in this blog post.
The idea is pretty simple and I like to resume it as:

Having a way to enable or disable a feature in a blink

So how do we make that happen?
First you need a simple interface where all features are described (a configuration file, database etc.). On this interface you should be able to turn each feature status on and off and your app should automatically be impacted. One important thing to remember is that you shouldn’t change any of your application code during this process!

Let’s be fancy and from now on call this concept a Pattern. This feature flipping pattern is also known as:

• Feature flag
• Feature bucket
• Feature toggle
• etc.

Use cases

We introduced earlier the idea to use this pattern to enable or disable a feature in case of emergency. Of course there is more granularity to this use case. Let me introduce you two of them which will be the foundation of what’s coming next.

As a SaaS company when we ship code all our customers gets it at the same time which is pretty cool and one of the few reasons why SaaS is awesome! But we all have very important customers and even more important one (not that all customers are not important!).

I think you see where I’m going! Wouldn’t it be a great to be able to tag the importance of a customer and correlate it with the release stage of a feature? When everything will be fine and well battle tested it will be time to flip the feature to a full production phase affecting even the most important customers!

An other use case that we encounter is related to localization. Our platform is localized in 6 langages and it can happen that a feature is ready, but not yet localized for a specific language. Business and Product departments are pushing for a release and again feature flipping pattern is a pretty good answer. This time we could flag each feature with a set of locales and depending on the user language we enable the feature or not.

Those two use cases are some of the most concerning one for me as running a B2B SaaS Application.

Implementing this pattern

Now that we know the pattern and have some use cases it’s time to get technical!

We said it has to be easy and not impact the full application code. In order to do that we talked about describing the feature set. In fact, we are looking for more than a description, but more a framework. This way the application should implement as little logic as possible, and only make simple call as:

if is_enabled?(:feature)
 #do this
else
 # do that
end

By mixing those requirements and our use cases, let’s right down some of know facts:

• An app has users
• An app has features
• Users are linked to locales (language, ex: :fr, :en, :zh)
• User have a status (ex: standard, important, critical)
• Features also have a status (ex: beta, pre-release, production)
• Features have locales (= localized in x languages)

Here is everything needed to build a description framework! Once in place our application shouldn’t do anymore than asking if a feature is enabled or not while delegating all the logic to this framework.

Ruby / Rails implementation (Gem)

I found many Gems that implement this pattern and (even) some very nice one (ex: flipper, Flip, rollout etc.), but in fact none of them covered my use cases. Decision was made, I decided to build my own Gem and push the concept a little bit further.

One of the main difference with my implementation is the way the decision logic is handled. I decided to put more logic inside the description file by setting a set of status for every objects (feature, user, instance) and then set their relations. At the end I think it’s much easier to read and maintain and give you more granularity.

Like I said the most important thing was having a simple and easy description process. In order to do that I chose to build the gem around a DSL. This DSL is the only thing the developer need to write and all the flipping logic is built behind the scene using it. Using a DSL was not only to be fancy but also to make the process readable and easy for any developers:

To find out more about how it works checkout Helioth Github repository

Have fun and please give me your feedback to improve it!

Introducing Helioth: Feature Flipping Ruby Gem was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

I worked on that matter earlier with a tool called Boxen (made by Github team) which purpose is to automate software install on OS X with a lot of HomeBrew behind the scenes. I’ve struck with many problems within this approach:

• Boxen always broke on OS X updates
• It didn’t allow me to setup multiple environment per machine (which is not its goal anyway)
• It only works on OS X

Then came Vagrant!

My first reaction was:

Yeah I’ll finally won’t fear to test and crash my box

And right after that one:

Oh my god I hate those Virtual Machines!

Let’s see what makes Vagrant so useful for any developer (and devops!).

Back to basis

If you don’t know much about Vagrant I suggest you check their website and if you are too lazy let me resume it:

A command line utility to let you build and run virtual machine using VirtualBox (or VMware) in the background.

This means that you, as a developer, won’t have to use VirtualBox GUI at any time. You will run everything from your shell and the whole process will feel so natural that you will forget that you are running your code inside a VM (hopefully).

Building aka Provisioning

Your computer (the host) won’t run anymore your code, the Vagrant machine you are going to build will. In order to do so the first step is to actually build this machine, this is the provisioning.

Vagrant is able to use multiple providers: Chef, Chef-Solo, Puppet, Ansible and even Docker (full list here). It’s up to you to choose the one you like. The important thing is that this process force you to create a repeatable environment and this is a very good thing. You just need to pick the base box of your choice (full list) and start the provisioning!

The whole Vagrant setup is described in a file called Vagrantfile that you should add at the root of your application repository and version it. Now your developer won’t only share code, but also the whole configuration needed to run it.

Once your Vagrant is setup it only takes one command to build your machine:

$ vagrant up

Running it

Once your machine is setup, you are ready to use it. Think of this machine as a distant server, so how do we use it? SSH my dear friend:

$ vagrant ssh

$ cd /vagrant #where vagrant mirror your host repository

Vagrant takes care of everything for you:

• Mirror your code to the VM through NFS, so you can still use your host machine to code!
• Forward your host SSH keys to the VM so you can still connect to your servers inside the VM (useful for deployments!)
• Setup everything network related, public and private network, port forwarding etc.
• Manage the RAM and CPU dedicated to the VM
• etc..

Gotchas

At the beginning we experienced two kinds of problems, NFS share was slowing down our code and Network was pretty unstable. We solved those by switching to VMWare Fusion (which is a paid option) instead of VirtualBox.

Finally 3 months ago we switched back to VirtualBox, all those problems are now fixed and performance are at least as good as on VMWare.

Nowadays Vagrant seems to get more and more traction from the community and they add new features on a regular basis.

Key benefits

After 9 months of use with my team, here are the benefits I mesure:

• We now have a fast and easy initial setup for new developer
• Our environment is always in sync (homogeneous)
• We try more new things because we don’t fear to break our setup
• Our development is closer to production which reduce last minute bug
• Developers acquire DevOps knowledge

I hope this post gave you the desire to try it by yourself if it’s not already the case. If you have anything to add or to say feel free to use the comment section below.

Vagrant, developer’s best friend! was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

Do you sometimes feel that a small change could be a big game changer?
Some don’t see it or the difference that it can make, but trust me when you see them it’s very frustrating.

I would like to give you one example, for that I’m calling Google as a witness.

The Google «App Launcher» case

You all know Google and Google Apps aka “Google for Business”.

Few years ago they started the Google Apps Marketplace, a marketplace for third party applications and vendors. Back in 2010 this was a huge deal, almost like it always is with Marketplaces and Google!

I won’t talk more about the marketplace for now, but about a simple feature you all have with your Google account, the « App launcher » link you find on the top bar of all google services:

The idea of this launcher is great being able to access all your services with one click wherever you are! Back to our Marketplace for a second, one of the goal for 3rd party publisher is to develop apps that can let users use their google identity (Single Sign-On) and then be always one click away from the user. Google thought so too, so they made those Apps part of this « App launcher ».

Remember SaaS is a paid as you go model, being visible is crucial.

So everything is great… Except that when you add one of those marketplace App you don’t find it in the App Launcher because it’s hidden inside a « more » link at the bottom, genius UX!

So what could make a difference? Why not let users re-order those apps as they like, maybe they don’t care about « Google Sites » but more about the SaaS application they just bought? Hmm..

I don’t think it’s possible to argue with this, but it took almost 4 years for Google to do it. Since few weeks you can re-order those Apps as you like. (Only for personal Google account right now, but it will come next to Google Apps)

I’m sure with this small change Google will see a lot more people using the « App launcher » and it will also add value to the Google Apps Marketplace perceived by publishers.

A small step for the developer, a big step for the product

A small step for the developer, a big step for the product was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.

As many SaaS application we offer the option to customize the domain (and subdomain) of our application to our customers. This option has always been a pain to manage in our Rails application. Rails 3 introduced a new concept, Routes constraints which makes Routes more dynamic, but it’s not (always) enough for this specific problem.

The routes constraints

As mentioned earlier Rails 3 support the concept of constraints for its Routes. Based on the documentation I created a custom constraint as below:

Then I created a simple constraint class which respond to the matches? method by looking at the current host of the request and comparing it to the content of the @domains object. One thing to remember for later, this initialize only happen once, when the application starts.

So does this code work? Yes but when I add an item the Domain Model nothing happen, why?

Making dynamic constraints

As I said earlier the constraint class is initialized only once, at startup. So the @domains object never get update if we change the Domain Model.

The first solution I thought was to reload the class when I updated my Domain model. In fact, this means “Reload the Routes” which is something possible with the reload_routes! method.

We just have to add a callback to our subdomain Model:

And voila…

Remember how Ruby works? Let me refresh your memory, NO (true) multithreading, so chances are you run multiple concurrent process of your application to spread the load. Then, the reload_routes! method has to run against each process in order to update your Routes on all processes.

Since I didn’t want to jump too much in this process thing, I bypassed this restriction by implementing a simple trigger mechanism.

Triggering the constraint update

The solution is pretty simple, when we initialize the constraint class we create an MD5 hash against the @domains object and then store it. Since I already use Redis to store some data I decided to use it here (Redis is a nice store engine for speed and reliability), but you could store this hash wherever you want.

Then in my Model callback I “invalidate” this value, then when the next matches? method is called for each process, the @domains object regeneration is triggered.

The code below will make it easier to understand:

Now my Routes constraint is truly dynamic and I don’t have to reload the whole Routes neither do I have to take care of ruby processes.

The final version

Finally I added some security to my Routes constraints by restricting some domains and subdomains and added other stuff that you can read by yourself below:

If you liked this article please consider clicking the ❤️ below so more people could read it, thank you!

Managing dynamic domains with Rails was originally published in mythoughts.io on Medium, where people are continuing the conversation by highlighting and responding to this story.