Wouter Smet

On web startups, technology, music and growth

Unigift – slimme cadeaubon oplossingen voor steden, verenigingen en KMO’s

Unigift BVBA is de naam die we kozen voor ons nieuw ‘overkoepelend’ bedrijf om online cadeaubon activiteiten zoals TadaBon, stadsbonnen als Cadeaubon Gent

De Unigift website bevat een beetje informatie over de verschillende zaken die we doen. Have a look!

Legco: Juridisch Advies

Voor Juridisch Advies is er nu een nieuwe betrouwbare partij genaamd Legcote vinden op Legco.be.

Cedric Claes staat u bij voor al uw juridische vragen, met expertise in verschillende domeinen. Contacteer Legco voor meer details.

Bijles in Kortrijk, Harelbeke en Waregem met Integrip Coaching

Wie nood heeft aan bijles voor wiskunde, fysica of talen kan steeds terecht bij Integrip Coaching, een populair bijleskantoor dat vooral actief is in en rond Kortrijk. Uit persoonlijke ervaring weet ik dat zij erg weten waarmee ze bezig zijn!

Integrip specialiseert niet enkel in ‘pure’ bijles, maar gaat ook prat op sterke ondersteuning van de student, met aandacht voor zaken als studiemethode, goed plannen, tips bij het voorbereiden van ingangsexamens (zoals het ingangsexamen geneeskunde) en meer.

Soms is er niet meer nodig dan een extra stimulans tot concentratie – dan kan begeleid studeren effectief zijn.

Klik hier voor meer informatie over het aanbod van Integrip Coaching.

Why Business Networking at Events Sucks for People like Me and How I’ve Been Fixing It

So here’s the thing: I consider myself pretty decent at ‘business networking’. The reasons for that are that I am not too intimidated when striking up a conversation with a total stranger, but even more – I like to think – that I try to listen attentively, and am genuinely interested in what people do and have to say. Every encounter is an opportunity to learn after all. Dale Carnegie would be proud.

Meeting new (and great) people at an event - the part that I can do - inbound2015

The part that’s fun: connecting with new, great people at an event

So, generally I have always liked attending or speaking at various business or networking events. And while I am not much of a ‘smooth talking sales guy’ or even ‘business person’ overall, often enough I do end up with valuable conversations where we end up discovering next steps that can bring both of us clear value – an agreement to try a demo and see if there’s a fit, a promise to dedicate a blog post to each other’s product, etc.

So we’ll end up with a heartfelt hand shake, a quick exchange of business cards or a linkedIn request, and a genuine ‘looking forward, talk soon’ for after the event.

The problem is what comes next.

Because, you see, beyond first encounters, I am not the most ‘socially organised’ person, to put it mildly. I barely tolerate entering data in a CRM, have a virtually non-existent memory for names, and typically end up with is a big pile of crumpled business cards of which some are  connected to a really great conversation that I need to follow up on, and the majority is because exchanging them was a politeness. But which was which, again?

... My typical aftermath of a business event.

… Less fun: my typical aftermath of a business event.


And besides, I’m tired and my head is still spinning from the event – by the time I can bring myself to the ‘follow-up’ part, the nice personal details of the conversation are long forgotten, and the CRM looks like a drag – I got a full inbox waiting thank you very much.

The ‘e-mail on the spot’ fix

So here is my fix that I have tried with success on various events I attended.

For those great conversations in which there is clearly value to pursue more conversation, I fire off a quick email on the spot. So either I straight up refuse their business card, pull out the Gmail app and say ‘never mind that, just give me your email’, or I accept the business card and before continuing to the next ‘mingle’ I make sure to take the email address from it and fire off that e-mail.

This is Hubspot's CEO Brian Halligan granting us early access to a product they just unveiled at Inbound14 conference.

This is Hubspot’s CEO Brian Halligan, shortly after his keynote, granting our company early access to a product they just unveiled at Inbound14 conference.

I have found this to work pretty neatly for me, not just for the reasons above, but also because:

  • By the time y’all get back home, the conversation and next steps have already started. So no nagging doubts about the exact pleasantries you talked about that make the message more personal, no forgetting.
  • It does not depend on the circumstances: sometimes we brought business cards, sometimes the other person is also used to linkedIn or whatever, but I always have my phone on me, and people always read a (personal, relevant) email.

Dreaming of even less pain: ByeTalkSoon

Still, the system has its drawbacks: I always have to type the full message (even if it’s often just a subject saying ‘Great to meet you at [event], let’s talk [topic of continued value] soon!’ even if most parts of it – but not all, I’m not a robot! – are repeated.

So, on to a solution, or rather a concept of a solution: together with a friend of mine we’re created a little app for that to make this process even more seamless. We christened it ByeTalkSoon, and it’s very much ‘minimal viable product’ (only works with gmail for example), but still, I like it a lot!

So, event networking app ByeTalkSoon.com is officially online now, and I’m very curious to see if this a ‘problem’ worth solving or if I’m the only one that has it!


TeamView – organize your company without spreadsheet or emails

TeamView is a new cloud app that aims to be the ‘productivity app to end all – well, most – productivity apps’. The idea was born from seeing again and again and again how a company faces the ‘ok, we should organize this better’ question on parts of their process, and they are then faced with these options:

  • Investigate, and if something fitting is found, invest – both time and money – in a ‘specialized’ app.
  • Throw something together with a shared spreadsheet, document, or similar.

Something’s missing here. So many things need organising right from the start, while very few of those should require a choice between a mess and an investment.

As a developer, there is always a third option, because you see crystal-clear what the solution to the ‘we should organize this’ question is:

  • it’s just a relational database.

But to stand a chance at being adopted, a relational database needs a better interface than PhpMyAdmin, which – I speak from experience – has way too many scary ‘drop’ buttons that should almost never be touched.

Enter TeamView,  which is ‘just a relational database’, except it has a user interface worth the name, doesn’t require a degree in relational queries to set up, and is instantly accessible as soon as it’s set up. Throwing an ‘app’ together to manage your meeting rooms or who is using which company computer should be easy.

I have a lot more to say on the subject, and TeamView is very much still in the ‘idea phase’, with me frantically building a bit towards ‘MVC’ when I have an hour to spare here and there.

But this post is mainly just to prove a point about brand name uniqueness and google. Go to TeamView.

The FLUID model – what do we choose to work on?

This is just a sketch of a draft of an idea, and it may turn out only to apply to myself, not others or something.

Many books have been – and will be – written about productivity, and similarly so about happiness. These are some thoughts I had the other day, reflecting on the things I do and the order I do them in for my little mini startup TadaBon. How do we prioritize the tasks in a specific project, or throughout our daily life, in order to be productive, get things done, and hopefully not go to crazy or depressed in the process?

No idea.

BUT, I think there’s an interesting little framework to think in when talking about happiness and productivity, called the ‘FLUID’ model, an acronym for Fun, Length, Urgency, Importance and Difficulty. It aims to be simple enough to easily explain our behaviour and motivations when working on projects, but also complex enough to explain a wide range of things.

And like most theories, the first goal of them is to be consistent, then to explain existing stuff, and lastly to help formulate answers to problems. So I guess goal #1 is this: given that you may interpret ‘fun’ to be extremely broad (like, the entire upper half of Maslow’s famous pyramid), can every single task or aspect of a startup or general project fit in this framework?

Obviously this is meant to be tongue-in-cheek, not as a serious ‘model’. I just happen to like models (in at least two senses of the word, come to think of it :)). This post is also just about ‘introducing’ and exploring the concept, since writing helps me  organise my thoughts.

Or maybe it’s just an excuse to see how far I can get with making 5D charts.

From the solutions I’ve tried, HighCharts’ 3D scatter plot so far seems the quickest and handiest way to do this, producing something like this:


JSFiddle where you can change things and rotate the chart

(the colors should actually just range from red over yellow to green, indicating the difficulty dimension, but I didn’t get that to work yet while maintaining the ‘3d-ish’ look with the shadows.)

Getting Things Done: Importance and Length

Both the famous ‘Getting Things Done’ method and our own instincts suggest to prioritize tasks by the following 2 dimensions: importance and length (time the task will take). Do the important and quick stuff first, then the important stuff that takes longer, then the rest.

(disclaimer: I didn’t read the book, just read – about – it, and I know I am grossly oversimplifying, so I may be totally off here, sorry for insulting any GTD fans)

… And that’s how we all prioritize our inbox, right? Unfortunately, life gets more complicated than that.

How We Choose What To Do: Fun, Importance and Urgency

I SHOULD be doing the important and urgent stuff (say, finding more users or replying to their support inquiries), but instead I am here writing a blog post that contains scatter plots and does not remotely contribute to my project. Not sure where my point is, except that like so many things, it scores low on everything but the F part.

I also just realized that ‘difficulty’ is definitely related to fun, so maybe I should leave it out. But then I don’t have my nice acronym. Also, I like (some) things that are difficult, like trying to create a 5D chart.

Ok whatever, just publishing this now just to make sure I don’t forget about it (which I tend to do with ‘draft’ posts), but obviously this is just a draft of half a thought.

Some more vague thoughts surrounding this thing and how it might relate to startups:

  • The same task evolves as your skills and experience evolve, which would make for a nice ‘pulsating’ and color-changing sphere traveling around the Fun-Importance-Urgency axis.
  • Also, throughout a startup’s life cycle tasks shift around on this spectrum, and jump over to different people/teams as well. Development of a first version of the product typically hits the jackpot among every single FLUID dimension as the founder builds the first version of the product, but then becomes less urgent and often less difficult, whereas growth becomes more urgent and prominent.
  • As a founder, you want to hire to move tasks away from yourself that start to become less important, but never fire yourself from all the fun ones, or, well, you won’t have any fun (motivation).
  • Could you take it one step further and say, the founder/CEO should aim for as long as possible to work only on tasks that hit the FLUID ‘jackpot’, and make hiring decisions to fulfill those tasks that do not?
  • An interesting personal goal throughout a day or week could be to try and make sure you do at least one of each? Whether combined in a single task or not.  A satisfying and productive day has you do at least something fun, something important, something urgent, something difficult and work on something lengthy (i.e. ongoing), whereas a day that is only filled with fun seems unproductive, and so does one doing only urgent-but-easy stuff.

To close this post I’ll just leave this fragment from Scrubs which is highly helpful in promoting my conceptual model:

I should get back to doing real work.

Growing web startup Tadabon part 2 – building a minimum viable product

Tadabon is a platform that enables small/medium merchants to offer printable gift vouchers onlineIt’s a spare time project intended as a learning experience, and I’m trying to document it as I go (with some delay though), however good/bad it turns out. Timeline of this post: nov-dec 2013. Previous part.

Allright, so I got a plan: build an online gift voucher site. Time to build it! Luckily I have lots of very relevant code lying around from my previous project, so I decide to make the most of that. Since this is about growing a site as much as it is about simply creating it, The goal is to get a ‘minimum viable product’ out there as fast as possible, and iterate from there based on what I learn from talking to my target audience.

Building the minimum  viable product

Design: bootstrap-based template

I generally suck pretty terribly at design (both conceiving it and writing decent CSS), so I take a heavy short cut and buy this nice bootstrap-based template which has an admin backend, a corporate frontend and an e-commerce site for 10 bucks. It includes even a blog layout! Exactly what I need for my project, perfect.

Screen Shot 2014-04-30 at 21.48.33

Plenty of great cheap or free ‘admin’ or ‘e-commerce’ or ‘corporate’ site templates (Tadabon required all three)

Code: home-grown PHP MVC framework

For the code framework, I completely reuse the small MVC one I self-built and created and evolved over the years, including for MyShoppingTab and Barlisto. Its template engine is (a by now heavily modified version of) QuickSkin, and the framework by now  has all the usual stuff with straightforward URL routing, database wrappers, controller class inheritance so that rights and stuff like that is easily shared, easy methods for storing and retrieving from a cache, utility methods for manipulating arrays, generating random strings, doing cURL requests, a complete debug log of queries and actions to view on each page what is going on, etc etc.

I’m sure it’s messier and hairier than many ‘prefab’ MVC networks, but I know my way around it really, really well. Another time saver.

App: reusable stuff from previous projects

Apart from the PHP code framework, other ‘app-level’ aspects already ready and easy to port were:

  • User signup, login, and forgotten password reset.
  • User rights, making the difference between users, admins, and any other ‘roles’ a user may have, and the accessibility with certain secitons that go with it.
  • Sending automated emails: signup confirm, password reset, notifications, to myself when an error or otherwise important event happens…
  • An admin backend to manage users, shops, and any other ‘objects’ relevant to the app.
  • Code for easy ‘scaffolding’ all the template+controller+model php code to do ‘CRUD‘ operations on any type object.
  • A minimal CRM to keep track on leads, which stadia they are in, which actions where performed on them, and who of the admin users ‘owns’ them.
  • A system of ‘shops’ with variable products, prices, names.
  • Logic for validating and storing images.
  • Code to make it easier to work with various libraries and APIs: payment gateways like PayPal, connecting with Facebook, generating PDF files on the fly…
  • … I’m surely forgetting a lot.

… All in all, that’s a lot of stuff if you add it up! None of this is overly hard or complex, but if you’d have to write it from scratch I imagine it adds up.

Many of these things are necessary, and others are a definite plus for even a moderately complex web app, and typically come out of the box many PHP frameworks (things like Zend or CodeIgniter or RubyOnRails), but again, the great advantage is that I know my way around them so well so customizing for my first version gift voucher platform can go relatively fast.

Screen Shot 2014-04-30 at 21.46.15

It’s convenient to have something like this out of the box

Defining the product: what not to include

What has to be in there is pretty straightforward: something that allows a merchant to sell vouchers online, and to dynamically add and manage the elements needed for such a page. Actually, as seen above, that by itself already has quite a lot of elements just to function and be secure and usable.

A lot of fun and piece of mind is to scratch out what is not gonna be included, even though MyShoppingTab already has it, and it’s pretty natural to think how it would add value and growth potential. In this phase ‘NO, NOT ESSENTIAL’ is a great way for peace of mind, and the answer to 90% of feature ideas:

  • No multiple languages. This project will focus exclusively on Flanders and all text will just be in Dutch. Bye complexity.
  • No fancy visual customization options. Each merchant page will look visually very much the same, as will each gift voucher. Bye complexity.
  • No way of paying me online. If for some reason I want your money in this early stage I’ll just make an invoice in Excel or whatever and email it over, and go extend your trial date in the database. Bye complexity.
  • No way of offering anything beyond a coupon for a certain amount of money.
  • No different ‘pricing plans’ based on features.  Less complexity.
  • Generally no built-in growth/viral mechanisms like easily inviting others, sharing on Facebook/Twitter …
  • No charts in the admin backend that show how many signups or whatever I’m getting. PhpMyAdmin will do the trick.
  • No big money/time investments in site performance, like paying for a CDN or a web host or server where I can install Memcached, or even build scripts that minify my static files. Less complexity. (code performance would be silly not to do as well as possible from the start though)
  • No Facebook login or integrations to put your store in Facebook or anything like that.

Now, just to be clear, by the time I’m writing this  pretty much all of these features are in TadaBon (and others on their way), but none of them were necessary for the first version to provide its core value: a way to sell a printable gift voucher online. If I cannot get that part to work and convince somebody it’s useful, who cares about Facebook login.

Online marketing groundwork

Writing the first version working off this base actually happened in parallel with gathering initial user feedback (as a nice change from just coding). Things like coming up with a project name and doing the other ‘online marketing groundwork’ like building a project site and setting up the right online marketing tools, but I think that’s worthy of a blog post of its own.

The same theme as above will continue for the presentation/marketing though: the most important part is getting something out there that works, so if it’s ugly and poorly written, I can live with that. As with the app functionality, the goal is not to impress, the goal is to launch.

After all, real artists ship.

Presentation on A/B testing at Growth Hacking Belgium Meetup in Ghent

I gave a brief presentation at the Growth Hacking Belgium (if you’re interested in the whole ‘growth hacking’ thingie at all, join them!) Meetup in Ghent on the topic of ‘A/B testing’. These are the slides:

The sources of the examples used are as follows:

Growing web startup Tadabon part 1 – Idea and conception

Tadabon is a platform that enables small/medium merchants to offer printable gift vouchers onlineIt’s a spare time project intended as a learning experience, and I’m trying to document it as I go (with some delay though), however it turns out to go.

Screen Shot 2014-03-25 at 14.20.47

Timing of events in this post: Summer-fall 2013.

TadaBon as a web project was born more out of these 4 things, all happening during or after the summer of 2013:

  • Receiving a printed amazon gift card that my wonderful colleagues bought me together before leaving for a long stay abroad, and loving it.
  • Considering (and partially implementing) the possibility to offer gift vouchers as a feature of startup MyShoppingTab with my cofounder Stijn, who also gets the credit for initial enthusiasm about the gift voucher angle and believing in its potential as a separate site.
  • Getting a new day job with a big emphasis on growing a project through online means. I love improving in my day job by doing the same kind of work on personal projects in my spare time, and trying to grow an online project from scratch through online means (more on that below) like this is just right for that.
  • MyShoppingTab, while it got a number of users, was fading out and not growing at the pace we’d hoped for, due to a number of weaknesses, so feeling like a ‘pivot’ is in order. What’s more, building something fresh is always good for motivation, and online gift vouchers solve many of the drawbacks of MyShoppingTab. More on that below.

Gift Vouchers as a pivot from hosted web shops

MyShoppingTab was/is a platform that allows small merchants to create a web shop that functions entirely (including payment, which is quite unique) in a tab of their Facebook page, with no technical knowledge required, and lots of customization/personalisation options, both in the design and the wording.

It grew to be a rather advanced and full-featured app and I’m quite proud of that, but strategically it also had several drawbacks. The biggest ones are the following, and online printable gift vouchers fixes some of them in a straightforward matter:

  • Promotion / traffic generation / converting is almost entirely up to the shop owner. Small merchants are often not up to that, and only those who really ‘live and breed’ facebook with a thriving community of fans managed to get good sales out of it.

    Tadabon fix: positioning it as a central platform, allows me to help driving traffic to the site in general, thus not leaving it entirely in the vendor’s hands.Tadabon fix: still center around ‘shops’ for merchants, but also market it ourselves as a portal.

  • Shop setup and maintenance, while simple, still required a lot of work because the entire inventory of products needed to be defined, described, and have a picture uploaded.

    Tadabon fix: no inventory of physical products needs to be there, and it doesn’t have to be kept up-to-date with products in stock. What’s more, no physical shipping is needed, another hassle removed.

  • There is still no real evidence that people like shopping within Facebook. What was long the biggest player in this field, Payvment, got bought and subsequently pulled the plug on Facebook shopping. Users still seem to associate shopping mostly with the web.

    Tadabon fix: it will be a separate web site, with Facebook perhaps used as a possible sharing / growing platform but not the main focus.

  • I wouldn’t use MyShoppingTab myself often, but I would (and by now, do) happily use Tadabon myself!

Some more strategic/product decisions made early on:

  • Unlike MyShoppingTab, TadaBon is not multi-language, just dutch. Greatly reduces technical complexity of the app, and what’s more I am ok with focussing on a small, well-defined market rather than ‘the world’.
  • The revenue model will be the same as MyShoppingTab: fixed fee for us, sales directly to the merchant, with a generous free trial to evaluate. Another great reduction of complexity (I just facilitate a direct transfer), and I like that ‘merchants have matters in their own hands’, and that I get paid regardless of how well they sell.Charging commission or not is an ongoing point of doubt though, many merchants seem to prefer a commission model however long I give them a free trial, because they are reluctant to pay for something without certainty it will be of value. So, this one isn’t carved in stone, but we got plenty of time to rethink, rethink and then rethink again here.The exact pricing also changes almost by the week in my head, even after the informal research done on this (see a next post). As gift vouchers make for so small a component of any merchant’s business (at least in their perception), here’s a big chance that this project never stands a chance of being financially self-sustaining unless it has hundreds of merchants, or unless I do give in and ask commission, or… Oh well, that’s why it’s a hobby.

Ok that’s about it for what lead up to Tadabon. Next edition will be about building the actual product and gathering initial feedback to get a sense of, well, the sense of it all.

In A Perfect World, This Is How Web Sites Would Handle Login Forms

Ok, so you own a web site with users. Here’s what you typically do with your login form, where you ask e-mail (or perhaps nickname) and password.

You do some kind of query in your database if there is a user with that email + password combo, and if you found something, you log that user in. So something like:

SELECT * FROM users WHERE email=:email AND passwordhash=:passwordhash

So far so good, and bonus points for you if indeed you do not store passwords in plaintext and even more if you use a salt with that hash. Most companies get at least the no-plaintext part right these days I think. Good.

BUT, what if that query returns nothing? Here is what 99% of web sites do, including big ones like Twitter:

Screen Shot 2014-03-20 at 13.19.00

What GOOD sites do when no user/pass combination is found in the database, is a second query, to determine whether it was just the password that was incorrect, or perhaps the email does not exist in the database. As so often, Facebook gets this right because they are pretty good with the whole UI thingie:

Screen Shot 2014-03-20 at 13.21.42

This does not impose that much of an extra load on your server because the extra work is only done when somebody gives a wrong email/pass combo, so this would not double your queries on your user database or anything.

That’s all, thank you for listening. I’d love it if you share this post if you have been annoyed by this as well, or comment on it if you think I’m completely wrong in having this as one of my (many) pet peeves.

P.S.: I know there are arguments that can be made against revealing that a certain email address corresponds to a user. For example, perhaps it potentially gives people with malicious intents a (cumbersome) way to tell that an email address exists or that a given person is on a site.

And perhaps Facebook can get away with this because everybody and there their mother is on it, but perhaps you feel your Defense NASA Banking site cannot. Still, I don’t think most sites thought this far, and just go with the lazy route because everybody else does it so they get away with it. And at the very least, you have measures to prevent automated non-humans from submitting your login form I’m sure.

UPDATE: many people pointed out to me that the afterthought I so casually put inside a post scriptum is quite an important one. Maybe, to not give any information to hackers, here is an approach that is a bit more secure. Store the user’s email address in a cookie (even if you don’t have a ‘remember me’ cookie login, in which case all of this is obsolete of course), and if the email address he tried to log in with matches that cookie, then show him that the address exists but the password is wrong.