What I learned from being a Lead Dev for a Startup (part 1)

About a year and a half ago, we took on Two Thousand Times as a client. They had an idea to build a storytelling platform for the masses. Their idea was separate from the likes of Medium in that it would build a community of writers and it would promote anonymity. The anonymity would help the writers to be true in their emotion and not afraid that they would be found guilty of their deeds. Most of all, there is a limit to the length of writing; about 2000 words or less. This was to promote short stories and to limit people from rambling. The idea of self-help/healing as well as self-exploration really struck a chord with us. We as Y-Designs helped them create the prototype which lead them to their investors.  

As soon as the funding came, it was all official; we were to hustle and bustle to build out our little prototype into something less buggy and more real. Sondry is built on top of Laravel, and NodeJS. Most of the web stack is Laravel while some of the surrounding components are built using NodeJS (Socket.io for messaging for example). The strategy at this time was that we had no time. I mean, no time = no strategy. We were given 7 weeks to launch. Okay, actually the investors decided that we need to build it in 6. Lesson 1: Don’t expect people to understand how long anything takes. Slash features when you need to keep yourself kind of sane. (There goes messaging from launch!)

What I haven’t told you yet is that before we could actually dive into the main web app code, we had to figure out another piece of a puzzle. The landing page. The landing page is a placeholder site until the real site can launch. Our functional requirement included being able to actually sign-up as a real user (in the database) from the placeholder site. To make matters more complex, we had to build two versions. One version was a really complex one page scroller with a lot of HTML5 animations. The second variant was a simple one page image with just a signup. Turns out that the complex one did much worse than the simple one. We were idiots wasting our time when we could have been just coding the web app itself. The landing page also took longer than a normal system since we had a running version of the beta site. We had to keep the user signups in sync to make sure that there were no username collisions. Building a secret REST api for the web app took time too. Lesson 2: Don’t waste your time on the landing page. Keep that shit simple!

Let me list you what’s involved here:

• 1 non-coding CTO/Sys Admin
• 1 Lead Dev (that’s me)
• 1 Junior Dev (that’s our intern)
• 1 Designer/Front-End Dev (Max)
• 2 Founders

That’s six people trying to build a content writing social network in 6 weeks. Two coders writing functions and one designer following the functional builds with SASS/CSS. A Sysadmin trying his best to deploy applications in Linux (which he’d not dealt with in 5 years). Our process was decidedly waterfall for the reason that we had to follow a very strict timeline. We waterfalled each functionality: Kind of Spec, Design, Approve, Develop, Commit, Deploy. In reality, all it can truly be described as is a mad house. In that time period, I had over 150 commits, the intern had 100 commits, and the designer had about 100 commits too. Obviously, the commit sizes vary, but most were pretty significant. We were probably not following best practice of “commit early, commit often”, but that was just part of not having a DevOps/extra hands to help us set everything up (We setup Jira/Stash much later). Well, what the fuck, we had to gun sling anyway, we only had 30 days or less at this point. Weekends were not a thing. So, 6 weeks, ~350 commits and I dunno how many lines of code later we had Two Thousand Times launch on September 17th. Lession 3: When in doubt, do what you can and you’ll get through; it won’t always be pretty though. In hindsight, an extra week devoted to just planning would have been nice (not that we had any time).

Well. Let’s just say that leaving every detail up to other folks isn’t always a good idea. Some folks don’t know that you have to lower the TTL (time to live) on the DNS and that mobile networks are notorious for caching DNS information. I was too busy coding to pay attention to the details of the deployment for the official day…. The site worked for everyone in the world, except for those of us on the mobile networks at the launch party. Type 2 fun commence! Lesson 4: Lower the TTLs for your A and AAAA records a few days in advance of the launch and make sure that your real deployments are not in a separate instance of your server farm.