What Does Cooperation with a Software House Look Like?

It's time. You've decided to create your own online store. You've defined your vision for the company, researched the market, and learned about the competition. Now it's time to start building your online store. If you thought the stage of difficult decisions was behind you, think again. It's time for one of the most important decisions in your project - who will be responsible for creating the platform. In today's post, we'll present potential solutions and explain what working with a software house typically looks like.

What is a software house?

Before we start talking about the collaboration process, it's worth explaining what a software house is. A software house is a company whose main product is software that it produces for its clients. It typically consists of a team of programmers who create software tailored to the needs of a given client. A software house often also has an advisory function - it helps the client identify their actual needs and define a roadmap for the application's further development. A software house may specialize in something. For example, at Rigby, we can create a web application or an information website, but our main specialization is advising and creating online stores. The advantage of choosing a company that specializes in a particular field is the wealth of experience that the company brings to the project. Such a company has already completed several projects in this industry, so it knows where potential advantages lie or which stages require particular attention.

Now that we know what a software house is, we should also mention another option for developing an eCommerce store - a freelancer.

Software house or freelancer?

A freelancer is a person who works independently, usually alone. They are a person and a company in one. They gather requirements, validate them with the client, create an information architecture, and then apply design to it. Finally, they write the code themselves, deliver it to the client, and then settle with them. That's a lot of tasks for one person, isn't it?

As you can see, the number of skills a freelancer possesses is enormous, so it's clear that there are very few people who do this job well. Freelancers' rates are usually lower than those of a software house because a group of people who specialize in a particular area backs up the company. If your budget doesn't allow you to choose a software house, verify the above skills of the person you are entrusting with the implementation of your online store. Entrusting so many elements to one person carries a significant risk because if any aspect is not done correctly, the entire project may fail. If you decide to go with a freelancer, be sure to carefully review their portfolio and, if possible, ask for contact information for previous clients. A simple phone conversation can help you assess whether the person you potentially hire is suitable for you.

However, if your budget allows you to hire a company and you don't want to transfer all the risk to one person, we strongly recommend choosing a software house. So, what does working with a software house look like?

Stages of cooperation with a software house

Often, our clients "after breaking the ice" confess that they were afraid to contact our company because they didn't know what would happen next. They would fall into the heartless corners of CRM systems of salespeople who would inflate their costs to the maximum and then declare a delivery time of many months. Fortunately, the above example is rare. If you choose a company that knows what they are doing, the process looks completely different.

Regardless of whether you are creating an online store or have an idea for a revolutionary interactive notebook, every company starting work on an IT project should start by examining your needs. Often, clients who come to a software house have a specific project already in progress. "Please make a website that includes A, B, and C." However, before we start implementing it, we should understand your current situation, the situation in which you want to find yourself, and create a path from the current point to the destination point. Of course, I want a simple online store! It may seem like a simple task, but there are many details that need to be clarified. After all, your brand is different from the competition, has different strengths, and emphasizes different values. The task of the software house is to understand these aspects and emphasize the most important ones. Creating an online store "just like others" causes you to disappear in the jungle of competition. Why would a customer use a new, average store when there are already ten others on the market that have been operating for years?

At Rigby, to understand your needs, we start with a brief. The brief is a series of short questions we ask you to get to know your project as broadly as possible. This allows us to determine the scale, stage you are at, and define your needs preliminarily. This brief serves as the "skeleton" for preparing to assess the project. How do we evaluate the project? We check the industry you want to enter, its size, current solutions, and competition. We identify the needs and problems of your future customers. All of this allows us to better prepare for the workshop, which is the next stage of cooperation.

The workshop is a meeting between the client and the person responsible for understanding the business logic and the technical person who will be able to assess the possibility of implementing a particular functionality. During this meeting, we outline the business logic of the project, its main assumptions, and potential user paths, i.e., the path we would like the client to follow using our platform. We create a list of functionalities that the project should include, consider the values they will bring, and their importance. The result of this meeting is a set of functionalities that need to be introduced in a specific order in the project, and a list of functionalities that can be introduced in the future, along with further project development. With this prepared list of functionalities, we can proceed to create an estimate and an offer.

After the workshop, we create an offer that includes the functionalities discussed during the meeting. Together with the technical team, we estimate the maximum and minimum time of realization. The introduction of a particular functionality may be delayed for various reasons that we cannot predict at this stage. Therefore, the time range works well and allows us to establish the estimation error margin. We multiply this list of functionalities with their time range by the hourly rate of the programmer who will implement the project. The result is a price range within which the cost of the project falls, taking into account the current functionalities. This time frame is, of course, approximate, as external factors and assumptions about some functionalities change during the project (we may want to add or change something during the project). We send this prepared offer to the client. Then, in case of any doubts, we can arrange a meeting to clarify, or after accepting the offer, we proceed to signing the contract. After signing the contract, we proceed with the implementation!

So, what does the implementation look like? Depending on the company you approach, it may look different. In the case of a company working in the SCRUM methodology, the process looks as follows. As you may remember, during the workshop, a list of functionalities to be created and the order of their execution was created. By creating such a list, we automatically created the project backlog - a list of functionalities that need to be implemented in the project. Within these functionalities, we create tasks that already contain technical guidelines required for implementation. We plan the first week of work. We choose which tasks we will do this week, confirm it with the client, and proceed with their implementation. After a full week of work, we arrange a demo meeting with the client, where we show him the results of the entire week's work and confirm the list of tasks for the next week. This cycle continues until the list of tasks in the backlog is empty. Then it means that the first stage of the project is completed!

In IT projects, many elements change every day. Functionalities are added, removed, and changed. The approach described above allows for dynamic project management. The client can change the requirements of a particular functionality at any time, and we can introduce these changes to the list of tasks for the next week. This provides great flexibility and a quick response time to changes. Projects conducted in this way can be infinitely developed and improved. Such an approach to cooperation facilitates communication in the project - the rules are clear, and all changes are possible to implement.

Summary

We hope that today's article has shed some light on what it's like to cooperate with a software house. Remember that a well-chosen company will not only write code mindlessly but also advise during the implementation of the entire project.