That is, about how to start working with a software provider….

Every time someone starts a conversation with “I have an idea for an app like Uber, only slightly different, how much will it cost?”, I feel like clicking “disconnect from the conversation”. Despite so many years in the industry, this perfectly logical question still evokes strong emotions in me. I’m sure building architects feel the same way when someone asks about the cost of building a random house. How then do I find out how much my app will cost?

Building an application like building a house?

AAnalogies to building a house or, for example, to buying a car, which can cost 50 thousand or 5 million at first glance seem reasonable. However, the car is a finished product, which you buy from the showroom and on the creation of which producers spent years and spent billions of dollars. A house also, despite its complexity, consists of a rather limited number of elements and its commissioning usually means that we will not be making any radical changes in the near future.

Building software is hard to compare to other industries. If you’re building a marketplace it’s like building a city in which many independent things can happen within the laws and rules you set. If you’re building a business application it’s like designing and building an office building or an entire shopping mall.

It’s just a button…

You can imagine the complexity with the example of a faucet – as a faucet user, you turn on the right tap and hot water flows. Does it make you wonder at this point that in order to achieve such a trivial effect as water at the tap, hundreds of people had to build a whole network of waterworks? Sewage treatment plants? Pipes? Connections? It is very similar in IT, sometimes what you see as a user on the screen as one button, one popup, required the work of a team for several weeks, months. That’s why it’s easy to fall into the trap of estimating the time consumption of building a given software just based on what you see on the outside.

• Installing a faucet and a sink? 2h? Sure! T
• Adding a button and a popup window? We can do it in 1h!

What happens underneath is crucial and decisive. For a faucet installation, you need a ready-made connection. In case of a pop-up window, it may turn out that extracting information from the database and processing it by the system requires functions that do not currently exist in the system. The estimate goes up to 2 weeks.

Not now, later

“If you are not embarrassed by the first version of your product you’ve launched too late.”

In addition to the complexity trap in IT, we have another toy that is unheard of in other industries. Usually when you install a bathtub it doesn’t occur to anyone to swap the bathtub for a shower in 3 days. In IT projects it is an everyday occurrence.

An example straight from life – in the current week we create a registration form, which was designed on the basis of the latest UX standards, then marketing lets in a few hundred people to test the registration and account activation process. Analyzing the footage and heatmaps, it turns out that the results are 50% lower than we anticipated because in this audience, splitting the registration into two steps is a confusing process, making it ineffective.

We hire a UI/UX Designer and Developers, analyze the results and in the following days we work on a new version that should improve the results. Eventually the results improve and are better than expected.

Architects designing shopping malls do not have such opportunities. If it turns out that the designed entrance to the building discourages the customer from entering, they have a big and very expensive problem. They are not able in a few days to build a version 0.5 of the entrance to the shopping center and invite the next day a thousand people to use this entrance. In IT, we can do that. This is an amazing capability that allows us to divide the creation of a product into stages – or more precisely, versions.

In the first version we can create an entrance to the building using wooden stairs, and in the fifth version there will only be an escalator. This way we will be able to invite our customers to use the application after a few weeks, not years. Customers get to know our product, we learn how they behave using the product and what they need most.

Thanks to this approach, after a number of iterations a product is created that is much better suited to the customer’s needs than if we wanted to guess all possible user behaviors at the very beginning. In practice it would look so that our competitors for 12 months analyzed to make possible scenarios, and we, starting work from a simpler version after 12 months we have customers in the system, and a lot of knowledge about their needs and behavior. This is one of the biggest advantages of the agile approach to project management and the Time & Material model.

What do I deliver?

But why does it annoy me to analogize the work of a software development team to that of a courier? It is a great mental shortcut. The IT team and the courier are tasked with delivering something to the recipient. However, the courier receives the package and has to get it to the customer on time despite adversity.

The IT team has to understand what the customer, or rather the end user, needs, then design, build and deliver it. It is as if the courier received a delivery note with the inscription “Deliver a tasty apple pie to Wiejską street in Warsaw”, not to mention the fact that probably no courier would want to carry out such an order, in this case let’s assume that the apple pie would not be included in the package at all. Should I bake the pie myself? Or buy from the nearest bakery? Should I sprinkle cinnamon on the pie? Or is it actually an ironic joke and I should deliver a scone?

Utopia?

Neither the example of a courier, nor that of an architect, nor that of a car salesman can 100% reflect the process of creating a digital product, an application. Therefore, very often for people inexperienced in software projects, a collision with such topics as versioning, iteration, feature prioritization, defining the scope of MVP is something very difficult. Everyone would like to build an ideal product that will attract customers, sell itself and return the cost of investment in the first month after launch. However, we live in a world limited, among others, by time and money, plus the pressure of competition requires us to make decisions efficiently, often risky. Only years of experience and working with the right people can lead us to efficient work, and thus to success.

Just talk

All these aspects cause that when asking a software vendor about “the cost of an app like uber only a little different” you may collide with extreme quotes. A pretty apt analogy is to ask “how much does a car cost?”, “it depends :)”. You will recognize a professional team by the fact that they will want to enter into a closer contact with you, they will want to talk, understand. Only common conversation will allow to define if we are able to find what we will call “Version 1.0” or MVP (Minimum Viable Product).

If we find understanding here, it will be much easier to carry out the whole creative process of creating a product, it will be easier to manage the budget, priorities. It won’t be one-time project status updates once a month. Here every day our teams have to work together to make it a success.

Get involved

If you expect that today you will send an inquiry to suppliers, within a week you will receive several offers, arrange a meeting, talk about your vision, sign a contract and in 3 months you will receive a finished product – I have to disappoint you. Creating a product requires close communication, cooperation of many people. Building even the smallest application involves business analysts, graphic designers, programmers, administrators, managers. However, all these people are building something completely new, based on your vision.

If you want to build a product that will conquer the hearts of customers, you or your team must actively participate in the entire process. Otherwise, you will share the fate of 90% of startups that fail. The best way to do that is to get to know 3-5 selected software houses that match your size, industry and work culture. This will make sure that you work with specialists in your field and that the cooperation will be pleasant and fruitful.

Uncomfortable questions

Don’t be afraid to ask tough questions during the interviews, when we will ask about the value or sense of an idea. These questions allow you to separate the most important elements of the product. Knowing for whom we are building the product, what is most important in it and what goals you want to achieve with this software, we will be able to give much more than in a situation where you ask us to give you a quote based on a pdf brief..

Let’s build a team together

Based on over 12 years of experience I know that the best products are created when the customer’s team works very closely with the software provider’s team. In practice there are often one or two teams focused on building and developing the product.

To sum up, the most productive and giving the best results will be close cooperation and transparent communication between the client and the software supplier. To put it simply – open communication and direct, quick testing give the best results. Teams that ask questions, that want to understand the product are worth appreciating. Such teams care about making your product successful.

The truth is that only through such a qualitative approach can the contractor count on further work on the product and your recommendation. It is worth taking care of the common win-win, because your success is also our success!