Working at Software-House vs Product Based Company

As some of you know, I ever worked at a software house-based company, but then I switched to my current workplace, which is a product-based company. Like I mentioned on Twitter several days ago, I’ll make an explanation based on my experience of the differences between working at a software house company vs a product-based company.

As you know, a software house company in general is a company that creates a service or app for clients. It means they are the third party that creates and fulfills the clients’ requests. Meanwhile, a product-based company is a company that has its own product or services that are offered to the users. A Product-based company usually has its own team to develop its own products.

Notices something here?

I worked at a software house company from September 2020 - November 2021. There are a lot of projects that have been developed based on the client's request. As you know, during my work period there, I was assigned to a BUMN client that provides train services, yes KAI. At that time, my senior and I developed KAI Access mobile app.

In short, KAI provides all the docs and requirements and we developed the app based on it. When the client says A, we have to fulfill it accurately. There’s no way to interfere with the request. In other words, I can only deliver the app or feature based on their exact requests. Actually, if there’s any concern regarding the requests, we can tell the client. But it will take more time and potentially the client will lose their trust if we cannot fulfill their requests, meanwhile, the software house company relies on clients to gain profit.

It’s hard to be Agile here. Mostly we work using the Waterfall method which a request comes from the client then we have to deliver it on time. I’ve tried to implement Agile Methodologies like Scrum or Kanban, but it’s quite hard because we have to deliver it accurately, not by iteration. In other words, I worked based on the request (sometimes spontaneously).

Long story short, I resigned from that company and then got my current job in January 2022. This time, my current workplace is a tech hospitality company.

My current workplace provides its own capsule or cabin hotel mobile and web app booking. The user also can use their smartphone as a key to enter their room (using QR Code).

Now, I’ve been assigned to the main product on the website. In other words, I developed the web app for my current workplace until now. Actually, I’ve been given the task to rewrite the whole website using Next.js (from Nuxt.js)🤣. But this time is different.

My main focus is on developing the main website of my current workplace. The request usually comes from the Product Manager/Owner then the mockup design will be made by the Product Designer until it’s handover to me. Before the handover, we usually discuss it and speak out if there’s any concern regarding the task so everyone can know what is the blocker and the general timeline. Sometimes, if I have some concerns about the web design, the Product Designer will adjust the design so it can make the development process easier. Feels more democratic here🤣.

This time the company uses Agile methodology for its development cycle. Mostly we use Kanban for every task, but we always do a weekly sprint planning and alignment on Monday to determine which tasks will be done that week. The recurring tasks from the previous week will be added to the next week.

Based on the Agile methodology, we developed the feature or request using iteration on each sprint. The product team will do the rest of the research on the customer behavior or even complaints, then the research result will be considered to be executed as a task in the sprint planning session. In other words, there will be constant updates every week/sprint cycle. Don't worry the manager has set up the max sprint point that can be assigned in a week, so it will make sure every engineer works ideally (minimize the overwork).

For the team structure, I can say that a software house-based company has the most diverse team or squad. Each team will be grouped based on the clients which have a very different context for each project request. For example, my former squad at my previous workplace is dedicated to the BUMN client. Simply, my senior and I work based on that BUMN client’s request (even sometimes I switched to another squad to solve the other client’s problem or issue reports). Changing squad here feels like you’re switching to another company but with the same benefit and salary🤣.

In my current workplace, there are also some squads. But this time, because the company is product-based, every squad actually has a similar topic because the company has its own product, capsule, or cabin hotel booking app. The team is assigned based on the main focus of the sub-product or feature that be developed. For example, my current squad is focused on customer-facing related like the main web app that is used by a lot of external users. Meanwhile, there’s also a squad that focused on internal tools or platform related.

When I was working at a software house company, I can say that the project deliverable is the main focus. It means, the project must be delivered on time and accurately based on the client’s requirements. There are some times that when the request comes, the software engineers will be hectic for a while. Meanwhile, there are also some times that there are no requests or bug reports so sometimes we didn’t know what to do🤣. Like I was saying in the first section, it’s hard to implement Agile methodology here because mostly the culture is Waterfall based.

There’s also some time that my former senior frontend engineer and I have to meet the related clients to discuss the requirements, the project timeline, and the contract documentation. To be honest, my communication skill is challenged here. And oh, by the way, that time I work from the office (WFO) every day even during the Covid-19 pandemic, so it’s quite tiring because there’s a gap time for commuting, and quite hard to find free time, especially during the hectic times😥.

How about the current workplace?

To be honest, when I switched to my current workplace, I feel quite a culture shock😅. This time, I have to be more Agile here. Like I said in the first section, it’s more to be democratic here. Every engineer can say “no” to a task or invitation that doesn’t have a correlation or related priority to their main task or role, or they can request the adjustment for the request/initiatives based on their concern. In other words, to convert the product initiative to a task, it has to pass the research step and have to be discussed with the related team, so everyone can know the context of the initiative.

For the meeting/alignment culture? Actually, it’s based on the squad. In my case, I work on the customer-facing related squad which means I developed the web app for the company’s users. This also means I have to align with the product and marketing team more because it’s the main product that the users use and affect the main company's operations. In other words, I still have to train my communication and negotiation skills here🙂.

But the main difference is I can focus on the product that I’ve developed here, even though sometimes I have to context switch because there’s some alignment meeting that I have to attend related to the web that I developed😅. And the main thing that I like here, I can work from home (WFH/WFA). I only need to come to the office once a month to attend a monthly meetup with my colleagues.

How about the coding behavior?

Hmm…. it’s quite opinionated I think. But I’ll try to tell the general story. When I was a frontend engineer at a software house company, I must have a project mentality which means I have to deliver the project on time and precisely based on the client’s request. To be honest, it’s very dilemmatic to implement a clean code pattern here, because of the tight deadline and some “magical” requests from the clients. The main focus is to finish and delivers the project.

Now in my current workplace, I realized that developing a product is very different than just delivering the project. The product has a longer life and it cannot be developed barbarically. Every product initiative has been researched by the product team, then it will be handover to the related engineer. I can say that I also have to develop a clean code for the product that I developed, so it can be more maintainable and sustainable in the long term. It’s mandatory to request a code review from the senior front-end engineer to make sure that my code is effective and has fewer code smells (actually zero code smells😂).

So yeah this is my testimony after working at a software house company and then switching to a product-based company. I didn’t mean to give negative reviews actually, just the story that I’ve experienced before😁. Both are good and it’s based on your preferences to work there.

So if you ask me, which one that I have to choose to work for, a software house or a product-based company? It depends. I think for a fresh graduate, it’s better to start your career at a software house company. Why? Because you’ll learn a lot from every project that you’ll handle. You also can learn from every client’s perspective.

In my case, after I work about a year at a software house, I felt overwhelmed with so many projects and clients. So that’s why I finally switched to a product-based company so I can focus to develop the product for the long term and also can train my coding skill to produce clean code. Also working at a product-based company trains me to be a product-minded software engineer, so every code that I produced must be aligned with the user’s needs for the long term.

It’s kinda hard to tell everything in this short article actually🤣. Feel free to discuss more in the comment section, or you can DM me through Twitter, I’ll try my best to answer during my free time. Hope it helps, thanks.