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.
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.
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.
#5. Putting It All Together
Oscilloskope - in numbers:
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.
We just sent you an email. Please click the link in the email to confirm your subscription!
OKSubscriptions powered by Strikingly