Ducksboard: from nothing to private beta in four months

It’s done. Ducksboard has entered private beta. The four months from drawing the first lines on a piece of paper to flipping DNS entries at 6AM have been a fun ride. Go see the homepage and play around with the demo or read on about some of our experiences.

Ducksboard is a real-time dashboard for tracking your internal metrics and webservices. A single place where you can gather data from all SaaS apps you use (GoogleAnalytics, Mailchimp, Sendgrid, Zendesk…), as well as pushing us any internal metric you might consider through our REST API.

A walk through the architecture

(a very brief one)

Most of the original design sketched at the beginning has survived, which might be a concidence or the effect of choosing simple interfaces and deciding to go with technologies we already knew. All of our backend is Python and we make heavy use of Twisted. Persistent storage is provided by PostgreSQL and realtime updates are pushed to RabbitMQ and delivered to clients through WebSockets. We have almost 17,000 lines of Python code, 10,000 of which are tests. Our unit tests coverage oscillates around 98% and in a few days we hope we’ll be pushing it back to 100%.

A common concern throughout the whole project was security. We care about security and we’re serious about it. We try to cover all our bases and we’re considering hiring outside penetration testers to make sure our customer’s data is safe. We use SSL between the backend and the database, between the backend and the queue and for the entire frontend. We check for certificate validity. We use bcrypt to store customer’s passwords, use symmetric encryption to scramble customer’s API tokens and encrypt our database backups.

Another point worth mentioning is Open Source. We’re using lots of open source, which today never surprises anyone. However, stopping to think about it, the amount of raw functionality and saved time we get from projects like jQuery, txamqp, txWebSocket, countless Python packages from PyPI, not to mention the database software, queue software, the editors we use (yes, one of us uses One Editor, the other one uses The Other Editor) and finally the operating system our servers and desktops run is *amazing*. Open Source is a phenomenon that never ceases to amaze me. We have identified parts of our code that are generic enough to be reusable by other people and we will soon publish them with a liberal license and we are deeply thankful to all the people whose code powers Ducksboard in its everyday tasks.

The architecture really deserves a longer post (and a more serious one than the last one) which we’ll try to put together in a few weeks.

Good decisions

Start gathering emails from interested people from day one

The rate of new signups served as a constant validation, reassuring us that there is demand for what we were making. We asked the people from that email list for some early feedback that helped us take product decitions at early stages. The last poll we did has been filled by +700 people.

Create an interactive teaser page

Software development is like playing frisbee, you should never say anything else than “hey, look!”. Our first appearance on the Internet has been a realtime Twitter timeline, deployed using our own software. It gave us a first glimpse at how well do we scale and forced us to document the deployment process. The timeline was tracking mentions of our Twitter account, which encouraged users to tweet something about us to see the message appearing. That gave a nice viral touch to the teaser.

Hire a top-notch UX dexigner

We’re a startup and we’re bootstrapping. Every dollar (actually, every euro) spent means one day less before we run out of juice. It was a difficult decision but we knew that you sell a dashboard throught the eyes. It turned out to be by far the best investment we did (maybe after NBA2K11 for the Xbox ). We are completely in love with the design of our dashboard and we are hearing similar opinions for people all over.

Not so good decisions

(also known as bad decisions)

Optimistic estimation for the front-end

We thought this wasn’t gonna happen to us… But it happened. It’s really hard to make good estimations when you are using fringe technologies (WebSockets, anyone?) and you have to test it in several browsers and devices. We’re server people, Javascript is not our strongest point and our application  is definitely Javascript heavy. We already decided our first hire will be a front-end engineer. If you are interested, please contact us.

Delaying front-end development until we have finished the backend

Writing network servers is so much fun you forget you need to deliver something a browser can render and execute. We thought it was as easy as turning the HTML into templates and connecting the frontend through our internal API… but as the frontend took shape it made us realise we needed several changes to our original design and the damn HTML never rendered as it should. We ended up with a backend we’re very happy with and a frontend that could definitely use some cleanup.

Hopfully you found some of that useful. Expect to hear from us soon!