So this is it. Thousands of lines of code later, hours of pondering on the right logo / design, days spent chasing the last few naughty bugs, we’re finally there. This little idea we had a few months ago is now materialised, and ready to be shown to the public.

This moment where you and your co-founders are the only one browsing your baby-website before the gates open is always peculiar. We’re quite excited to open today, we hope you’ll like hbookmark, come and have fun with us!

hbookmark is not the first startup we’re launching, but it always comes as a surprise when you realise how much time and attention needs to be spent on the last few details and bugs of your product before launching.

Once again, we have experienced the theory according to which you spend 80% of your time on 20% of the code or features (the split could even be 90/10 in our case).

We’ve had an almost-ready-to-launch prototype for maybe a month now, along with a fully working api (we built it first as it’s the core of our product). However, the last few days have been exhausting, trying to nail down naughty bugs hidden in thousands of lines of codes, and it is always at this point that it is extremely important to keep ultra focused and motivated. Everyone here is eager to launch, but even if launching early and iterating quickly is key for a web startup’s success, it is also crucial to launch a near-perfect product (at least in terms of the initial features which have been agreed on).

After all, you only get one chance to have some decent coverage, and users only try a new product once, maybe twice. If you fail, then good luck to get this user back. That’s why hbookmark doesn’t need you to sign-up - you just need to have a twitter account - we tried from day one to come up with a product as unobtrusive and easy to adopt as possible.

I guess we’ll see in a few days if we got this part right, before then we need to iron out the last few kinks…

hbookmark is entirely built around our api, so we need to take extra care about scaling issues. There’s not that much literature around the web giving concrete examples of server architecture for real-time, asynchronous web apps like ours.

Note to self: write a blog post explaining how we chose our servers set-up, and dealt with scalability and redundancy issues once we’re happy with what we’ve come up with… and made sure it actually works!

sysctl vm.overcommit_memory=1

Server configuration is such a joy ;)