Wouter Smet

On web startups, technology, music and growth

Erasmus for young entrepreneurs: preparation

Here are some of my experiences entering as a participant in the Erasmus For Young Entrepreneurs (EYE) program, from the point of view of ‘young entrepreneur’. I’ll try to include some – hopefully useful – tips throughout, to be applied at your own risk.

If there’s one thing an unusual-ish university trajectory, an unforgettable Erasmus experience in Spain, being employed+unemployed+student+self-employed all at the same time (only in Belgium!), and living in banks-require-proof-of-everything London has thought me, it’s that all good things in life come with a pile of mind-numbing forms to fill.

EYE is no different (even though most of it happens online).

I am living the rewards now of course – of which both the blue sky below which I’m typing this and the great experiences in the web dev and entrepreneur/startup sphere I am now having here are proof – but yes it took some preparation. Luckily things were often eased by some great people I met on the way (more on that later). Reason enough to give you:

TIP 1: always look for people that can make your life easier, and TALK TO THEM. People are nice. (don’t forget to pay it forward by always trying to help others out of course).

What is Erasmus for Young Entrepreneurs (EYE)?

EYE is a program from the European Commission that aims to bring together young or aspiring entrepreneurs with more experienced ones across Europe, so that they may benefit/learn from each other: both in terms of ideas, new approaches in their relevant field, and of course (for some reason it makes me cringe a bit writing this), improve understanding of another language/culture.

While I’m sure there exists some centralized commission somewhere in Brussels that is dedicated to EYE (and its web site), the program is mainly organized around ‘intermediary organizations‘, IOs in short. IOs are local entrepreneur-related organizations that agreed to add ‘managing local EYE participants’ to their activities.

All concrete steps, from applying for the program, to receiving funds, writing/evaluating the course of your stay… happen trough an IO of choice in your own country, both on the ‘young entrepreneur’ (YE) and ‘host entrepreneur’ (HE) side. Once accepted in the program, and have chosen (and are accepted) by a Host Entrepreneur, it’s *their* IO that also manages things from the foreign side.

Step 1: applying for the program

Let me say right of the bat that the whole online site / platform / … where everything happens, leaves something to be desired. (I’m being polite here). In any case, the steps are to go

– middle name is ‘sounds good let’s do it’? Used to the fact that all good things in life come with a pile of boring paperwork? Erasmus for young entrepreneurs.
– be personal with your IO and that of your country of residence to keep things moving. If you have a company in mind not in the system: explain them! (as I did)
– web site ‘entrepreneur database’ is crap but I got a script to scrape it to local mysql db for better searching/navigating
– going to explore made lots of difference! Met CS hosts, future boss, impression of how vivid the place is, and how well I know the language to get around. Travelling all alone is nice early taste of living all alone…

[AUTHOR’s NOTE: I stopped writing here, but as I’m trying to clean and re-organize this blog a bit, and going through the drafts, I thought I’d publish this anyway as is. Step 1 should get you half way there anyway]

This post is part of the Erasmus In Lecce series about my experiences with the Erasmus For Young Entrepreneurs program in Lecce, Italy. I was there for about 6 months in 2014.  The posts in this series are:

  1. Erasmus for Young Entrepreneurs in Lecce, Italy
  2. Erasmus for Young Entrepreneurs: preparation
  3. An everyday day of living in Lecce
  4. When life gives you lemons…
  5. An everyday day of living in Lecce
  6. Living in Lecce – random thoughts and tidbits
  7. The difference between typical Northern and Southern European cities

The XKCD NOW world time zone converter

Screen Shot 2014-03-05 at 12.55.05

Last week XKCD made another great comic, about his 1335th, simply titled ‘NOW‘.

The comic shows the earth in a peculiar circular projection, where the South Pole is in the middle, and the continents are arranged/stretched so that equal radial locations correspond with equal time zones. Around the earth is a fix ‘ring’ with indicators of the hours, and some nice ‘zones’ like typical business hours and ‘rude to call’ hours.

The comic is dynamic: the image updates every 15 minutes, reflecting the current state of the world.

I made a simple web app called xkcdnow.com based on that comic that makes it easy to compare time zones at one glance. Read on for the details.

xkcdnow.com – a time zone converter based on the xkcd comic

I hate dealing with time zones so much, and I like how Randall presents it here, that as a little experiment I made a version of his arrangement where you can show the situation at a given hour of the day using a simple slider. You can try it here right away, but I’ll just state the ‘features’ that are there now. Note that it’s very much a prototype / proof-of-concept, so the code is messy and not at all cross-browser compatible etc etc…

The features:

  • On page load, the slider (and earth position) is automatically set to the current time in your local time zone.
  • You can add locations of interest by specifying a label, offset compared to GMT/UTC, and a color. So for example you could add ‘Paris’ and then ‘+1’, because Paris is in the GMT+1 time zone.These locations will show the precise time corresponding to your slider position, and also as ‘pie’ areas on the map, for quick location of the spots whose relative time you want to know. Handy for viewing the hours at your company’s different offices worldwide for example.
  • Your locations are saved accross sessions using a cookie, so they are still there when you come back later.

Here’s a screenshot of how it currently looks:

Screen Shot 2014-03-04 at 17.43.59


Curious what you think! If you like it, please share it so that we can all together break my cheap shared hosting plan.

7 Reasons You Are Never Too Old To Learn To Play Piano

I am 29 as of this writing, and have been taking lessons in piano for almost 2 years now. And, it’s been fantastic. It’s also been challenging, adds pressure in my life, made me realize limitations that I could comfortably hide during years of dabbling by myself on my keyboard, opened up entire worlds I barely knew the existence of.

Most people start learning piano at, say, seven. So, while I have been messing around on keyboards on and off since I was 15, I am still extremely late to be starting serious, classical piano lesson at my age.

wouter en simon piano pisa

But I stopped being jealous of those 7-year olds, and decided to finally start learning myself. And, even though my progress has been a lot slower than I had initially expected, it’s been a really great experience so far! Below are some reasons that I believe make learning to play the piano worthwhile whether your’re 7 or 77.

1. the fun is in the learning, not in reaching any actual resulting skill level

This is explained at length in the great book The Practicing Mind: as adults, we are often driven by goals, and every step taken to reach them comes with a degree of frustration because you are not quite there yet.

Sometimes this holds you back rather than help you advance: daunted by the difference between where you are now and where you hope to be, you feel so intimidated that you give up entirely.

In many situations both personal and professional, setting and reaching concrete goals is a good way to reach results. But when learning something in your personal time for fun and personal satisfaction, it pays off to just enjoy the process of learning as you do it. Get in the zone. Play.

With piano, you can stop caring about improving, but instead just enjoy what you are doing and know that, however slowly or quickly, as long as you are always working on new things, you are

2. You discover music that you never knew existed

Sure, you love the idea of playing Beethoven’s Moonlight Sonata, Mozart’s Turkish March, or even Adele’s Someone Like You. And it is great. (not that I can play anything besides Adele from that list – working on it though!)

But another, rather unexpected, joy that I have found in learning the piano is discovering great music.

Even without any formal musical education or preference for classical music, the melodies of piano songs like those mentioned above are known to most. But I never knew that guys like Grieg and Tsaikovsky wrote these wonderfully intimate things for piano well, that alter your mood as much while playing, as they do while listening them. Or an even better  examples: Russian composers Mussorgsky or Sviridov, both of whom I’d never heard of before having to learn a beautiful piece they wrote, like this one!

3. You get to peak in Bach’s mind

There is nothing quite like staring and trying for hours at a Bach piece, when suddenly it ‘hits’ you what the guy is doing, and how brilliantly there’s not just a beauty, but often also a pattern to his pieces.

It must have been since I learned Galois theory in second year of uni that I felt that excited.

4. It’s great for flexing brain muscles

Which is something that no doubt you do already often during your work or studies, but still. Can’t flex em enough!

5. It sounds beautiful early on and when played alone

Unlike by themselves wonderful instruments like the violin or trumpet, by the time you practice your 4th piece, you’re doing something that pleases the ear. This is a great motivator for yourself to keep on going, and increases your chances of your flatmates not kicking you out.

6. Every piece you learn is an accomplishment to be proud of

Because you are adding some beauty to the world, your friends who volunteered to listen, the room you’re in. That’s not something to take lightly. What’s more, YOU did it. YOU took the initiative, and so you got yourself to thank for every note you hit right.

7. It tends to impress the other gender

Oddly – and rather unfairly – enough, playing a piece on the piano seems to impress the ladies more than, say, explaining the elegance of group theory. Believe me, I’ve A/B tested.

On the other side of the coin, and I know it’s only one data point, but still: a girl that plays the piano instantly makes my heart beat a bit faster.


If you ever dreamt of taking lessons in piano, like I did for years before taking the plunge, I say go do it.

One last question: learning by yourself versus going to a music school versus taking a private teacher?

If you can afford it, I think your piano playing will be a lot more satisfying and likely to be a successful endeavor if you opt for a private teacher.

That’s because it gives you the freedom to steer the lessons according to your individual tastes. I tried to learn on my own for years, and I never had the character to go for the really hard bits. Like songs that use the black keys. But my teacher (who is wonderful) pushes me to also explore these, sit down and expand my comfort level, and generally giving both constructive and encouraging feedback. And to me that makes all the difference.

A case for the infinite free trial

This post is about free trials for software, specifically web apps. You know, ‘try 14 days for free’.  I want to argue that we may want to rethink that model, and more specifically: we may want to rethink when to end the free trial.

I’d like to argue for a new approach for this: do not expire the free trial until you detect that the user has formed a clear idea of your app’s value.


I’m sure there are flaws in my reasoning I am not thinking about, and in any case I’ve never seen this approach, at least not taking it as far (i.e. automating it) as I will describe here. Flexibility in trials when appropriate is already done – and rightly so – by companies that like a personal, value-centered approach during sales, but my thought experiment is about doing it by default, automatically.

First of all, why do we offer free trials? Because it’s Sales 101: put time a time constraint (whether real or imagined) on the other party, and they will be more likely to make the decision to buy your product.

Not every decision is a buying decision

Actually it’s a bit more specific than that: time pressure puts pressure on a decision, and if the relevant decision to make at the time is a buying decision, that’s the one the pressure will help make.

However, not at every stage of the ‘customer journey‘ a pricing decision is the one on the person’s mind. Before that, at the very least, there are:

  • The ‘what exactly is my need/problem’ decision.
  • The ‘what direction shall I search in to solve it’ decision.
  • The ‘does this specific solution hold a promise to fulfill my need’ decision.
  • And only then there is, maybe, a ‘buying decision’ regarding your specific solution.

You want to make the customer at ease at their own time for as long as you want, but when he is ‘hot’, i.e. saw the value of your product, a time constraint is the extra nudge that can help them make the decision and close the deal.

In the store, you first ask the customer if you can help them and what they are looking for, and only after they expressed an interest for your product, you nudge them over the edge with a ‘benefits if you decide now’ constraint.

So, the free trial time constraint serves a well-defined purpose, but in nearly all of the current apps it’s just a bit too… Crude.

Note that this may apply more to some people than to others: people who are busy, and sign up to new things all the time. Where I work we are a big fan of using tools to make our lives as easy as possible, so just to give you an idea where I’m coming from:  very much fit that profile, and chances are so do you.

A fictional conversation with a customer

Pop quiz: try to spot where the following exchange turns from quite common into never-happened-between-sane-people territory:

  • Sales rep: if you buy before the end of the month I’ll be able to give you a 20% discount!
  • You: great, with that discount I’ll take it. Bit busy now though, so I can only do the purchase the 3rd next month.
  • Sales rep: whoops, sorry sir, I said before the end of the month. Guess we lost you as a customer then. Say hi to our competitor wen you buy from them!

Yet this is exactly what we do when we send a ‘your trial is about to expire’ mail to somebody.

A concrete example: ToutApp

As a concrete example let’s look at ToutApp‘s ‘end of your free trial’ email, the one that triggered me into writing this post. Here it is:

Hey Wouter,

Just a heads up that your Tout trial is coming to an end soon. I wanted to reach out to make it easy for you to move to a paid plan.  

Go ahead and enter payment here: https://toutapp.com/billing/edit. We generally recommend that you pre-pay for the year so you can lock in your rates with Tout. That way you can just pre-pay upfront for the year instead of the recurring month payments. I can also apply a 15% discount with the yearly subscription. 

If you’d like to go for the year shoot me a quick email back. Thanks! 


Now, ToutApp is first of all a great product (seriously, check it out if you are a disaster at managing your sales emails like me), and this mail is also flawlessly executed by the ‘rules of the game’ in my opinion, including a friendly invitation to reply to a real person with any more questions.

But given that I had barely used their app when I received that e-mail, and they could easily detect this in their systems, I think it’s not ideal that the obvious objective they push for in the mail is having me switch to a paying plan.

Something like this would have been even better I think:

Hey Wouter,

Just a heads up: you created a free Tout trial 2 weeks ago, and it is coming to an end soon. We noticed you didn’t use the app a lot, so to give you a chance to keep evaluating our product, we extended your free trial for another 2 weeks.

Click here to log in and see for yourself how ToutApp can streamline your sales email process, or have a look at our tutorials to learn how to get the most value out of our app.

If you have any more questions, don’t hesitate to shoot me a quick email back. Thanks! 


P.S.: if you are already convinced of ToutApp’s value for your business, follow this link to convert to a paying plan. If you pre-pay upfront for the year instead of the recurring month payments we can give you a 15% discount. 

See? Rather than hurrying me into a buying decision, it pushes me into the next natural step they want me in: discovering the value of their product. Who wants a customer that doesn’t even know what they are buying anyway? That’s easy money perhaps, but not exactly great for the sustainability of your company.

And yes, as long as their systems indicate I did not do a ‘value showing action’ (could be login, could be something more specific, like in their case creating an email template and sending it), I propose to keep extending my trial and sending me the above mail indefinitely, until I either go log in and go do the value-demonstrating actions, or indicate explicitly to stop bugging me.

Of course, as soon as your systems indicate the user had a chance to experience the value of your product, that’s when switch to the ‘your trial is over, give us your money to keep the goodness going’ approach and message.

Infinite trial !== freemium

As a final note: the scenario I argue may seem a lot like the ‘freemium’ method at first sight, but that’s not quite it:

  • Freemium starts you off with a ‘limited’ version of your product, and then wants you to upgrade as soon as you want the more powerful ‘premium’ functionality.
  • Free trial (including the infinitely extended version) shows the full-on ‘premium’ value right from the start, and wants you to upgrade.

Both approaches have their natural place depending on how exactly your product provides value, but that’s another story.

(As a case in point, ToutApp actually has a free plan, and it’s pretty good, but it’s limited so I am now kinda stuck on using a stripped-down version of their (no doubt great) product to evaluate whether I want the Real Deal.)

So, in conclusion, here’s what I argued as a thought experiment: don’t expire a free trial until you know it has served its purpose: showing the value of your app.

I wonder if any companies already do the ‘infinite free trial until value shown’ approach? Do you know any?

If you liked this article, I’d love for you to Tweet or otherwise share it! Use those share buttons below to make me a happy nerd 🙂

Learning Italian in Lecce – in bocca al lupo!

… Crepi!

So far the only way I have discovered to say ‘good luck’ in Italian are the preceding 2 Italian phrases, translating roughly to ‘in the mouth of the wolf!’ to which the reply should be, nay has to be: ‘crepi!’, implying something about the wolf dying after you jumped into his mouth. I could be wrong, since I suspect there’s conjuntivo being used.

Of course, if you where to – the madness – something like ‘buona fortuna! Grazie!’ brings bad luck, Naturally.


That is to say, the Italian language is many things, but ‘compact’ or ‘efficient’ is definitely not one of them. Beautiful? Colorful? Rich and expressive? All those it is in spades though!

I spoke a fair bit of Italian before I arrived here – though it’s been a while, and, frankly, it’s quite mentally exhausting (but in that good way!) to speak it all the time here. If you have experience speaking with a native speaker in a language you are still into getting, the following dialogue should be familiar to you:

[Some fairly safe and anonymous everyday situation, in which at some point you mumble…]

Me: ‘Hi’ or ‘Thank you’ or ‘My Name Is Wouter’ or ‘one from that (while pointing) please.’

Native speaker: ‘Oh wow, you speak Italian really well!’ (loud and enthousiast, also where did that spotlight suddenly come from)

Me: ‘Naaah, not really… But hey, thanks I guess!’

Native speaker: [friendly follow-up babble in Italian that is totally incomprehensible to you]

Me: sheepish smile / blank stare

[Author’s note: this post is actually an unfinished draft, but since I’m back now, it’s unlikely I’ll ever finish it so I’ll just post it as it is]

This post is part of the Erasmus In Lecce series about my experiences with the Erasmus For Young Entrepreneurs program in Lecce, Italy. I was there for about 6 months in 2014.  The posts in this series are:

  1. Erasmus for Young Entrepreneurs in Lecce, Italy
  2. Erasmus for Young Entrepreneurs: preparation
  3. An everyday day of living in Lecce
  4. When life gives you lemons…
  5. An everyday day of living in Lecce
  6. Living in Lecce – random thoughts and tidbits
  7. The difference between typical Northern and Southern European cities

Why the most important part of your app has the messiest code

If you’ve worked at, or talked to, some developers at various software companies, there is one theme that often returns: developers blush when thinking about the central part of their app code, and would like nothing more than to finally clean up that mess, once and for all.

And it’s not something ‘non-core’ they wish they could refactor. No, it’s the central part of the codebase. The checkout code in an e-commerce platform. The friend invite mechanism for a social network. The formula engine in a commercial Excel plug-in (to name just three I’ve seen up close). When asked to make a change in that code, chances are the reaction looks something like this:


Why is this such a common theme?

The reason is, I think, threefold.

1.The most important code is for the oldest functionality

Actually, I’d say even more: it’s the code of your minimal viable product. The code you wrote as a proof-of-content to see all excitedly how it works! The code that you deem worthy of building nothing less than a business around.

The code that you built after-hours during your day job, while also learning the framework you use for turning it into a web site.

You can see where I’m going. It’s the code you wrote before you learned many lessons about you specific project, and sometimes even about the framework and/or technology it is written in.

2. The most important code is the most affected by customer feedback and product improvements

Sure, you should be tweaking your signup flow. But usually, that one is just a series of steps and forms, and you’ve done it a thousand times. Customers, whose feedback you care deeply about, don’t care about your signup flow, because they already took it and forgot about it.

The code that is central to your app? That’s the one they have a thing or two to say about. So you add a small exception to please that one early ‘poster customer’. And another exception because you didn’t need team collaboration and e-mail notifications in V1, but realised the added value of those in V2. And another exception that makes it work in French.

And you’re a lean startup, so you iterate fast.  And break things. But then you fix it again. But refactor that code that so many of your current clients rely on, rather than just adding functionality to it? That’s not business-critical, so you just vent and sigh, and postpone it.

3. The most important code is the hardest to fully grok for new developers on your team

If it were easy, you wouldn’t have built a business around it. So it’s the code that you poured all your vision and oversight as a founder in. The class structure is elegant, the performance well-tweaked. You know exactly where any improvement to the code fits best because you have the whole picture in your mind.

But then you hire John The Junior Developer. And after a ramp-up period and some small bugfixes and fringe features, you deem him ready to Touch The Core Code.

But John doesn’t know your vision. John just wants to fix a problem or implement an enhancement. And that’s why John reads through the relevant part of your core code.

And so he uses an IF statement rather than a subclass, because god knows what all that scary stuff in the base class is about, and it doesn’t seem to have much to do with team collaboration or e-mail notifications anyway.


The most important part of your code is also the messiest. It’s also the most valuable.

The core code of your app is like a veteran battle-hardened warrior, scars included.


So, when for the umpteenth time a new developer joins your team, and when you walk him through your code, he backs away in disgust, or burst out in hysteric laughing, loudly wondering how you ever made it to a point where you have a hiring budget using that shitfest of a code base, don’t despair. Keep your head held high and point them to this article.

Also, the good news is, as I’ve said at the start: while this phenomenon is quite common, and I’ve certainly been guilty of it for personal projects, it doesn’t always have to be like this. The smarter tech companies I’ve seen schedule precious senior developer time regularly to dive in the core code, and make sure it stays performant and in pristine condition. Consider adding this one to your ‘things to ask during the job interview’ list.

Last but not least, I’d like to point you to Joel Spolsky’s ancient but still valuable (hah, how appropriate!) article of the strategic danger of a full app rewrite. Don’t go that far.

This blog is still quite new, so if you liked this post, I would love for you to Tweet it and help spread the word!

Engagor – growth hacking a B2B app using smart tools and metrics

I gave a short talk at the Growth Hacking Antwerp and Growth Hacking Ghent meetups on January 18th and 24th respectively. This here is the content of that talk in slightly extended form. It’s actually my preparation for the talk, so sorry that it’s all text and no pictures.

(If you are interested in what the whole ‘growth hacking’ thing is all about, highly recommended you join those meetup.com groups, or if you speak Dutch, read Omar Mohout’s great explanation of growth hacking)

There are many aspects to growth hacking, but I’m only addressing one very specific aspect of ‘using technology for growth’: different tools we used and still use, the role they played in growing as a B2B startup, and the ‘hacking’ aspect of using the APIs all of them offer (good times!) to boost their value.

One way to justify this topic is that almost all of these tools (especially from the first slide) match what is often mentioned in the context of growth hacking: high value for growth at a very low price, with programming playing a central part in boosting that value.

[slideshare id=29949729&doc=engagorgrowthhackingpresentation-140113025833-phpapp01]

About Engagor

Engagor is an online platform to help agencies and (medium to large) companies and organisations of all kinds manage their social media efforts by combining analytics, monitoring and engagement tool in one neat package.

The platform is built by the company of the same name, which was founded in February 2011 by CEO Folke Lemaitre, and is headquartered in Ghent, Belgium.

The model is Software-As-A-Service (SaaS): customers buy a license allowing them access to a personal secure Engagor account for x number of users during y months (typically one or more years), with some other differences in pricing plan related to features and how much you can monitor. See the pricing page at engagor.com for specifics.

As of this moment, we have about 30 employees, and roughly about 300 customers around the world. In August 2013 Engagor also received 2.5M in funding, and opened a second office in San Francisco. Being just under 3 years old, this means that Engagor has managed to grow fast compared to many other SaaS companies.

Founder/CEO Folke fits very, very much the description of ‘growth hacker’, so quite naturally the use of technology and data to help create and understand growth is ingrained in our company culture.I myself only started  recently as ‘growth hacker’ at Engagor, so the credit for originally finding,  implementing and then hacking the various tools I mention here goes entirely to him.

About me

I studied math and physics as Ghent University, but after (and actually, during) university it was startups all the way: SEO-optimized web site that brought in private teaching gigs during the last years of uni, then risk analysis consultant at Vose Software, web developer at Massive Media (Netlog / Twoo), co-founder of MyShoppingTab, then Engagor. (my linkedIn profile, if you’re curious)

I started at Engagor in October 2011 doing Customer Support / Relations (a non-technical role, but it sure makes you know the product and its users),  then October 2013 my role became officially ‘growth hacker’. Yes, that’s on my contract, how cool is that!

At the beginning: communicate with your audience

First and foremost a disclaimer: while these tools and the hacks we did on them absolutely made growing easier, they by themselves did not make Engagor succeed: ‘classic’ things like great product-market fit, early exposure, and a great network all played a much more vital part. But they are not the theme of the talk.

Most important thing for B2B app is communicating with users, visitors, potential users, EVERYBODY. So none of these tools got us millions of visitors.

What they did get us is people coming to us interested in our product, and turning them into paying, extremely happy (and thus recurring) customers at a nice pace. We aim to optimise for sustainable revenue as much as we optimise for web site traffic.


  • Value: chat widget we integrated in on our site (and app!) to help, and learn  from, visitors. Useful for feedback, generating leads, improving product!
  • Hacks we did: include not just name and location, but also current account plan in nickname, to know whether it’s a trial or current user (different approach for each!). Integrate tightly with both our helpdesk and CRM.


  • Value: helpdesk / ticketing system. Keep incoming inquiries organized!
  • Hacks we did: link closely to the internal issue tracking system of GitHub (a platform we use to help organize our development process), easily create issues from a ticket + reopen ticket when GitHub issue has changed.


  • Easy online presentation + screen sharing with a fully featured free version!
  • Hacks we did: none, it’s just easy to start a session for both parties, and works perfectly fine in the free version.


  • Analytics at the user level! Great for more detailed understanding than Google Analytics, seeing realtime which pages a person asking support had looked at…
  • Hacks: integrated traffic numbers in own backend dashboard to combine visit numbers with others (trial signups, mails  sent…)

Many more: Curdbee for easy sending of quote+invoice, MailChimp for newsletters, Google Apps for gmail/calendar/shared docs, DropBox…

And let’s not forget the obvious: we have access to one enterprise-level tool for social media entirely for free! The perks of using your own product.

Now : sustainable growth, traffic, metrics and team

As Engagor grew in team size an reach, two main points play a bigger role: a smooth running team (and the occasional human errors, workflow tools that come with them) and maintaining data quality, not always obvious if you move fast as a company (URLs change, new product features…)

Top of the funnel

Search, display and retargeting ads with AdWords, AdRoll and others:

  • Predictable, steady targeted traffic to feed the ‘top of the funnel’.
  • The price of a click can seem high, but it can make business sense if you know the returns on those clicks!
  • Hacks: landing pages! Different wording in each of the ads, constant tweaking in targeting…
  • Story: sales rep says ‘I love Swiss leads, they tend to have resources for a tool like ours, readily accept meetings’. Quick check in SalesForce if the data matches his intuition, then dial up our Swiss targeting! That kind of stuff you cannot do with a blog post.

Ad Backends:

  • Almost all offer conversion tracking!

Google Analytics:

  • Powerful for segmenting and answering questions, but anonimised.
  • No more keyword reports since 2013, but connecting with AdWords does give you some insights on search behavior.
  • Tends to under-report numbers, so don’t rely only on it.
  • Hacks: custom variables for metrics by account plan, heavy use of filters for ‘canonical urls’ (removing the user-specific IDs when they are in the URL)…

Middle of the funnel: leverage content, guide leads through ‘buyer journey’

From here on, we’re starting to leave the realm of low-priced tools and enter tools with a bit of steeper pricing, so not really fit for a beginning startup budget. One great advantage more expensive tools (like ours :)) tend to have is brilliant support though, both on usage and strategy level.


  • Value: like Clicky, but better for our needs: individual customers, powerful ‘identifying’ tools, great segment reports, easy to include revenue numbers in reports
  • Hacks we did: we track on account- rather than user level, since the person initially ‘discovering’ our tool is not always the end user, decision maker…


  • Value: inbound marketing! These guys don’t just sell a tool, they sell a philosophy – great tool to help make the most out of your contact, set up lead nurturing campaigns…
  • Hacks we did: tight connection to our CRM which is a benefit for both directions


  • Value: empowering your sales e-mails, which can easily become a mess, using templates across the company, connected to CRM
  • Hacks we did: none so far. Close eye on ‘template performance’ though.

Bottom of the funnel: sales


  • Value: super complex and steep pricing, but boy is it a complete package, and almost every tool I named includes an integration with them. Great reporting tools as well to get reports ‘closest to revenue’.
  • Hacks we did: pushing as much as possible from the earlier funnel info in there to tie ‘early’ properties to actual revenue

Bonus tool: hipchat

HipChat is a chat client, like skype without the voice/video calling. If you don’t use an internal chat for your team, stop being silly and start a chat room. If you do but think WHAT??? ANOTHER CHAT TOOL, AND IT’S NOT EVEN FREE???? bear with me.

  • Value: the power of HipChat lies in its integrations: you can super-easily push automatic notifications to chat rooms from your own code, and developer tools like Jenkins and GitHub have integrations with it, to notify everybody of deploys and new bug tickets etc… Also not bad that they mail you if you get @mentioned while absent, so you don’t miss anything important.
  • Hacks we did: we use it to show a nice ‘vitory GIF’ whenever something great happens like a new customer won, or also to alert the Sales chat room that somebody asked for a demo on the chat, etc..


Almost none of the tools listed are free, but they can pay off hugely, saving you time and hassle so you can focus on what really matters: building a great product, having a great and smoothly functioning team, and most of all: delighting and understanding your users!

My password strategy: gibberish string + app string + mini-algorithm

Because not a week seems to go by without a major service being hacked these days, it’s more important than ever to drop that ‘same password for all services’ approach if you are still using it. Make it your 2014 resolution!

I used to use the same password for different services I considered in a certain ‘importance level’ (roughly banks > emails > social networks > tools I plan to only try once), but some tools turned out to change ‘importance level’, while others didn’t fit neatly into one category… So while this felt already quite secure to me, it was not ideal.

I also hate using a desktop app or USB key or something like that to generate and manage your passwords because it defeats the good part about cloud apps being accessible from any computer. I want to remember my passwords myself, especially since I always say no to browsers offering to remember it for me.

There are as many ‘password strategies’ as there are people it seems. So, here’s mine.

Let’s start with a laugh, with the now infamous comic by XKCD on the topic:

I am often annoyed by people taking this approach seriously online, because while entropy + easy to remember is nice, it overlooks the fact that a good password is short (I mean as in 10 characters, not 4 characters, but not 30 either). That is because it is hard to correct / remember where you were in your password when it looks like *************************************** in the input box. All the more for mobile.

Properties of a good password

So, in my humble opinion, a good password should be:

  1. Between 8 and about 15 characters. Less and some sites will complain that it’s too short, longer and it suffers from the same problem I mentioned above.
  2. Easy to remember, so you don’t have to waste time when logging in to a service.
  3. dictionary attack‘ secure: not just an English word or concatenation of words and your birthdate or whatever, because those can be cracked using a dictionary or ‘rainbow table’ attack, for sites that don’t salt their passwords.
  4. ‘reuse’ secure: if somebody knows your password for one site (either because they hacked something, or you gave it to them, see below), they shouldn’t be able to use it on other sites.

So here’s how I do it. It satisfies the above criteria, and you don’t have to be a genius to remember it.

Some ‘special cases’ before we get to the jackpot

First, some ‘special cases’ you may consider, before I divulge my super-duper password strategy that I think everybody and their mom should adopt.

1. Trivial passwords for things you are likely to share

You do require a login to your computer, right? In any case, this is a password very likely to be shared with people (close to you) at some point. They want to change the music at your dinner party while you are cooking in the kitchen, your flatmate needs to look up something that’s on your computer while you are in another country…

So this should be separate from any other password, and can be a simple word with a number after it or something, so you can easily say it over the phone.

Another one for this is your home wifi network. Make this easy to remember and share. For me it’s just a very close variation of the network name, and this has worked well so far.

2. Something similar could apply to some services used at your job, depends what kind of work you’re in.

3. A separate password for banks and e-mail? Because this is really the most important thing of all, I have a totally separate password for my gmail and banks, which are long, impossible to guess, and cannot be deduced from the below strategy.

But I think these exceptions are just because I’m paranoid. If you simply include the above cases in the below strategy rather than memorizing a ‘special case’ for them you’re probably still way better off than whatever you’re doing now.

The killer approach: gibberish string + app-specific string + mix-up algorithm

So, here we have it. My ideal password is a mix between something that depends on, and is easily – but not trivially – deduced from, the app name, plus a string of random ‘typical’ password gibberish. This satisfies all of the good password criteria I listed above, and assures I score ‘very strong’ on about every ‘security level’ meter they put next to passwords. Feels good man.

Screen Shot 2014-01-13 at 14.31.56

So, for example: the gibberish string is Bxx12ab!3. Containing an uppercase, number and symbolic character and being over 8 characters, that one satisfies virtually every ‘safe enough’ check on sites, both in length and ‘complexity’.

The second part is the ‘algorithm’ that depends on the app it is for, so that it is unique for the app, to prevent it from being reused should your app be hacked, or should you exceptionally have to give the password to somebody else.

Here, for example, you can use ‘reverse the first 2 characters of the app and attach them at the end’. So your password for github becomes Bxx12ab!3Ig, your password for Facebook becomes Bxx12ab!3Af, etcetera. If somebody gets a hold of more than 1 passwords of you they might spot the pattern, but from just seeing one it’s hard to guess. And that makes it infinitely better than just reusing the same password.

The one thing that isn’t covered yet is the annoying and retarded habit some tools have to force you to change your password every X months, while requiring that it’s different enough from the previous one. This typically leads to people writing the password on a post-it note, defeating the purpose. But for this, you can have a strategy like ‘increase the a by one in the alphabet, and the 3 by one’. So if GitHub were to require a change you could change it into Bxx12bb!4Ig.


So, that’s my password strategy. After Apple pissed me off with the requirements for their Apple ID password and I resolved to fix this mess once and for all, it took me about 30 minutes to go fix this in all the apps that I could think of, and then another month of doing this whenever I logged into an app I hadn’t fixed yet.

So, in summary, I have to remember:

  • One gibberish ‘strong password’ string.
  • One ‘algorithm’ to transform the app name.
  • Some easy passwords that are likely to be shared with others.
  • Some additional passwords and/or gibberish strings for e-mail/projects I am collaborating on/…

It’s reasonably doable to remember this (especially since you’ll be typing your gibberish string over and over again), it never gets complaints from an app that it’s not secure enough (au contraire!) and it feels more secure than any other ‘password habit’ I have tried or seen so far.

To get the same level of satisfaction and improvement in life quality as throwing out all your socks and buying 20 identical pairs of black ones, implement this now and make 2014 the year you once and for all stopped worrying about passwords.

What do you think – I am not at all a security specialist so if you are, please let me know: did I miss something here?

Startup on a shoestring: building a poor man’s CRM yourself

One of the questions that web startup founders often face early on when starting a web company without a big – or any – budget is: which tools to build, and which tools to buy? As a developer, in principle, you can build at least a basic web-based version of just about any business tool in-house: it’s tempting, but the question is one of time and priority.

For example, while you can implement your own web site analytics, it makes more business sense to leave this bit to Google Analytics, which is free and powerful. For good measure, you may want to pump every page view in a table yourself, especially at the start, to be absolutely certain that you have correct figures. But don’t build that fancy dashboard for that data just yet, and focus on your product instead. (I know you want charts, I love them too, but PhpMyAdmin can chart query results too!)

Same goes for mass mailing (MailChimp has a free plan) for your news letter, having an online chat on your site (e.g. ClickDesk has a free plan). Then there’s a couple of other tasks that, in a first stage, a spreadsheet can help you just fine: creating invoices, keeping track of your revenue and expenses…

When your startup is aimed at businesses though, I have found that there is one part of your toolset that it may make sense to throw together yourself: a Customer Relationship Management tool, or CRM in short. This is basically a database that you use to organize all your activities and conversations with potential customers, so you don’t forget about anybody, and can have a clear view at all time what next to do, and how well you are doing.

The reasons hacking your own CRM together may be a good idea

The reasons I believe CRM is one of those business tools you may want to whip up yourself is:

  • It’s indispensable to maintain your sanity while talking with different early customers (once you have a first version of your product online, you are talking to potential customers and not just focusing on your site, right?).
  • Existing tools tend to be either very expensive, a bit too bloated, or both.
  • How you want to structure and manipulate the data is kinda hard to fit into the ‘spreadsheet’ mold.
  • A basic version that you whip up in an afternoon has huge value.
  • A CRM gains enormous value from being ‘close’ to your app-specific data (your users and accounts). Syncing your data with an external CRM can take up almost as much of your time (studying documentation…) as building an entire basic CRM yourself where you already intimately know the code, so why bother.

Ingredients of a minimum viable CRM

The most basic CRM, but one that already has enormous value, only requires very few tables and fields. Also, but this is probably something very few people would agree with: it’s ok if it is ugly. Here’s a snap shot of some entries in the home-brewen CRM of MyShoppingTab:

Screen Shot 2013-12-31 at 15.36.18

First there are 2 ‘settings’ pieces of data that you could put in a table if you wish, but they change so rarely you could also hard code them without much hassle, saving you 3 pieces of CRUD work:

  1. Sales reps. People who do the selling and who leads are ‘assigned’ to. This is probably just you and/or your co-founder at the early stage of your startup. And anyway, you can just use the users of your app with admin rights.
  2. Possible activities done on a lead. This is typically an ENUM field. I like to use: ‘reached out’,’conversation’,’demo’,’created account’,’sent quote’,’sent invoice’.
  3. Lifecycle stages. These allow you to prioritize on leads, and get a clear view on how well you are doing. I tend to use: ‘unknown’,’test’,’cold’,’warm’,’closed won’,’closed lost’.
  4. Possible lead sources. Another ENUM field: ‘found myself online’,’newsletter signup’,’trial signup’,’referral’…

Ok, that’s the ‘setup’, now for the actual living,breathing data:

  1. Leads. This is the central table: all people you want to talk to, or are talking to, come here. In its most ‘bare’ version, it contains these fields:
    – creation date
    – sales rep ‘owning’ the lead
    – lead stage (see above)
    – name of the company
    – name of your contact at the company
    – e-mail of your contact
    – phone of your contact
    – lead source (see above)
    – an extra freeform text field to add additional details like the type of company, who initially referred you to the lead, its web site etc etc… Don’t try to structure these things too much: what you have for each lead tends to vary.
  2. Activities. This is where you log what has happened, and what should happen, on each lead. A minimal structure for this table would be:
    – ID of the lead it is connected to
    – type of activity (see above)
    – creation date
    – todo/done date
    – whether the activity is a TODO or DONE
  3. Deals. For the ‘closed won’ leads, i.e. customers. This is typically something you can infer from your main app database, but it’s handy to explicitely have it in your CRM, to be able to do at least a very crude revenue analysis, and to have an extra checks and balances if there are no errors between your business and your account plans.
    – ID of the lead it is connected to.
    – if it is a subscription, when it starts and expires.
    – deal value.

… And that’s about it! You’ll typically want to add some extra fields depending on the specifics of your business, links to immediately view the account of the lead, etc… But it shouldn’t be much more.

The user interface

To be honest, if your web app is built in Php and MySQL,  PhpMyAdmin does not make for too bad a CRM interface! You can bookmark queries, add,insert, update and search leads easily, etc. And again, you can easily create charts right within recent versions of PhpMyAdmin – I’ve found myself doing this more and more lately.

However, where’s the fun in that? Since your web app no doubt already has a private admin backend, and a standard design for ‘list of items that the user can create, read, update and delete (CRUD)’, might as well reuse that.

Wrapping it up

Ok, that’s about the gist of it. I was tempted to put some sample code here as well, but the fact is that you want this to work closely with your existing code and database conventions, since one of the benefits of building it yourself is that you don’t have to dive into developer documentation for an external tool. So I won’t.

Some final things to bear in mind if you take this route is: best not to get too attached to this. An internal app can be a fun ‘break’ from working on your main product, but if it’s costing you more than, say, one or two days, you’re taking too much precious coding time away from your main app code.

What’s more, if your startup takes off and starts to get significant amounts of revenue, leads, and a full-blown sales team, investing in a ‘real’ commercial CRM like SalesForce is definitely worth it, if only for the easy customization and reporting these tend to have. So be prepared to abandon your internal nifty CRM somewhere along the way.

So, conclusion: I think in the very early stages of a start-up, especially when your budget is extremely tight, a CRM is one of the tools that is worth whipping up yourself rather than spending money and time on an external tool.

My Google Reader replacement: Facebook

I just realized today that I spend less and less time reading the RSS feeds I’m subscribed to (though I started using Feedly right after Google Announced shutting down Reader), but I spend more and more just reading what the same blogs and news site read… Right within my Facebook news feed:

Facebook as news reader

It took some careful and consistent ‘hide all from this friend’ actions, to weed out all those distant and abroad contacts that I love to be able to get in touch with, but where I am less interested in their daily lives. But, it’s finally paying off.  My Facebook newsfeed is now a mix of different news sources, mixed with the occasional share / opinion of a friend I really want to hear from.

And I like it. Facebook wants to be more of a news source than a ‘meme share’ itself it seems, and I couldn’t agree more.

So, if you are looking for a nice Google Reader replacement: try Facebook.