Maybe you’ve heard the news. We at Usersnap launched a little side project, called bugtrackers.io. Displaying stories of digital crafters and showing real people behind pixels, bytes and bug reports. That’s the vision for bugtrackers.io.

Starting with three interviews bugtrackers.io went live on April 16th. Following some great feedback on our social media channels as well as through direct feedback, bugtrackers.io experienced a great start. Within the first 4 hours after putting the platform live, more than 1.000 unique visitors stopped by and spent more than 5 minutes on the site (average session duration: 5:02 min.).

Although the launch just happened a couple of days ago, there are some fresh lessons learned we want to share, since they might help you for your next project. Here are 6 things we learned when launching bugtrackers.io.

[otw_is sidebar=otw-sidebar-1]

Inspiration through domain search

You probably know the following situation: you browse the web and discover some free domain which you think is pretty awesome. Because the domain may be valuable for you in the future, you buy the domain.

Well, this is what happened when we came across the free domain bugtrackers.io. To be honest, we hadn’t had a clue what we are going to do with this domain, but we knew that it may help us to position ourselves in the bug tracker scene.

We definitely knew that we don’t want to use the domain for any promotional or self-branding thing for Usersnap, but use it for some neat new content idea instead.

After a couple hours of brainstorming we found the idea of providing insights in people’s life in web development pretty interesting and something worth to follow. Inspired by other platforms like thegreatdiscontent and communicatebetter.io we pursued our idea.

From idea to design within 5 days

After this brainstorming session, I made myself comfortable with moqups.com to work on some first scribbles.

As you can see these mockups were pretty rudimentary, although we had a clear vision in mind. Our amazing web designer Pavel then drafted some first designs for bugtrackers.io which were then discussed within our InVision projects.

See full design draft version 1 here: design draft bugtrackers.io V1

[otw_is sidebar=otw-sidebar-2]

You do not necessarily need a CMS

After concluding on a final design draft, discussions on which technological basis our platform will be built arose. Since our blog already runs on WordPress, it stood to reason that bugtrackers.io will be build on WordPress too.

However there were some clear signs which let us decide against WordPress and any other content management system. In the end we choose to build bugtrackers.io only with HTML + CSS. Here’s why:

• We weren’t in need of any complex CMS, since we knew that we want to keep bugtrackers.io as simple as possible from a site architecture perspective. At the date of our launch, we only had four pages online. Here’s how the “site architecture” looked at the date of launch:
  • index.html
  • interview-blossom-thomas-schranz.html
  • interview-codeship-florian-motlik.html
  • interview-paymill-christian-braun.html
• We only provide “static” content (such as text, image, video (in the future)) which can be edited quite easily and way more flexible just by using HTML + CSS.

No project plan, but an agile project board

We didn’t use any concept or any other project document for creating bugtrackers.io. Not having a project plan or at least some kind of concept was kind of unusual for me in the beginning. On the other hand it made us quite flexible and fast in the execution of bugtrackers.io.

However, we established a project board with Blossom, a great tool which we started to use for our day-to-day tasks as well. You can see our project board in the screenshot below:

[otw_is sidebar=otw-sidebar-3]

Version control with GitHub & static hosting with divshot

After deciding that there’s no need for a CMS, our research for a static hoster began. Early on, we ended up at GitHub and divshot. We have used GitHub before to host & run some little side projects at Usersnap, but haven’t thought about it for greater tasks. divshot was something completely new.

After setting up GitHub with a new reprository for bugtrackers.io and connecting it with divshot, first tests looked absolutely great.

Not only for the development process itself, version control is great. Also for more design- and content-driven tasks, working with GitHub makes life a lot easier and the QA process faster.

Codeship & Usersnap for testing

When it comes to testing a new website or web app, everyone seems to be busy avoiding that topic. With Codeship and Usersnap we found the perfect tool chain for automated & manual testing. We decided to give the awesome tools of Codeship a try and integrated it in our workflow. Before our code gets hosted at divshot, it will be tested & deployed with Codeship.

Later on, we use Usersnap for manual testing, QA and simply discussing new ideas or collecting feedback on any content. Our development process basically looked like this:

Going live, basically meant, pushing our site from staging to production in divshot.

With this setup we experienced an incredible increase in speed regarding deployment, testing and QA. All our bugs, ideas where basically stored in Usersnap, whereas we ensured no mixup with version control of GitHub.

Summary

Since this workflow was kind of new for us and the way we work on new projects, we think that we’ve experienced a future way of web development by combining great tools like GitHub, Codeship, divshot & Usersnap.

To sum things up, I’ve collected all tools we somehow used during the development of bugtrackers.io in the table below:

This article was brought to you by Usersnap – a visual bug tracking and screenshot tool for every web project.