Big Companies vs. Small Startups: What's the Difference?

Photo by Mario Gogh on Unsplash

Big Companies vs. Small Startups: What's the Difference?

I have worked mostly in small & early-stage startups but got an opportunity to work at a large organization like Amazon. Listing down the different processes that are followed in both the organizations describing the development process & release process in them.

Startup work life:

In the startups where I worked, we had lean teams (mostly 4-5 developers) who actively worked on development and a few designers with whom we collaborated. The development process mostly involved setting up the codebase locally and asking questions about it to get clarity on certain patterns in the initial days. Mostly, I worked in 2-week sprints where we were assigned development tasks around the product, like enhancing a page UI or creating a functionality according to the designs. Once you are done with the implementation, you would raise a PR (Pull Request), which would be reviewed by senior team members. Then, you would address any comments by them and merge the PR. The feature might go live initially in a staging environment, which would be tested by other developers or designers to validate that the feature is working correctly. If everything is okay, we will release the feature to production along with other features in a week.

Amazon work life:

It took me almost 20 days or more to properly set up my work laptop as you need to follow a lot of steps. Mostly, we followed 10-day sprints which included retro meetings to discuss any feedback. The product manager and managers would decide the priority of the feature for the sprints. Based on that, you would start working on the feature and raise a Change Request (CR). Once you raise a CR, the code is tested against previously configured tests for your project. If any test fails, you need to fix them. The CR will be reviewed by at least 2 reviewers, but sometimes a 3rd reviewer gets added to it if the feature is large. If the approach is correct, they will approve the CR, or else you need to have meetings with the team and decide on the approach to finalize it. If everything looks good after multiple reviews, or depending on comments, they will approve the CR, and you need to merge it to the mainline.

If you need to update a CR after a review, you will have to raise another revision for the CR. For performance reviews, how many revisions occurred for your CRs will also be taken into account, both for the reviewer and for you. So, it is recommended to close it in 2 revisions.

The release process at Amazon is very different from the companies I have worked with. The top management decides on particular dates for a release, usually 2-week or 3-week release cycles. Before a week from the release date, you need to merge your changes to the mainline. They will go for QA testing. Once everything is finalized by QA, then only it will go to production, or if they find a bug, you need to fix it and merge it into the release branch for the release date.


I felt that working at both a startup and Amazon is challenging; you have to keep up with deadlines and deliver features on time. I think when you have a streamlined approach to doing things, you can perform better and manage the expectations of the management. Eventually, any startup or large organization will create their streamlined approaches.

PS: Actively seeking frontend/fullstack JavaScript roles. If you have openings that match my skills, please connect with me on LinkedIn. Let’s discuss opportunities!