I'd like to welcome you to the next episode of our Just No Code podcast.
The Application Development Process No-Code Low-Code
In this episode, we'll talk about what the application development process looks like, how you can prepare for it and what de facto exactly it looks like on our side. So without further ado, I invite you to the next episode.
Requirements for the Client
To start, I'd like to tell you what we... as a Software Development Company that will be creating your application, actually need from you. Because it's not like you just come to us with requirements written on a blank A4 sheet, say... price this for us, we price it, and then we start making the application. It totally doesn't work like that.
Preparing for the Process
At this point, we would just be code monkeys or something, and not actually helping you achieve success or build an application that will just work. Very often, it's also the case that you as our clients don't really know... what's needed, how the process looks, because you simply don't have the technical competencies on your side.
Technical and Business Competencies
You know what you need from a business perspective, you know what effect you want to achieve and why you want to do it, but you don't know whether solution A or B is better, technology X or Y. And that's exactly what we are here for... to help you.
Project Estimation No Code Low Code
We are also here to tell you how much time it might actually take, how much it might, and I emphasize twice, approximately cost, because we can never predict everything that will happen in the application, how exactly it will function, look, and so on. You don't either.
Client Engagement
Unless we're talking about, you know, a really tiny, tiny... teeny, tiny application, but that's not the point and not how it actually looks. So what do we actually need? Well, at the beginning, we need to get a list of functionalities from you, what you want to achieve, what the effect should be, what purpose the application should actually serve.
The Role of Stakeholders
Next, we definitely need stakeholders, meaning a person designated on your side who will be, let's say, the final say. This doesn't mean that there can't be a team on your side. There probably should be a team on your side, probably must also be, so that we can discuss what we're building, how it should look, etc., but there must be one decision-maker.
Knowledge and Engagement
The next thing we'll need from you is knowledge. Of course, we will want to acquire this knowledge from you in several different ways. I'll talk a bit more about this later. However, thanks to this knowledge, we will know what we actually have to build. Remember, we know our industry, you know yours. We know how to build an application. You know why you want to build the application and what should be valuable in it.
And this kind of focuses into one big, let's say, comprehensive element, all these elements are connected in what we need from you. And how to prepare for this? Well, of course, it's worth it for you to have a good discussion about what you want to build, so it's not just, you know, only a concept I'd like x, because that's way too little, you know.
Definition of User Management Functionality
Based on wanting a user management feature, we can tell you that the development of this will take a week or 10 weeks, because user management can mean that you want a list of users where you can add more. And user management can mean that you want to be able to block, edit, delete, add, view users, maybe you want to add more things to them, be able to manage their documents, check reports about these users, etc. So, if you define a functionality, we need to have some minimal description to simply know what it means.
Preparation and Verification of Needs
So, to prepare, you really need to reevaluate on your side, discuss as a team what you need and here one very important note we must separate "I feel like", "it seems to me", "I would like" from "what I must have". We have probably already discussed and will definitely be discussing more that initially, let's build something that provides only and exclusively mega value to the users.
MVP and Functional Minimalism
This means that of course, we can have a lot of functionalities in our application, an infinitely long list, but we have to ask ourselves if we really need those functionalities at the beginning. We always encourage our clients to build a minimal solution that minimally meets its value, delivers that value, minimally fulfills its functionality. This way, you simply spend much less, spend much less time on building the first version of the product, to simply validate that product when you gain traction, see that it makes sense, and you like it.
The Role of the Project Manager
One of the most important people is the project manager. The project manager is someone who, a bit jokingly, will kick both us and you in the butt, when we don't deliver something to you or when you don't deliver something to us. The project manager is also the person who will be collecting requirements, documentation from you, chasing you if we don't get answers from you, asking you questions, talking to you.
The Project Manager simply also oversees the entire process of creation, collecting information, to make the process go smoothly, quickly, so that the exchange of information between us and you is effective, precise, and clear to everyone what is actually happening at any given moment and what we are actually doing. A very crucial role that actually oversees many things.
The Role of Designers
The next people are, of course, designers, individuals who will work on how our solution should actually look. We usually have some requirements about how our solution, our application should look and function. These are also people who can say, "hey, this button here works poorly, better to place it here." Of course, we're getting into UX, UI here, splitting this into these two roles doesn't matter at this stage. The point is that we're able to tell you, suggest how something should look, or that it should look or function differently. Deep UX analyses are necessary, we're also able to do that, or use the competencies of third-party firms that specialize in this, but that's obviously a separate topic. Thus, such a company or such people are simply woven into the whole process of creating those first frames, those first pictures, those first screens, of what our application will look like.
The Role of No-Code Developers
Then we have the devs. Devs, of course, are the people who will create the solution. They will translate your knowledge collected by our PM and designs provided by our designers into what will be the live product, something clickable. They will be pondering how the database structure should look, how workflows should flow, how everything will function in sequence, they will be delivering that. And of course, like designers, they will participate in our meetings to talk to you, to ask you questions, to inquire about edge-cases, to suggest certain solutions because, as I said before, the solution belongs to you. We only suggest, we advise, we implement, but you are the owners, and we always need to have the final say from you. Of course, where you are not able to make that decision, such responsibility falls on us, we will also make that decision.
The Role of QA Engineers
And last but not least, QA engineers, or testers. These are people manually or automating tests depending on how large a solution we are dealing with, whether it's already a maintenance phase, or it's the phase of building the first version of the application, testers are involved of course. Testers, whose task is to ensure that the application is free of defects. And here one very important note, the application is never 100% free of defects. To this day, Facebook, Twitter, Google have a "Report a Bug" button, because we can't always think of all the edge-cases, those extreme use cases of our applications, where something just might not work quite right. And that's what our testers are for, of course, to try to catch such things, to make sure there are no such obvious errors or mishaps in the operation of the application. But this, of course, does not exempt you from acceptance testing.
And you must remember that. Our testers are responsible for Quality Assurance. QA is short for Quality Assurance, which means ensuring that the product stands at an appropriately high quality. It's understood, a bug in any software can sometimes occur. Extreme cases as well, but we attest that our software stands at an appropriately high quality, meets appropriate performance, meets the appropriate indicators that it is usable, and the user should be able to go through their process every time. However, as I said, this does not exempt you from acceptance tests, because acceptance tests are such that we give the application to you to click through, to see how it actually works and tell us if everything is as you imagined.
The Application Creation Process
And how the process of creating the application actually looks. We know who is involved in this process, how to prepare for it, what the project estimation looks like. So what happens when we say to each other, OK, we start, we begin to implement this project. We always start with a five-step workshop. A five-step workshop that involves us meeting together, of course, we already know roughly what you want to build, but we want to clarify certain information. As with every platform, every application we build, some things are clearer to us, other things are less clear.
And it's about the less clear that we want to ask, to see, to write down how it will function. Maybe build some first user paths, just to see how the whole process will look, confront it with you, ask, so we can be sure that we are on the same page. To think about the solution in the same way, to avoid any misunderstandings, to be sure that what we will be building will meet your needs. Once we have these workshops, because again, this is a very important note, workshops do not consist of us writing down every little thing, every tiny detail, because we would have to spend probably half a year at these workshops, and still, we would know nothing, because many things would have changed in the meantime. Workshops are meant to clarify things to the extent that we roughly know what we have to build.
The Design Phase
We start drawing these things, which is very important, because we still do not start building them. Initially, we start drawing them, and we start drawing them because one thing is our imagination, another thing is things we see for the first time, and yet another thing is things we touch for the first time. Therefore, first, we talk about imaginations, about theory, then we translate this theory into some picture. And here the designers lean over it. They build some first, not all again, because that again would be a waste of time, but they build the first pictures of your application, how it can look, what the graphic identification will be like, how it will look. We confront this with you, for you to see, touch, then again there are some comments about how it might look, how it might function.
The Development Phase No code Low Code
And only when we have approved these first workshops, the first things, how they will look, then we actually move on to development. And here we develop our application when the first module, the first functionality is built, we give it to you to click through just so you can click through and convince yourself whether the process we built actually corresponds to what you imagined. And if it corresponds to what you imagined, then if reality is consistent with your imaginations.
The Quality Control and Acceptance Process
We give it to you to click through as quickly as possible, so you can report corrections at a very early stage, so we again do not prolong or return to things that we have long closed on our side. So that we do not return to them, do not dig them up but build module by module, just like LEGO steps. At the end, of course, we do such closing tests, to hand over the application to you for acceptance tests, and when the application has passed the acceptance tests, we can go live with our application.
Continuous Development Process
Of course, this does not mean that this is the end of all development because if we want to continue to develop the application, it has gone live, its first version has been released, meeting, collecting requirements from you, gathering knowledge about what is to be created, how it should look, and adding these next things, or even creating documentation. Because you also have to remember that at each of these stages, some documentation is also created regarding designs, test cases, how we built certain functionalities, or specific algorithms, if such a requirement exists.
Transparency and Collaboration LCNC
At Have No Code, we operate in such a way that you have access to our task board, our time, our documentation at every stage because you are, as I've already said, a very important part of this process. And we together form one team. It's not like we stand in opposition to you and are your subcontractors. No. We focus on being one team, acting very transparently, communicating everything, working together on everything. You have your boards in our system, where you can report various things, modifications. We exchange documentation, knowledge, opinions in order to build an application that will be your application, built together with us, by our hands. Not that we are the ordering party, you are the ordering party, we are the executing party – of course, from a formal point of view, yes, but that's not how we want to operate, that's not how we want it to look.
Our process aims to be simply transparent, so that you know at every stage how your application is being created, what exactly is happening, at what stage we are, where we might have difficulties, and where, for example, we managed to accelerate. So as you see, I hope that this entire process is clear to you. How it is created, what is necessary, who participates in it, and how to simply prepare for it.
That's all from me today. Thank you very much. See you in the next episode. Goodbye!
