How to Plan the Budget for an Application and How Much Does It Cost? From Idea to Go-Live!

Hi, I would like to welcome you very warmly to the next episode of our JUST No-Code podcast. Today we're going to talk a little bit about budgeting, that is, we're going to answer a question that we get very often and that is most often asked by various companies, organizations, or individuals. Namely, how much can such an application cost? Of course, the topic is a bit complex. To say how much such an application can cost, we need to ask a lot of questions, we need to know a lot of answers, and we need to know a lot about such an application. Unfortunately, this is not always possible. We will not always know everything at the very beginning. That's why, as you probably know. Which we will also talk about in the next episodes of the podcast. In IT or to be more precise in development we use the Agile approach, the so-called agile approach, not the Waterfall approach, which means progressing aspects one after another. Just an approach that guarantees us some flexibility in terms of what we create.

‍

And today we are going to talk to each other about this very subject. We will answer such questions as What is application budgeting? What is fixed price, What is time & material? What is priced, that is, what is taken into account for the valuation that we prepare, for example? What influences this valuation, and why is it important to have this in your valuation, in your quoting at all?

‍

At the very end, we will answer the question of why it is cheaper to develop applications in no-code / low-code than in the traditional approach. What exactly is the reason for this difference, we will tell ourselves, what this final cost of the application de facto depends on. I hope you will find this episode interesting. Here we go! Okay, so let's start with what app budgeting is all about. Firstly, app budgeting is when a client comes to us. You come to us and ask us the question, "Hey, listen, we have this idea for an app. How much could it cost?" Of course, the answer will mostly be "it depends." The answer of a typical consultant, which I was for a long time in my career. Well, because it always depends on a great many factors. Initially, we can never answer how much such an application will cost. De facto, the brutal truth is that until this application is proven, we are never able to answer with 100% certainty how much such an application will cost.

‍

Of course, if someone, some software house works in a fixed price approach, which we will talk about, well, then he will give you such a price how much he will wish for creating such an application.

‍

But this involves certain risks or certain compromises that you have to agree to. If someone is to give you a price guarantee on the software, they don't know much about it yet. To price an application, firstly we need to know as much as possible about it. We need to know what functionality it is supposed to have, what technical requirements it is supposed to meet, how we approach the design, and who will be the recipient of this application. Because based on who will be the recipient of this application, we will be able to break down a bit of how it will look like, how it will function, and what platform will be suitable for it. The choice of tools to build this platform is also of great importance, because with some tools you build faster, with others a little slower. If we build slower, it means that we need more time. This means that if we require more time, the final price will also be higher because we are paying for the time we spend building the solution.

‍

The final price of budgeting an application also depends on the approach of building this budget, that is, whether it will be a Fixed Price, it will be Time & Material, that is, payment for the number of hours burned.

‍

Generally speaking, we as a no-code agency act just like a traditional software house, that is, we take into account all aspects of building an application. We take into account that we have to have a project manager, that we have to do the design, that this application should be tested, etc. We discuss all these aspects later in the podcast. It's just that the stack differs with us. What are the resulting differences? We will also talk about that later in today's episode. So now I'd like to move on to what these pricing models are. If we approach app budgeting, then of course from our perspective it looks like we get some list of functionality that you want to include in your app. We know what we need to do with the design, and we know how much more or less we should spend on managing this project, testing this project, and so on. We take those functionalities and assume their complexity. Of course, assuming the complexity and each function is a bit of a guess. If we are to be honest, because we never know the complexity until we de facto sit down with you, we scout every single functionality.

‍

Well, but if you want to know right at the beginning of the ballpark, where you have really at the beginning just the very idea of the functionalities are not yet described, we don't have any details about the functionality.

‍

Well, we're also kind of guessing, just like you, and we have to guess how complex these functionalities will be. We sit down, price it out, and then you get a ballpark, the so-called preliminary estimate, which gives you some, gives you kind of idea of how much we think such an application will more or less cost. Of course, depending on how deep we will go into the given functionalities, whether we will add something during development. Whether we will, these functionalities that were initially very simple, according to you should be more complicated. We will add this time automatically, it is also known that this time will increase and behind it will also increase the valuation or the final cost of building such an application. So now let's talk a little bit about how the fixed-priced approach differs from the time and material fixed-price approach the solution provider assumes that he knows a lot about this application, that few things can theoretically surprise him and he is able to provide you with a price model just in this fixed price model, that is, a price that is already fixed with some kind of probably guarantee.

‍

He assumes you won't spend more and guarantees you that the application will cost that much.

‍

Unfortunately, this approach has a great many downsides. First of all, its downside is that it does not assume any flexibility. Your contract with the supplier for strict functionality, such as the supplier for the present understands all the changes you will want to make. There will be so-called “change requests” put on them. All change requests, of course, will also affect the final price of this application. It will be just such a false sense for you at the beginning that you know how much the application will cost. On the other hand, in our experience and in the experience of probably all software houses, this initial thought, this initial thinking about the application is completely different from this final product. It is completely different from how we imagine the applications. What is different is the stage of how we already visualize it, at least on a very preliminary mockup, and what is different is the product that we start clicking on. You will see a lot of things in this project, in this application, you will simply want to change. Because you will see that there are many things you are not able to think about and many things you are not able to predict at the very initial stage.

‍

That's why this model, according to us fixed price and according to probably all software houses, is just very dangerous. It causes that at the development stage, instead of focusing on the development itself, on introducing functionalities that really matter, we focus a lot on the bureaucracy itself, on introducing just these change requests, confirming them, scoping them, pricing them, and so on. Because every request not only has to be somehow scope-ed, that is, it has to be somehow specified what exactly is to be done. There has to be some kind of framework of what we are going to do, well, because they have to be somehow priced. That is, the supplier has to say OK, this change request, we see this feature that you want to introduce according to us, it will cost this much, well you have to confirm it. So it slows down the de facto process and doesn't give you the flexibility that de facto in software development should be taken very much into account. And that's where the other model we're going to talk about comes in and the Time & Material model, which is de facto we have some scope.

‍

We know more or less what we want to build, we have some idea of how much more or less it might cost.

‍

We can also assume something to ourselves, that ok, we see some framework of what we want to build, but Time & Material is a typically hourly approach. That is, do we implement all the functionalities one at a time? Of course, some we are able to price more precisely, others less precisely. Such functionalities as eg. logging, and registration, well, these are rather repetitive processes, which we are able to price quite precisely, and determine how much they will cost, so here we can assume some more rigid framework. Well, such functionalities, which are strictly related to your application, and are a bit unique in other applications, are similar, but in each application, they look different and must be taken into account differently. Well, this is where we need this flexibility on your part. We, of course, also assume something, that it should cost more or less, that it should take more or less, But as you guys see this progression of building the app, you will see it start to function.

‍

You'll be able to click through it, you'll start coming up with new ideas or little tweaks that hey, I'd like to change this a little bit here, and here I'd like to make it work a little bit differently though.

‍

It's at this point that we don't mess around with all this bureaucracy and say OK, well let's price it, let's sit down to do it, let's calculate how much it's going to cost and now confirm it, but not here dear supplier you got it wrong and we'd like it a little differently though and we go through this whole process. We just say ok, fine, then we make the change, see if it suits you and we just act. Of course, on the other hand, this approach may seem very risky to you, that now you are the one who does not know how many de facto hours the provider of such a solution will spend, what will be behind it, what the final costs will be for this application. On the other hand, this is not quite true, because, as I said at the very beginning, we define a little bit of this framework. It is known that if you add a lot, you will change a lot, well, this time will also increase, it will also affect this final cost.

‍

However, as I said, if we define for ourselves this framework, most of the functionality we are able to price with pretty good precision. Well, then you can feel quite safe, because you also monitor the whole process of creating this application.

‍

You can see what these hours are burned for, as well as with the supplier very often you can make an agreement. Okay, Listen, let's make an agreement for those open hours, but please don't use more than, for example, 100, 160, 200, 300 hours per month, because that's simply the monthly budget we have and we want to stick to it. If you will already be, for example, at 50% of the implementation of the hours in a given month or 75%, let us know and we will take steps as to what should have more priority and what we want to focus on. So as you can see this Time Material approach has more flexibility gives security to two parties and does not slow down the application building process itself. And de facto these days we are mostly concerned with making this application development process, to be agile, to be flexible. So that we can respond on an ongoing basis to the requirements of the business environment, which is changing very dynamically. Okay, so let's now talk about what de facto affects this valuation, because valuation is, of course, affected by very many factors.

‍

As I mentioned a little bit at the beginning, of course, the list of functionalities, how many functionalities we will want to introduce into the application.

‍

This has the biggest impact on our valuation, well, because we have to take them all into account, the more functionalities, well, you know that we need more time for this implementation, but the valuation is also affected by, for example, how we want to approach the design, whether it should be a simple design, because we are starting with an MVP and it just has to be clean and clear. Are we any company that already has some sort of guideline on how the apps should look? Are we a company that wants to have such a sophisticated pixel-perfect design, in which there will be data, many water features, many fountains, which will make a big wow in users, well, it is known that then we will also have to spend simply more time on the design of such an application, so that designers prepare the application, so that there will be this wow effect. On the other hand, the more sophisticated the design, the more time we need for the development of such an application.

‍

Another thing that affects the pricing is the multitude of tools or platforms that are involved in the preparation of this application. Of course, if we build the solution only on one no-code platform, it is known that then this complexity is much lower than if we would like to consider integrating several platforms into one tool, because, for example.

‍

will be such a technological requirement, it has a very big impact. Another thing, of course, is the complexity, also the functionalities that we have listed, that you have provided us, well, because it is known that some functionalities are simpler, others are more difficult. If there are going to be a lot of functionalities, which are also not entirely clear to you, you don't know what the final result is supposed to be what it is supposed to be. What de facto this functionality is supposed to realize. You do not know how to approach it, you do not know how it should be implemented. This is where, for example, we should include workshops, where we work it out together, where we figure out how exactly it should work to meet your needs. The amount of integration with external platforms, for example, on the platform should be integrated payments and you want to use Przelewy24 and you want to use Stripe? Take advantage of the recently very fashionable and artificial intelligence. The more such integrations there will be on the platform, the more documentation the provider will have to read to get familiar with them in order to implement them into your platform.

‍

The more integrations he will have to implement, integrate, handle and implement into that platform, which of course also adds time.

‍

On the other hand, it is known that such solutions as Stripe, transfers or all those most popular solutions that you will want to use, suppliers are also already familiar with. So if the supplier has used such integrations before, they have already implemented them somewhere. It's always worth asking about this to find out if your supplier has experience with a particular integration. He is the one who already knows how it works. He knows how to implement it. He knows what surprises might await him there. So it will also then potentially cost less. He'll be able to give you the supplier's answer that ok, it's going to cost that much, and he'll be able to give you just the necessary budget. We've already talked about what affects pricing, what models we have for pricing or collaboration between the supplier and you as a customer, what application budgeting is all about. So I would now like to talk a little bit about what is de facto mostly priced, what we price. Of course, I am not responsible for other software houses.

‍

I think it looks similar there. Because as I mentioned before, we operate very similarly. I mean we even operate identically to traditional software houses we just have a non-traditional technology stack, so what de facto we include in the

‍

pricing. We always take workshops into account. Because if we have an agile approach to application development, meaning that we recognize that we don't know something, we also don't know what we don't know, we know that we will definitely have to question you. We're going to have to talk together about what you want the functionalities to look like, so that we have an understanding of how they're going to potentially work, what functions they're going to perform, what goals they're going to achieve through those functions. So for this, we always include some time necessary for the workshop. Of course, we price and determine this workshop time depending on how big a platform we are going to build. It is known that the smaller the platform, the fewer work shops, the larger the platform, the more potential workshops. With Workshops, of course, we also price the time required for the weekly meetings where we present the results of our work to you. We share it, talk about what should be a priority in the coming week, how it should look, and so on and so forth.

‍

About running projects how exactly the cooperation with the software house looks like, we will also be preparing another episode in our podcast, so you will be able to hear about how exactly this cooperation goes.

‍

The next thing we price, which we always take into account, which is also very important, is the heart of the application. It's the preparation of the whole environment, the application and the application architecture. Every application has a slightly different architecture, a different database structure, a different environment. All these things have to be properly prepared, because on them depends how your application will ultimately function, whether it will have the right performance, whether it will properly execute your objectives. Whether it will have the right data at its disposal which, for example, in the future you will want to pull for yourself from this platform, these are the kinds of elements that we need to include in the pricing, because this is the heart of the application. So the time to prepare all this is also included in the valuation, it is listed accordingly in such a valuation. The next thing we take into account is the preparation of designs, UX, UI, all that is related to how our application will look and a little bit how it will function, how your users will simply feel in it.

‍

This is where they sit down. On top of that, our designers, they talk to you, prepare a moodboard, gather information from you about how you want the app to look, what you like, what you don't like.

‍

Taking into account all this information that they are collecting from you about what it is like to work with a designer in an application, what is important to take into account, we will also be preparing such an episode and based on this we will determine the time complexity. How much time we will need to prepare just these designs. The next thing, of course, is development, that is, how much time we will need for particular functionalities. What more or less fork do we assume for each individual functionality that it will take us? The more information we get from you about each individual functionality, the more precisely we are able to price it. Sometimes there will be large spreads even at the level of 100-200%. If we don't know something and something seems very complex. Sometimes it will be spreads at the level of a few percent. If the functionality will be very simple and should rather not surprise us with anything special. The next thing we include in the pricing is QA, or Quality Assurance. Every application that we prepare, that we want to hand over to you, that is going to collide with your customers or with your users, should, in our opinion, be properly tested.

‍

Every time we develop an application, it is developed,

‍

Before it gets into your hands for your testing it is properly tested by our Quality Assurance Engineers, or simply testers, by the processes we have internally. Companies put in place to ensure that the application is of the highest possible quality and free from a large number of errors. That is, we always try to deliver a product to you that you believe will be a product that is already finished, tested, and of course you will still be able to find some minor bugs in it, because to this day even companies like Facebook and Google have a "Report a Bug" button, because bugs always happen. As we introduce more new features. We won't predict everything, we can never predict everything and somewhere some bugs may happen. On the other hand, we test the application as intensively as possible, so that you get a product that will already meet your strict requirements. The next thing we also include in the pricing is this project management, that is, we will chase you around a bit, we will collect information from you, we will require you to answer many questions, because there are many things we don't know and we don't want to guess.

‍

This is your application.

‍

You are the ones who are supposed to be satisfied with it at the end of the day. So our developers during development or designers will have a lot of questions for you. A lot of things, like the privacy policy, like access to accounts, to certain environments or to information, or those kinds of things you will have to provide us with, in order for you to provide it to us you have to know about it. And here this is taken care of by our project manager, who collects all this information with each other, with each other. He is such an intermediary between us and you, and makes sure that the whole process runs smoothly, without interference, and that this exchange of information is very efficient. This does not mean, of course, that we are somehow playing with a deaf phone and you do not have access to our developers, to our testers or to our designers. That's why we have those meetings we mentioned to ourselves earlier, so that you can always talk to the whole team, and it's to the team that we pass on all this information as well.

‍

Whereas this management allows us to streamline the process and make it just smooth. Okay, so why if we take into account all these things that a traditional software house also takes into account, why is it cheaper de facto in the no-code approach.

‍

You have to take into account that, of course, such processes as workshop, preparation of architecture, design or application testing or project management, these things we are not able to accelerate relative to a traditional software house. Things look exactly the same there. The conversations with you in the sheds look the same as in the traditional approach, we can't get around that. Designs look the same as in the traditional approach. Here the procedure is the same as in any software house or in any agency that prepares design, in any UX / UI agency. Testing the application. To test the application, walk through it also we need the same amount of time as in the traditional approach. Of course, here we have a little less time in testing, we spend on testing individual elements, because we create from ready-made blocks, so they are already properly tested, have a high enough quality, so here we save this time. Well, and of course we save most time on the development itself, because if we create just from these predefined blocks, we add possibly 10%, 20% custom code, then here you will see these significant differences in pricing.

‍

Here you will see these significant differences, in the time we need, that we need to devote to create certain functionalities.

‍

And it is here that you have to look for these differences precisely in pricing. Well, and de facto the last point I still wanted to discuss today is what the final cost of the application depends on. As we have already talked a little about it, of course, it very often depends on your approach. The more things you want to change during development or during design, the more things we will have to implement, so the more time we will spend on this application. If you will want to add more new things during the first iteration, the more time this first iteration will take. Any changes that you will want to make, of course, have a significant impact on what the final cost of this application will be. Changes always have the biggest impact simply on how much such an app will cost in the end. The simpler the design, the less time we need to create it or come up with it. Of course, it happens very often that you already have a design prepared on your side, and this is also ok, because then you know that such a design is simply not included in the pricing.

‍

If we get from you a view of all the screens or screens that also allow us to design or the developer to say ok, this screen will also be very similar to the one here will change, possibly the displayed data on this screen, then it is known that then we can let go of this design and just follow the guideline provided by you.

‍

Subsequent iterations, feedback from users. If you will also want to respond to it right away, these are also the changes we need to make to the app. Also, your approach will affect the final price of this application a bit, because the easier it is for us to get along, the more efficiently we get responses from you, the less time we will also spend waiting or keeping an eye on you, reminding you of these responses, which de facto can affect the whole process, the whole project and how much time the project manager has to spend. Over getting all the information together into a so-called pile, putting it together and telling the developers do you hey, do we need this and that? Is the less time we need to spend on these kinds of issues, the less time we just spend. How much time we will spend on the weekly discussions, how well prepared you will be for the work shops where we will discuss functionality will also have a significant impact on this final cost of the application, because if you come unprepared to the workshops, you will come unprepared to our weekly meetings, well we will have to drone on about this topic a lot.

‍

You will be spending time thinking about it, which de facto just at the very end of the day prolongs the process. Look, I think I've given you such a basic understanding of what application budgeting looks like. We've gone over de facto what we need to know in order to price. We're going to do a little summary now. We need to know as much as possible about your application. The more details you have, the more detailed you have all the functionalities described, the better for you, the better for us, because based on this we are able to determine and price all the functionalities. Of course, it will not always be possible to specify precisely, but the more we know, the more precisely we are able to specify it. We know how the fixed price approach differs from the time and material approach, that is the flexible approach, that is the Agile approach. What disadvantages it has, what advantages each of these approaches has. Of course, there is a lot of information on the Internet on this subject.

‍

How exactly and what exactly these models differ. Each software house also approaches budgeting a little differently, has some of its models of cooperation.

‍

So here I told you in general how it looks like. Well, but here it also always comes out simply in cooperation with the software house in question, where we talked a little bit about what affects this valuation, that it is affected by the multiplicity of tools, the platform, the complexity of functionality, the list of these functionalities. The more the more complex. The number of integrations with external meeting platforms, Workshops, how prepared you are. All these things affect that pricing. We also told each other about what affects this valuation and what is included in this valuation. Workshops, meetings. Design, Development, Quality Assurance, which is testing on the platform and quality assurance and management of this project. So I think we've been able to tell today what comprehensive budgeting looks like. Of course, this is the so-called overview. This is something to give you any guidance or general knowledge of what budgeting looks like. Because you also have to be aware at the end of today's episode that each software house approaches each application a little bit individually.

‍

Because first of all, it's dealing with a slightly different customer, a slightly different product.

‍

Every client wants to work together differently or on different terms, as they also have some of their own requirements, so here these issues are always discussed individually as well. I hope that today's episode was interesting for you, it gave you some hints on how the budgeting of applications looks like, what is taken into account and I hope to hear you in the next episode of our podcast. OK, thanks, until we hear from you.

‍