Note: this is a technical post.
After launching Monica on Hacker News, I received a lot of questions about why
I chose to write the tool with PHP and Laravel in particular.
I was actually surprised to receive so many questions about this topic because
I consider that a language does not matter - only counts what you do with it.
In this post I'll share why I chose PHP and Laravel and the difficulties I had
to overcome to build the first version of the product. This post is not meant
to start a war between languages.
PHP has an interesting history. A lot of great web developers, who probably do
not use PHP anymore, have learned the basics of programing with it. It was so
simple to use and get started with, and while it wasn't an elegant language, it
paved the way for making a career in web development. Then over time, PHP
became less loved, to the point where it was almost shameful to use PHP or even
say in meetups that your company was using it. Other languages, arguably more
elegant, gain a lot of popularity (Python, Ruby) thanks to wonderful frameworks
built upon them. At the same time, new PHP frameworks appeared. Symfony for
instance. But Symfony was still hard to learn and use. And then PHP died. Or so
that's what people said, ignoring apparently the fact that a lot of
business was still using it and loving it. Then PHP 5.5 was created, followed
by PHP 7, and a new framework with a weird name appeared, Laravel. And things
changed entirely in people's mindset. PHP is still not as elegant as other
popular languages, but things got a lot better. It became also fast.
But regardless of this, PHP is still the language people love to hate,
especially on Hacker News. They say PHP is not scalable. This is probably why
Facebook and Mailchimp, amongst other big names, use PHP today, at great
Why this context in mind - why did I chose PHP and Laravel?
- PHP is simple to learn, and simple to use.
- There are a lot of PHP developers out there, and if people want to work with
me on the project, there is a potential larger pool of PHP developers, at least
from where I live, than Ruby or Python developers. Also, there are a lot of
people on GitHub using PHP, and if I wanted this open source project to gain
any traction, I had to write it in a language where people with different
coding level skills could contribute easily.
- The most important thing to consider when choosing a technology stack for a
new project, is how easy it'll be to maintain it on the long run. PHP is
simple. It's easy to debug (although it could be better) and easy to scale
(although it's not my concern right now at all).
- Laravel is by far the best PHP framework I've ever used. It makes it so easy
to do complex things. It's clear that the framework has been created to start
new web applications really quickly, and it's truly a pleasure to use. But
Laravel's killer feature is the quality of the documentation, compared to other
PHP frameworks or even a lot of frameworks in other languages. Everything is
extremely well documented. I can't emphasize how important a good documentation
is (this reminds me that I should document Monica even more).
- There is a huge community around PHP and Laravel in particular: Laracasts,
Forge, Envoyer, a strong Slack community to name a few. If you need help, there
is a lot of people out there ready to give a hand.
What are the challenges I faced during the development of this project?
Overall I didn't have that many challenges while developing the current version
of Monica. It's not a complex application, and I don't have scaling challenges
as the user base is quite small still (around 7800 users total and 4300
active). But there are some implementation details that I did wrong - not
because it was bad coding practice, but because my technical skills were not
good enough to overcome those problems on the short term. Hopefully, listing
those mistakes will help others not make them - or nice people will send me
emails on how I could have fixed them.
- In an earlier versions, I used a lot of events and listeners. While the
concept is awesome, I had a lot of problems with unit testing the base classes
because to them. Moreover, the more I was using them, the more magic happened
behind the hood. I thought that people who would jump in the codebase would
struggle to understand how come some stuff happened when an object was created
for instance. In my mind events and listeners would make the application harder
to understand, so I decided to remove them all (well, 99% of them, there is
still two listeners that I need to get rid off).
- At the beginning, the database was entirely encrypted. For reasons I still
haven't understood, from time to time there were bugs with the decryption
process, leading to data I couldn't recover. Because I didn't want to deal with
this problem at this stage, I decided to remove the encryption. Moreover,
having data encrypted made it impossible to operate any kind of sorting or
search in my queries, which could have been problematic on the long run. I'm
sure there are solutions to these two problems but I wanted to focus on
creating new features instead of fixing this single one problem.
- I didn't write unit tests before launching the application. This really hurt
me bad. I don't think we should aim for 100% test coverage, but at least, have
some kind of tests for the main features of your site. Otherwise you end up
with a s**t ton of bugs that you didn't think about, and while you try to fix
it, other parts of the application are affected by your fix. This becomes
quickly a nightmare. Laravel makes unit testing super easy - I should have
taken this more seriously. Starting with the next version of Laravel, no pull
request will be merged unless there are unit tests and perhaps even functional
These are some reasons why I chose Laravel. As I said at the beginning of this
post, your project is not about the language. Unless your project is about
learning a new language, you should not spend weeks choosing a language or
framework. Stick with what you know, and just make something. Your users won't
care that your code is ugly or that you chose Python over Ruby.
Only 5 days since v0.2.0 and yet another big release. So big that it required a
new version for this.
When you have a lot of contacts in your account, you can now categorize your
contacts with tag. Tags are like folders, but you can have multiple tags for
one contact. This allows maximum flexibility to manage contacts the way you
want it to do.
Tags can be entered right below the contact name.
Once contacts have tags, you can see them on the contact list, and click on
them to filter the list.
Finally, you can delete tags either on the contact view, or in a new Settings
panel created for this purpose.
Version 0.3.0 is already in production, and as always, you can install it on a
server that you own.
One of the biggest feature request is the ability to import contacts from
Google. Google allows to export data about your contacts in the vCard format,
which is the universal standard for exchanging contact information. Monica
0.2.0 adds the ability to import your data from a vCard file (either .vcard or
.vcf), so you can populate your account with most of your data instead of
having to add your friends one by one.
Right after your contacts are imported, you are redirected to a dashboard where
you can see the status of the import. Because users might have thousands of
contacts, Monica imports them asynchronously. You'll have to wait a bit before
all the contacts are imported.
You can click on a specific import to see what happened.
Also, we've added a feature to reset your account, which will be handy if you
do import thousands of contacts and something goes wrong. Resetting an account
deletes everything, except you.
Version 0.2.0 is already in production, and as always, you can install it on a
server that you own.
A lot of people have sent me emails about why Monica is open source. There are
a lot of reasons for this that I want to describe at length here. Open sourcing
a consumer product and at the same time trying to make money out of it is not
something that is that common (unfortunately) and perhaps this will inspire
others to do the same. I've been personally inspired by how Sentry, GitLab and many others have created
companies around open source products and even if Monica doesn't generate any
revenues yet, I wanted to share my own thoughts on the topic.
The pros of open sourcing your product
- I've always wanted to create an open source product. Probably by idealism.
I've been using open source products for as long as I can remember and I wanted
to humbly contribute to the open source ecosystem in return. I also thought it
was cool on the CV.
- Monica contains a lot of personal data. I would argue that this data is way
more potentially harmful than what people put on Facebook. For some it's a huge
privacy concern. By making Monica open source, and providing ways to install it
yourself on something that you own and control, it's up to you to decide
whether you want to take the risk of letting someone else host your data, or if
you want to keep it under your control.
- Because of the sensitive nature of data hosted by Monica, and because I'm a
single developer who is not as good as the community as a whole, I needed to
open source the product to make sure hundred of eyes scrutinize the code and
look for bugs, potential breaches and improvements. And find things that should
be fixed or enhanced much quicker than what I could do myself.
- When people have access to your source code, and become users of the
platform, you will be astonished by how much they will contribute. They will
submit pull requests with great ideas and concepts, that you can immediately
put in the product for everyone to profit from it. It's awesome. Of course, all
ideas are not great and you will refuse pull requests from time to time, for
various reasons. But globally it's extremely positive and you will receive
great new features.
- In an age where social networks are extremely opaque in what they collect and
how they use the data, people are more and more concerned about their privacy.
For a very good reason. Monica doesn't display ads and does not resell any
data. But why take my word for it? For one reason: the freely available source
code is exactly what is in production. I
don't maintain a second fork with private modifications. Therefore, everything
I do is transparent and users can control that I don't do anything nasty. It's
all about transparency and creating a relationship based on trust.
- Developers are the most important part of an ecosystem. When developers like
what you do, they will create an ecosystem around it and cool things that you
would have never thought about. This is a very strong magical moment when that
happens. Developers are also powerful influencers and your best ambassadors.
Non geeks people reach out to them often to ask for the latest tech advice. And
if they like Monica, they will talk about it with almost the same reach as a
post from a Kardashian would in a gossip magazine.
The cons of open sourcing your product
- Regardless of your license, there is a risk that people take your code and
spin off a company around it, and take the market you wanted to address. There
is nothing you can do about it. A popular maxim says that an idea is worth
nothing, only the execution matters. In Monica's case, it's more than an idea -
the code is already there and it's already an execution. The more mature the
product will be, the more it'll be tempting for other people to steal the code.
I'm ready to live with it, as long as the community benefits from the results
- If you get big, you might become less attractive to either venture
capitalists or potential buyers. But you know what? In my case it is good news
because I'm not building something for them, I'm building something for users.
I don't care about what VCs will think about the product.
- It is time consuming to deal with the community. Don't get me wrong. I love
interacting with them, and I feel extremely blessed that there is a passionate
community around Monica already. But while I'm trying to build what's next for
the product, I spend a lot of time every day checking issues, verifying pull
requests and answering emails. Like, a significant part of my time actually.
Again, I'm not saying it's bad. Actually I'm enjoying it greatly. But this time
sink is something to consider if you decide to open source your product and you
need to be willing to participate and take care of your community.
I can't think of any other drawbacks. You should consider open sourcing your
The two most requested features on Monica so far are:
- the ability to import contacts from an external source,
- automating as much as possible the recording of things about your
I totally understand why people want it. Monica is all about recording and
documenting social interactions with the people you care about. Having to enter
all the contact names one by one is considered by many to be a painful task.
Moreover, having to record everything manually after a phone conversation for
instance, is even more painful.
However, think about this. Monica is designed to help you have better
relationships. Building relationships is not something that we should automate
and make it easier. Building relationships is a conscious effort. It is not
easy. It does require a bit of work. If you had the ability to import 500
contacts, what it would do to you? You would have now 500 people in Monica,
ready to be documented. Will you really take the effort of entering all the
information for those 500 persons? Can you even be friends with that many
I like the idea of having to enter my contact one by one, because it forces
me to think of who is more important to me. For every person that I add to
Monica, I conscientiously choose if this person somehow deserves (the word is
definitely too strong but you get the idea) that I take the effort of
documenting our relationship. Then for every person I add, I have to fill all
those information for which I have to actively look for. I would go as far as
saying that having a mass import, without the ability of pick and choose, would
even ruin the main purpose of the application.
But this is how I personally see the product. How I see it, is perhaps not how
you see it. Hence the need for an importer. We'll built it, definitely. But
before importing your contacts, think about this. Do you need to keep
information about that many people?
Monica is meant to host all the private information about your contacts. By
nature, this is personal, and private. However, there are some cases where you
would want to share these information to someone else - your spouse for
instance. It's easy how Monica, in a context of a couple, can help the couple as
a single entity to organize the relationships they have with their loved ones.
To address this use case, we are introducing the support for multiple users in a
Adding users happens via email. As a security measure, the person you invite by
email will have to enter the email of the user who has invited her upon
You'll find user management when you click on the Settings tab in your
This feature is the first paid feature. The paid plan is called Chandler and
costs USD $10 per month. This plan is only available on
https://monicahq.com and does not affect self hosted
installations. If you host Monica on your own server, you have access to paid
features for free.
Take a look at the pull request
to know more about this.