Return to site

From Zero To One. How To Build A Product

Last year we embarked on a thrilling and frightening task: to deliver a stellar product to redefine what it means to do online media monitoring.

We knew somehow what we wanted to build we just didn't know how and where the journey would take us. This is, of course, true in many startups where you build a minimal product with a stable set of features as soon as possible and iterate and grow using feedback from your early clients. We wanted to build the next generation media monitoring software. So with this little crazy plan in our heads and not much guiding other than our pleasure for what we did we started a really hectic, focused, nerve-wrecking and incredibly incredible satisfying period of our lives.

Here are listed for your delight some of our architectural choices we had the pleasure of making. The decisions taken there took us where we are today.

#1. Pick The Right Front End Technologies

At first, the choices seem abundant. But let's add some constraints.
So it's got to be a webapp. Javascript! And be responsive. Bootstrap at least. Mobile apps? Coming soon but doable with this stack so far.
 

jQuery? Seems oldish and not seems enough for a larger dashboard app. Angular? Might do the trick but I'm a complete noob at it. React? Seems kinda new and not yet fully supported by the community. ExtJs? Ugh, I don’t like it.

But hey, what we know for sure is: no php, no aspx, no ‘grandpa’ technologies. We want to use only the newest stacks to get to our minimal viable product as soon as possible.

#2. Pick The Right Backend Technologies

No question about it. The backend options are too many for this article’s scope. Any language - framework combo you want to name we could write the backend in. Compiled language? Scripting? Our combined experience of over 20 years as devs only makes the decision harder since we have to choose between 6-7 languages and as many frameworks.

C++? It would take ages, but I would love the speed of the code. No dev speed, though. Java? Not a fan personally. C# maybe?

Again, some of the recent developments steered us towards node js. Could play nice with the frontend.

#3. Create A Work Setup

Professional code writing isn’t just an editor, a compiler / interpreter and a machine. It’s also test cases, tdd, bug tracking, at least, a shared todo list app. We all have our favourites in all of these domains. The choices here were easy and straight forward. For external software, we would use Asana and Evernote. Team communication? Slack, just because it’s newer to us.

No code should ever be written without sitting comfortably in a versioning system. We use Bitbucket for Oscilloskope.
 

In the editors section, it gets trickier: vim vim vim. At least, it sounded this way until the middle of the project when i switched to sublime with a remote ssh plugin. I highly recommend it. As a past visual studio user, I really prefer the simplicity and how light sublime feels even with all the features it packs.

#4. Choose The External Service Providers

Hosting. Amazon is flexible, some friends made a really compelling offer, but the winner here is DigitalOcean. Not only because it is cheap and friendly, but it also looks goooood. Highly recommended.

We send mail though SendGrid although MailChimp would suit our need just as fine.
 

To determine the categories of the websites we scan we use BrightCloud and to scan for malware to be sure we don’t include any infected websites in the lists we present to our users we use Fortinet.

#5. Putting It All Together

Oscilloskope - in numbers:

  • 30k lines of code
  • 10 bitbucket projects
  • Between 50 and 70 digital ocean machines
  • 12 months to MVP
  • 1 GB of daily bandwidth
  • 5 vps with heavy load at all times
  • Tens of thousands of URLs scanned daily

Wrapping up

Who can know where we would be if our choices were different? Maybe releasing a month earlier? Maybe with 6 months delay? We don’t know. The thing is we were happy and confident in our tools and at the day’s end this is exactly what they are: tools. You just have to use them with good judgment to the end of their ability. And yes, you must know how far a tool can get you.

It turned out to be a delicious journey: we learned a lot about us about our work patterns about what makes us tick while building a great piece of software. And this is what matters a lot more than the GitHub versus bitbucket debate - that we can talk to our happy customers and enable them to have great positive work experiences using our product. Building a media monitoring software is not easy and maybe is not for everybody. We were fortunate enough that this project was just like a glove for us and this is what we wish to you.

All Posts
×

Almost done…

We just sent you an email. Please click the link in the email to confirm your subscription!

OKSubscriptions powered by Strikingly