Lessons Learnt at a 3-person Startup

In this day and age, there is virtually an infinite amount of information available online regarding entrepreneurship & startups – blogs, books, MOOCs (Massive open online course), forums, and many others.

It is an extremely daunting and overwhelming task to systemically digest all the information you are presented with. This is a classic case of analysis paralysis, where over-thinking/over-analyzing/deciding which resource is the best leads to no action being taken; I personally suffer from this phenomenon time and time again.

Over the past few years I’ve been building up my knowledge of entrepreneurship, from fundamental Startup Do’s & Dont’s to fundraising strategies and building company culture. However, it was only recently where I was thrown into the deep end of the pool – right into the heart of a startup – where I could finally put the theory I’ve learnt to the test.

From January to May 2016, I was a part of Bumbung, an online platform to match home-seekers and real-estate agents in Malaysia. When I joined the team, I was the first employee – which meant that I worked directly with the two co-founders Gadiy and Claire (GC for short). The company had been conceived just a few weeks prior and I had the privilege of sitting into the first company meeting. To give a bit of background, Bumbung was GC’s way of improving home-seeking in Malaysia. The biggest difference between Bumbung and other real-estate platforms was that Bumbung did not allow the user to search and browse through properties. Instead, the user would be automatically matched with suitable houses which fit the preferences he or she indicates. This was the unique selling point – the convenience of not having to browse through thousands of homes to find a suitable one.

Working with Gadiy & Claire was a pivotal experience in my growth as I managed to witness first hand something most people do not get to see – the earliest and youngest days of a startup. What is it like to start a startup? What should I know before I start a company? What should I look out for when I make my first hire? In this post, I try to summarize my biggest takeaways from this experience and answer some of these pressing questions.


Ever had that ‘million-dollar app idea’ which you know will work? The only way to truly find out if something is worth pursuing is to test your assumptions about consumer behavior. This is one of the core ideas of The Lean Startup, quickly testing assumptions and pivoting where necessary. However, I believe that we at Bumbung did not test our assumptions very well. The biggest assumption that we needed to test was whether or not customers would be able to change their ‘browsing mentality’ (browse through every listing) and allow us to narrow down the choices of homes for them.

We did try to test this assumption – by having a session where ‘potential customers’ tried to use a prototype of our website. This went reasonably well as we received generally very positive feedback, but I did have my doubts about how accurately we had ‘tested’ our assumptions. One of my mentors once said “If you want to test whether the food you cook is worth selling, don’t ask your potential customers ‘Would you buy this for 10 dollars?’, because they’ll almost always say yes. Instead, make them give you the 10 dollars and tell them you’ll cook it for them the next day”. I believe that we did not do enough to test our assumptions about customer behavior, and that could potentially mean that we were building a product which would never catch on.

Given the chance to start over I would change 3 things:

1. Do not get your friends to test your product
This is quite self explanatory, but I think this may have skewed our testing results. No one wants to be a bad friend after all.

2. Make the ‘users’ commit
I would have asked the users for their email addresses/cellphone numbers if they would be interested in being updated about the product. People do not like to receive emails/texts/calls about things they are not interested in. If they willingly provide their contact details, it may be a good sign that they are actually interested.

3. Create some sort of tracking mechanism
I would have asked the users to share the product with their family and friends and given a special link for them to share. If I am able to track how much/how often the link is being clicked, I’ll be able to get a very good gauge of the product’s ability to spread through word of mouth. If the link is not clicked at all, it is a good indicator that the product does not get people excited enough to share it with their closest friends.


Get a technical co-founder. Seriously. If you can’t find one but want to start a technology company, BE the technical co-founder. Read up and learn some code – I promise you it’ll be worth your while.

Gadiy & Claire were non-technical founders, which means that they did not have deep expertise in technical aspects of the company, which for Bumbung’s case, meant that all code had to be outsourced. We outsourced the entire development process to a team of 4 – a product manager, designer, web developer and mobile developer. There are undeniable benefits which come with hiring a development team – you have a team of highly skilled people working for you, which relieves you of the burden of finding tech talent. It’s also generally much faster to hire a team on contract, versus building a team yourself.

However, I personally believe that the cons severely outweigh the pros. Listed are my 3 biggest reasons for having a technical co-founder.

  1. It is EXTREMELY expensive to hire a development team. If you’ve worked hard to raise VC or private funding, be sure that hiring a development team will eat up a substantial amount of your money – money which you could have spent on growing the company or hiring top talent. Having a technical co-founder does not necessarily mean that he can build the entire product on his own for free, but if he can build even a quarter of the product on his own, you potentially save tens of thousands of dollars.

  2. A capable technical co-founder will have a good understanding of what can be built and how long it would take. He will be able to tell you that your prototype for an “autonomous electric airplane which operates on energy from nuclear fusion and travels at supersonic speeds” is not build-able within 3 months. In my experience at Bumbung it was very often that the founders, Gadiy & Claire, were unsure of how long it would take to build a certain feature – and hence were clueless if the development team was working fast or slow. Having paid good money, you’d definitely want to know if your development team is sluggish.

  3. Control and quality. Having a technical co-founder who directly oversees the development process ensures a much higher level of product quality. After Bumbung was built, we were slightly unsettled as the quality of the product was not up to expectation. Features were missing, the user interface was not perfect and there were multiple bugs in the code. Having a technical co-founder who holds a stake in the company usually means that he will work his butt off to make sure the product is as good as it can be.


You have an idea for a product. You have a small team ready to begin work. You have money in the bank. It’s go time. Where do you begin? Do you start writing the code or designing the product? Do you start with a market survey or do you hire more people? Through working with the development team, I learnt a very effective method of rapid prototyping and testing called the “Design Sprint Method” which is used within Google to test new products. This is by far the best and most holistic method I’ve seen thus far.

This method is essentially a structured way of organizing brainstorming sessions and testing ideas. One example of how we used this methodology for our product was when we were discussing which features to include. We had a brainstorming session where we would individually write down as many app features as we could think of for 20 minutes. Once the time was up, we combined everyone’s ideas and organized them based on their importance. This way, we could visually see which features were the most important and could systemically put the rest in the pipeline. I found that this method is much more effective than a group of people sitting together and verbally discussing which features to include – which is how most disorganized meetings go.

The method can be found here:





Being someone who lacks real leadership experience, managing people has always been foreign to me. I’ve observed effective leaders in school and tried to identify certain aspects about them which make them good leaders, but I was never able to articulate my thoughts about leadership. Working at Bumbung and reading multiple management books opened my eyes to the world of management, especially management of small teams. These recent experiences helped me form certain ideas about People, which I attempt to explain here.

I’ve talked about the importance of having a technical co-founder, but I also believe that there should be some guidelines to the types of personalities to have in a founding team. There should be 2 types of people in the founding team – divergent thinkers and convergent thinkers. Divergent thinkers are people who are always thinking of new possibilities. They get excited when there is new opportunity and are often very good at thinking of 101 ways to achieve a certain goal. However, I think that there always needs to be a counter-balance to be effective. Divergent thinkers often get distracted (coming from personal experience) by the limitless opportunities which lie ahead. They need a convergent thinker who is able to collect all these ideas and streamline them to achieve set goals in a systemic way. At Bumbung, I felt that we did not achieve this balance of personality traits. Strategy and operations were often messy; meetings and discussions were spontaneous and not very impactful. After each meeting, we would feel reinvigorated and accomplished after discussing a wide array of issues and coming up with many new ideas. However, a conclusive and structured plan to carry out what was discussed was often missing. A third co-founder who has a strong convergent mindset would have been extremely beneficial to the company.

Other than the founders, it is obvious that the initial 5-10 people at the company have to be of the highest quality. However, I never knew how difficult hiring would be. We had posted job offers on multiple platforms and were constantly receiving applications (I reviewed the applications for interns), but the quality just wasn’t up to expectations. Many of the candidates applied for the positions with close to no understanding of our industry (real-estate) nor the way startups operate.

Because of this, I think that the core team should be sourced out by the founders instead of opening the positions to the public. We wasted a lot of time interviewing candidate after candidate, only to be displeased by the quality. Instead, I think that founders should actively seek out potential employees – be it through their own network (that’s why it is important to have a large network) or elsewhere. Looking for a software developer? Instead of advertising the position online and waiting for applicants, I think we should have hunted top talent from universities, coding bootcamps, or even other companies. Although this could take a long time as well, I think this method has a much higher likelihood of finding a suitable and competent employee.

Once you start making hires, one more thing which you have to think about is company culture. ‘The Hard Thing About Hard Things’ goes into this very extensively and only after reading it I realized the importance of company culture. Reflecting back on my experience at Bumbung, there are many things I learnt and also certain things which I would have done differently to cultivate a strong company culture.

One thing which I thought worked very well was the idea of stand-up meetings. For approximately 10-20 minutes every Monday morning, the team would stand in a circle and take turns to talk about what they are working on currently and what their plans are for the week. I think this was effective because it almost eliminated any form of distraction while encouraging everyone to speak up. Bumbung also organized a sharing session, where every week one of the employees would share about their personal life and interests outside of work. This probably served well in fostering team bonding.

However, I don’t think we should have stopped there. What I would have done differently is create another informal hour-long discussion session at the end of each week to discuss just about anything and everything. At Bumbung, I felt that we did not create a strong culture of openness (not anyone’s fault, it just did not happen) as I often did not feel completely comfortable voicing my thoughts. As a founder, I would have pushed very hard to encourage everyone to give criticism, even if they did not have any solutions. I think that the phrase* “don’t bring up a problem without a solution”* can be absolutely crippling to a company and I would avoid this mentality at all costs.

Secondly, other than fostering openness I would also want to try to organize 1-on-1 meetings with each employee (learnt from Ben Horowitz) to understand them better on both a professional and personal level. I, as a founder/manager, would want to understand each employee’s individual goals and try my best to help them realize their goals. If the new intern says that he wants to learn to become a better programmer, it is the manager’s duty to help them achieve these goals by giving him more opportunities to program things. Lift an employee up, and he’ll do the same for your company.

In conclusion, these are some of my biggest takeaways from my time working at Bumbung. This narrative may seem like I am giving Bumbung and its founders undeserved criticism, but I am trying to be as objective and introspective as I possibly can so that I can draw the most value out of this experience. There are countless things I myself could’ve and should’ve done better, and I regret that I did not have the mental capacity or bravery to fix these issues while I was at Bumbung.

Hence, I hope this reflection serves as a reminder for myself of what I learnt from my time working at Bumbung as well as a way for me to share my experiences with everyone else. Keep in mind that this reflection is told from my perspective and is likely to be biased in some way, so I advise readers to take everything I write with a pinch of salt.

If there’s anything you feel I missed or would like me to talk about more, do not hesitate to drop a comment below or shoot me an email.