We scrapped everything. Here’s why, and what we’re doing now.

by Colm Cahalane
CTO, NativeNote.com

Version Zero: What Went Wrong

The first version of NativeNote.com was based on the idea that we could develop a minimal viable product, give it to a very small user base, test it and develop it. It’s a reasonable strategy, but working to build just anything and get out the door with a prototype version led to us making some bad design decisions.

We decided to code our product from the ground up in pure procedural PHP, having tried various frameworks and thought that we “didn’t need them”. This led to myself, Evan and Mervyn spending long nights implementing our own authentication systems, Facebook account system, CSRF handling, routing, etc. We learned a lot about what makes good applications work, and how to implement these systems, but we certainly made this difficult. Maintainance was near-impossible to balance with speed of development.

And although we had abandoned the idea that we were going to build NativeNote with a framework, our attitudes began to change as well. Evan built the NativeNote Surveys system in the Python framework Django, and used Laravel to build FoundersMarket.

The weekend that Evan dedicated to building FoundersMarket was a difficult one, simply because he just would not shut up.

Can I have a moment of your time to talk about our lord and saviour Laravel?

His devotion to his new way of development was almost cult-like.
But now I’m a believer, and I’m betting the future on it.

Building From Scratch: A New Stack

Although Evan, Mervyn and I all have team experience, NativeNote felt more informal, more in line with our personal projects, and when we finished our initial prototype, we had allowed that informality to creep in with some poor design choices in how we built our system. We had agreed to work on an API-first style of development, but writing our own CRUD functions and keeping these consistent and useful became a complete chore. Operating as a team of five and having to ensure that everyone was aware of every design decision that we made was incredibly difficult without a structured stack.

When Evan brought up the idea of a rebuild, we worked together to develop a stack that would allow us:

1. Rapid development — in our early stages of this project, we want to be able to roll out new changes and ideas quickly. With all three of us being full-time students, being in employment and attempting to launch a startup, we want to use the toolkit that lets us focus mostly on writing features, not boilerplate.
2. Good behaviour — We want to use industry-grade tech and adhere to good standards. Although part of what’s exciting about being a startup is trying things that might not scale, we also don’t want to give ourselves unnecessary headaches when we do reach that scale. Also, we want this to be a learning experience for ourselves. Our ambition is to be world class — we need to hold ourselves to that too.
3. Future-proofing — We want to build a product that will last; we want to use technology that won’t become outdated within weeks. We also want to ensure that it’s easy for us to create documentation and maintain the code as we continue to iterate over it and develop on the knowledge that we’ve gained.

Backend Framework — Laravel

Laravel was the reason for the rebuild; so much that we were doing wrong on the server-side was already fixed and pre-packaged in Laravel. I fell in love with it for how easy it made creating a solid API that even had support for social authentication out of the box. The community and documentation is of course top-notch and it’s very friendly to new developers.

One element which sold me completely was Laravel Homestead — a prepackaged Vagrant box that contains all of the development tools that we use. It allows us to develop consistently across the entire team and I love it for that.

UI Framework— Knockout.js

I was introduced to Knockout while working with Teamwork.com and using it in Native just made sense. It’s never been so easy to just create powerful UIs that react effortlessly to data coming in from the server. It allows us to think of NativeNote as a modern single-page web application, and to deliver fast, reliable performance in the browser. Knockout is far easier to learn than many other JavaScript MV* frameworks; although we function as full stack developers, our knowledge lies primarily in the back-end. Knockout works as a fantastic entry point to the rapidly changing world of front-end development.

Cloud Architecture — Microsoft Azure

Microsoft have done wonderfully in building their cloud solution; it feels far more simple than AWS but with no sacrifice of power. We tried a lot of different ideas in the cloud world while we had the chance; Microsoft’s BizSpark program and their free trial for students helped us get to grips with Azure without running up a bill. We still have some love for AWS — in fact we’re still likely to be using S3 for storage — but Azure has proven itself as possibly the best thing Microsoft has ever done.

CSS Boilerplate — Skeleton.css

Bootstrap is bloated. It was honestly a godsend in that it made personal projects easy to add a coat of paint onto, but building applications with it leads to dealing with a lot of bloat. When building Native, I found myself using the overwhelmingly large UI Framework to perform basic tasks. Of course my first step was to rebuild Bootstrap minus the bloat, but we inevitably found ourselves requiring far too many elements.

Skeleton offers itself as a starting point, not a framework, and it comes in at 400 lines of CSS. While it claims to be built for “smaller projects”, Native is designed to be beautiful and minimal. We believe that Skeleton offers the approach to CSS that we need in order to succeed — a clean, simple, responsive starting point that works well in plain English.

My gripe with Skeleton? It places Raleway at the top of its font stack. Raleway is a wonderful font, but it looks terrible on web.

We may likely start using individual modules from Bootstrap such as modals, but we aren’t switching back to anything that requires us to run thousands of lines of CSS to display text on a page.

Database — MySQL

If it ain’t broke, don’t fix it. MySQL works excellently at all scales and all three of us have experience and knowledge in administration with MySQL. It works fantastically with Laravel (which even lets us quickly seed the database with test data based on the models we define) and in our Vagrant boxes. I use Navicat as an SQL client whenever I need to debug inside the database.

A commitment to quality at all costs

With big plans for the future and our new place in Eircom’s Lab353, we want to establish NativeNote on a solid technical foundation. A “minimal viable product” simply is not enough in the face of strong competition, but we believe that our new choice of stack allows us versatility in how we can challenge them.

Our CEO, Evan Smith, writes about the journey we’re taking on his blog. Read his latest post.

Colm Cahalane is the Chief Technical Officer of NativeNote.com. When he’s not planning world domination, he works as a Technical Intern at Teamwork.com and studies Computer Science at UCC. He’s the Finance Officer for UCC Netsoc for the incoming year. Find him on Twitter on @ovrplyd and read more on his website colm.cf.