intro

i’ve been in different stages of startups since 2022, ranging from series D to bootstrap so roughly about four years with breaks in between. as i just left a bootstrap startup as a full-stack engineer, i thought it’d be a good time to reflect, pen down what i’ve learnt and gone through over the years.

the transition phase

there was a “culture shock moment” when transitioning from a series D to a bootstrapped company with friends.

in a series D company, you have an entire team around you. colleagues with different skillsets, knowing their ways around the system because they’ve been here longer than you, and if you needed any help they’d jump in. if any mistakes are made, people will point it out and tell you, reducing the blast radius of your mistakes. there’s a safety net to catch you and an implicit structure to rely on.

however in a bootstrap startup, it’s different. the team is small, there’s probably only 3-5 people including you. everyone in the team has their own role to fulfil and you’ve more responsibilities so naturally your impact (work done or mistakes made) are amplified. you learn to stand on your own, figure stuff out yourself, being resourceful, google and llms are your friends to get you unstuck. this journey is a steep one, people say is hard but you don’t listen or believe until it hits you.

similar to what Mike Tyson said: “everybody has a plan until they get punched in the face”. meaning the moment a punch hits you, it’s so painful and overwhelming that despite having a plan to perform certain moves, everything goes out of the window and you go into survival mode.

everyone around me said it was difficult and hard, but i didn’t feel the gravity of it until i joined one and went through the process. in addition to what i said above, the uncertainty and pain makes the whole experience gripping.

all startups have some amounts of uncertainty, but a bootstrap is the most extreme of all. figuring out if the initial idea you had works or not by building in the dark, hoping there’s value in it and somebody out there sees and wants to pay or fund it. if nobody does, you pivot and keep pivoting and you keep trying and trying, like an endless march where there isn’t an end, until somebody says stops or in this case you get your first client or first funding.

at the same time, it’s painful because the lack of revenue and it eats away at your saving. each change or iterations toils on you a bit, as you do not know when this venture will take off. slowly but surely it’ll start to wear on you down. you just have to keep your head down and keep trying until you either win or quit.

how i work nowadays

despite all that, i’ve learnt a lot about myself especially on the way i approach work.

when asked to do something, i’d ask for more context to form a clearer picture, and if i feel that its not enough i’ll ask questions. i’ve realised without a big picture view, there will be holes in my understanding and i’ll end up guessing what people want, resulting in building something which is misaligned. it’s even worse with llms because i can ship fast but if it’s in the wrong direction, i don’t think time is particularly well spent.

with a better understanding, i can figure out what should go into a proof of concept which contains the required functionalities without overbuilding and this should usually take a few hours to a two days showing that it’s truly small. by keeping it small and shipping fast, it enables me to show what i’ve understood to others, making sure we’re aligned.

through building a poc, i discover the nuances i’d not thought of even though i understood what we want to achieve conceptually. this helps me to form a better understanding what’s required for a full build.

after the poc is done, before even showing it to others, self-testing is important. i’d test out what i’ve built to ensure it works, be it an api, a website or an end to end integration. if something breaks, or i find a bug, i can fix it before showing others. this gives other reassurance as well because the stuff i built is tested, and it saves people time, nobody wants to see a demo which is full of bugs. unless something is omitted on purpose due to the constraint or it’ll be worked on after the demo.

so in the event that what i showed had some misconception, the blast radius is contained because i can take the feedback, work on it and show it again. it’s this tight loop of figuring out the minimal functions, shipping it small and fast to gather feedback helps to ensure alignment along the way.

if the poc is aligned and everybody likes it, people can take it and show others for more feedback or do a demo. this helps me buy time, as i wouldn’t be pressured to deliver something and i can use the extra time to do things that are more complex such as planning, researching or figuring out how to better implement certain parts i’ve never done before.

with that breathing room, i can revisit what i’ve built, by thinking of what i’d do differently and come up with a better build as now i’ve a more in depth understanding of what we’re trying to achieve and discovered the nuances.

ending it off

alas, being in bootstrap startups isn’t easy but the takeaways are immense. through this journey, i discovered more about myself, and figured out my own working style. the next leg for me is to find a growth stage startup to plant my feet in and execute on what i’ve learnt.

i hope people enjoyed reading this as much as did writing it. see you guys next time!