The existence check
Before you build something, check for an open source alternative. You might not find the exact match, but something similar. Later, tweak it according to your need.
An year ago , I made a news app for sports. When the app grew, I needed a way to manage users, add polls, etc. An admin panel was required.
I came across Flask-AppBuilder. I wrote the database model. It automatically generated views. They already had a login system and I could create admin users through commands. This was a life saver. Later, the app grew more complex. I had more things like tags, fixtures, etc. I could generate the views in minutes.
This didn’t look great, but did the job. Since this was only for employees, it didn’t matter. Some companies build such things from scratch. Such waste of time and money.
The trade off
There are few frameworks which allows you to build things really fast, but don’t guarantee scale. Meteor in it’s initial stages, didn’t promise scale. A lot of people had issues . However, it helped ship things really fast. We could do things in days, which usually took weeks. Once you are done developing the responsive web app, one command is all it takes to package an ios or android app.
We prototyped fast. Things used to break. However, we got it up and running in no time.
Question traditional means
The task was to fetch news articles till the last sync. Doing this with API’s is a pain. You have to loop through multiple paginated results, ensure it doesn’t take up too much memory, deliver it really fast so that user don’t have to wait etc.
This is when I heard about Google Cloud Messaging (GCM) topic subscription. It’s a simple pub-sub. I made the client programatically subscribe to the topic ‘sports’. Then my parser was set to publish all news to the ‘sports’ topic.
This went as a push notification to the client. In the client side I parsed the notification content and stored it in the database. I didn’t have to write any API’s (web based). The best part is Google Cloud Messaging is free. I could scale this to millions without spending a dime.
Build first optimise later
In the early stages of a startup when you are still figuring things out. You go through rapid prototyping. The more you engineer it, the more it hurts when you have to throw it away. Unless you have validation, I would say, its enough to make it work. When users stick to your product, optimise it. Around 90% of the prototypes I build went to trash.
Don’t over engineer from day one, instead optimise it incrementally. I made the mistake of worrying about scale and security. It was not worth it. I agree there are chances your product can go viral and it may break. But if your product is valuable, people will come back.
Adopt growing frameworks
Some people are really reluctant towards learning new things. Even if it could make their work lot easier. I did struggle to setup docker initially. Later my co-founder didn’t have to bother me to deploy the CSS updates. He could trigger the deployment with a git push.
I have seen a few employees making their own frameworks instead of adopting the one which has a well established community. The problem is maintenance and upgrades are costly. A framework with a well established community gives free maintenance and upgrades. The worse scenario is when this person leaves the company. If the product is complex , developers will have a hard time taking the product forward.
Negotiate before you build (This is not possible in most startups unless you are the CTO). Your business founder might need a lot of things from day one. A product gets better through continuous iteration. Tell him, if this works we will add that. Instead of building ‘this and that’ and scraping them both.