I’ve grown a lot from my experience co-founding StockRender, which through hard work and blind luck has become a successful venture. I was fresh out of university when I began working on StockRender and had never worked at a startup let alone co-founded one. I compensated for my lack of experience by learning as much as possible everyday. I read countless articles online. I bought and devoured dozens of books about technology, management, funding, scaling, cost-cutting, and the like. This effort provided some semblance of a baseline for me to lead this project.

Looking back four months later, I’ve learned a lot. It was difficult, stressful, fun, hectic and I would do again. I’ve worked with a diverse team which I’ve had the privilege to mentor as well as learn from. I also worked with cutting edge technology and solved big data problems. The lessons I list are observations of things that went well, and things that didn’t. They are just the 8 most obvious things that come to mind from a list of many.

We chose to develop with Koa because it could accelerate development while avoiding Express’s drawbacks. This was a tradeoff, learning the koa ecosystem involved a lot technical debt but we figured it was worth it. As a next generation technology Koa looked appealing but its scarce documentation and small community meant we would be flying solo with minimal assistance. We rolled up our sleeves, brewed some coffee, and started coding.

Small bugs turned into hours of debugging. Syntactical issues turned into long games of guess the syntax. And finally, our lack of experience combined with the lack of community tools caused us huge headaches when deciding how to structure our architecture. Some number of iterations later, we had everything figured out. Finally, Koa was pleasant to use yet the overhead of learning it all was too costly. We spent too much time wrestling with the language; as a result we were slow to market. We also had to cut some features since we had gravely underestimated the hours we would spend learning and rebuilding basic tools. Tools that existed for Express but not Koa.

I now understand the value in selecting a mature technology like Express. It allows the business to benefit from the community and their tools, it maximizes the time developers spend on the business directly, and it eliminates many technical risks. Would recommend.

Koa did not have any frameworks so we went frameworkless. Nevertheless we rationalized the benefits of our decision. Our application would not have the bloat of unnecessary features that large frameworks tend to have. We also believed that we would be able to customize our mini framework to our business and maybe even make it open source. We entertained the thought that we could become leaders in the Koa community. Ha.

That’s not exactly how things turned out. There were few best practices for Koa so we had to figure out how to integrate modules into our code on a case by case basis. This also meant we created our own best practice which is a pitfall in itself. Not only was this time consuming but new hires wouldn’t be able to simply Google our workflow; instead they would need a someone to teach it. Also, too much time was spent settings things up then tearing them down while constructing our workflow.

As a technical adventure, building our own framework was fun and educational. As a budgeted project with time constraints we made the wrong decision. As previously noted, our time would have been better spent working on the business directly instead of the tools. There’s a reason frameworks have so many features. I learned this the hard way.

Just because a technical problem seems exciting, fun, and challenging does not mean you have to solve it. We spent a few weeks developing accounts, sessions, emails, passwords, and user databases. We then overhauled the entire system and used a service called Auth0, which handled all the logic and only took a handful of days to set up. We were also considering rolling out our own load balancers, monitors, and other misc. devOps features. Instead, we chose to use Amazon Web Services which handled all of that for us.

Using third party services cut development time and costs significantly. Better yet these services are usually highly tested and more secure than anything we would have built. They allowed us to focus on the unique parts of our business and ignore the administrative chores. In the future, I plan to use as many third party services as I can to reduce my team’s responsibilities. When it becomes necessary, then we will roll out our own solution and migrate the data over, but no sooner.

We had already built a proof of concept that was in demand by the market so we began working on a minimum viable product. We built administrative features such as accounts, payments, security, and load balancing. As the launch date approached the situation constantly evolved until we just needed a prototype to raise money. We kept the core elements of our business, and removed all the administrative crap that we had set up. Over half of our work was swept under the rug.

Had we focused on our core service it could have been twice as good and would have netted us a higher valuation. Building unnecessary features was a colossal waste of time and resources. Moving forward I will identify and prioritise business features versus administrative features. I will also share my findings to the team and stakeholders since poor communication contributed to moving in the wrong direction.

The first couple of iterations we worked without contact to the outside world. Consultations were few and vague at best. Coincidentally our project’s progress was also slow. I decided to meet with one of my friends, who was a serial software entrepreneur, for advice. To my surprise, our chat over brunch presented solutions to problems we were experiencing. Weeks of research, work, and prototypes could have been avoided by a simple coffee meeting with an expert who knew the problem well.

Originally, I felt guilty when I went out to a long brunch during work hours thinking “but if I’m not coding, am I really working”? But over time, and plenty of meetings, I’ve come to the realization that a meeting is the most optimal decision in every way and saves me days if not weeks of effort. Always, always look for mentors and counsellors in software, they have walked the path you’re starting and know the best way for you to reach your destination. However, beware the ones that are trying to sell you their product. They’re there to push their own craft instead of finding the optimal choice for yours.

Before StockRender I worked at a design agency so I was no stranger to meeting with various departments but this did not adequately prepare me to lead a software project. One of the prized notions of being at a startup is that anyone’s voice can be heard and anyone can influence the direction of the company. If left unmoderated, this concept can cause the project to grind to a halt.

The notion that everyone should contribute to everything in a startup made our meetings run on for far too long. Too many decisions were a democratic process where we waited for a majority agreement to move forward, sometimes on trivial matters. I also noticed we had many run-away tangents during meetings. This was worsened by our lack of office space. Our meetings were held in our primary workspace so everyone felt obliged to contribute and would be distracted regardless of their willingness to participate.

I’ve realized having a room dedicated for meetings is valuable. I recommend establishing everyone’s responsibilities in the company more explicitly. Before a meeting, we now write up a simple agenda of what is to be discussed and invite the members who are needed. Finally, we established a culture / expectation where everyone is expected to keep the meeting on track. Everyone is positively reinforced for saying something like “that’s not on the agenda, let’s take note of it and get back on topic.” I find that the lack of expectations is what causes meetings to derail and people shy away from interrupting someone on a tangent for fear of seeming rude. Neither is in the wrong so we should set up an easy way for anyone to get the meeting back on track. We’ve only been doing meetings like this for a short while but they’re been efficient, fun, and productive.

Unless I’m working on trivial tasks, I’ve found pair programming to be more fun and effective than going at it alone, especially if we can banter. Technical speed bumps are resolved faster and code is of a higher quality when working in pairs. Tackling problems solo for eight hours is much more likely to make me feel exhausted than working with a buddy. I recommend the buddy system. Sometimes I felt guilty working in pairs since it felt too fun and it felt like it resulted in lower productivity. Looking back however, I realized that some days I’d stare at a screen trying to fix a bug for eight hours that someone else was able to crack in just a few minutes. That’s an oversimplified yet decent example of why working in pairs is good for my sanity and the product.

Building a company is an endurance event which requires a steady pace. There were times when our aggressive deadlines made us work plenty of overtime. This would bleed into a two week crunch time by the end of which everyone would be completely done. We’d all need to take two to three days off to recover, which was originally not accounted for on the sprint chart so the project looked very behind schedule. These were bad management practices on my part. If the team consistently is struggling to meet deadlines, then chances are it’s not their fault, it’s yours. There were sometimes when individual members would opt to work extra, be it for work or a pet project. This would last a week or two and then all of a sudden their productivity would tank and they would need multiple days off.

Our team was young and new to the industry so we had yet test our mental capabilities to their limits. During our time at StockRender every single individual burnt out multiple times on an aggressive schedule. It became clear to everyone that something needed to change.

We pushed back the work day start time from 9am to 10am so we could get more sleep. We approached ominous deadlines with care. Instead of pushing the team harder we’d maintain the current work pace and adjust deliverable expectations accordingly. We took longer lunch breaks. Originally, we’d just grab our meal and eat it while continuing to work. Now we would actually take out food outside, enjoy the scenery and talk about something other than work. Although on the surface this looked like a loss in work hours, in reality it boosted morale, cheered everyone up, and inspired us to work with renewed vigour the moment we returned from lunch.

Personally, I made an effort to spend my off time doing activities that de-stress me. There’s a lot of ways to pass the time outside of work, however they all have varying levels of de-stressing for you. Figure out what makes you happiest and don’t remove it from your schedule!

In Closing

I had a blast working on StockRender, there were ups and there were downs and I wouldn’t have it any other way. I’m better because of it and I am very psyched at applying the lessons learned to my next venture. Thanks for reading, bye bye.