Founder, Imua Studio
Cost estimation is imperfect in the early stages of the product planning process. Through requirements gathering, user research and with the use of tools to streamline communication you can keep your project (no-code or traditional software) on budget.
Hi there. My name is Eric Johnson and I'm the founder of Imua Studio. We're a design and development agency based in San Francisco.And we are really focused and excited around the use of low and no code tools for rapid development digital products.And in working with clients, one of the most common questions that we get in the early parts of the conversation is how much is this going to cost?And three thing about low and no code development is it means that you can usually build things faster and cheaper depending on the complexity of what you want to build.Now that doesn't change the fact that there's still a lot of uncertainty in the development process and it's our experience working with entrepreneurs or even seasoned business owners that you can come in with a general understanding as to what you want built and how the interface might be constructed, but usually there's a degree or yeah a wide kind of area that's unknown.And that is the I would say risk and nature of the product that really makes it hard to say, Hey, this is going to cost exactly this much.And you'll get better estimates from people that have done it a lot before. And as mentioned low and no-code development is really helping to streamline the process and help you focus on more of the experience design and less on some of the, I would say more behind the scenes infrastructure in terms of setting up a database or needing to install particular libraries in the code base that you get to really in a low code environment, just focus on, build the experience add the business logic and put it in front of users now that is easier said than done, and is why when we're having these conversations with clients, we typically we'll give them a wide range early on, and then over time as the actual requirements and the user experience has been really understood, then you can start to provide more detailed and finalize estimates around, Hey, this is how much time it'll take.And for a particular agency what it will take in terms of costs to build it and this visualization I, I got from practicing.So I have to give them credit to it to the creation of this, or at least finding really illustrates it well.And it's, it's not even at the project definition phase and create a detailed requirements that, that you can really have a, an accurate, like a w plus or minus maybe 20 or 50%, which is even even that can feel like a wide range.But it's, it's not even until you actually get into the, truly at the development that, you know, how long is it going to be.And so that's why you really need to go through this process of defining at a high level, what it is that you're building.You'll start to get some good estimates after that point, if what you're building is truly just based on perhaps a template and you're just modifying some of the language or the visuals but none of the functionality, okay.Maybe, maybe you can make some assumptions or cost or just duplicate something. And knowing that that the cost is gonna be there, but likely you're creating something new and yeah, you have certain requirements for how your application needs to function.And only through gathering those requirements and then getting to an actual design in the interface, can someone that's going to develop it start to break that down into its component parts and understand how all the pieces fit together.So this is just advocating for following a process like that. We use it variety of tools to help manage this process.And if you're not working with us, I just wanted to point you towards some resources that are really helpful. Even if you're not necessarily the, the designer that's going to use it, or the project manager that's going to keep, keep track of the backlog or the quality assurance testing, that's going to go through the process of testing the app having tools in place to streamline this process is going to help you avoid kind of that hidden cost of just inefficiencies in communication, which really is, in my opinion, a lot of what we're we're fighting against.There's a kind of nature of communicating with your user and understand what they want. Then there's communicating with a designer to convey that into requirements for an interface.And then there's communication between a designer and developer in terms of how the interface needs to perform, and then communication between the developer and a QA tester in terms of making sure that the application is functioning as as intended and yeah, as built.And especially if you're new to building products as a lot of no-code low-code enthusiast or adopters are you really need to have as many tools in place to help guide the process.So just calling out a few here Figma is our preferred design tool, and this is a great place for both creating a low fidelity wireframe, but also high fidelity design that a developer could use and really understand all of the screens and states that need to be built into the avatar.For this at minimum, if you don't have like a high-level scope document where are you managing a backlog having some kind of a task management tool or a tool for organizing your user stories is really essential.And so a great one is a sauna and this can help help you and a group of people. If you're building as a team stay organized and in sync on different aspects of the project.Finally this is often a maybe overlooked aspects of the development process, but it is almost a guarantee that there will be aspects of your application that require kind of fine tuning or fixing and a tool to help streamline that communication that we really enjoy it's called Buchard.And what it does is helps visually capture the aspects of the design or rather the development that it might be off or might not be implemented exactly as was designed or potentially even just overlooked entirely.And so a tool like this similar to a sauna can just add a little bit of structure to that feedback process.And so it can really help avoid this kind of final development phase and QA from exploding into a really costly do.So we hear the most studio. We use all these tools and we've actually built some automation and some integrations between them and have found it really to be a valuable way to accelerate development and help everyone stay in sync in the building process to keep projects on budget and on time.So if you have any questions about other ways to de-risk your product in the requirements gathering phase or in your design process we'd love to chat about it.There's a lot more that you can do to trim scope and really make sure that what you're building is the most efficient version.And so in the link below this post will include this Praxent article, which includes a lot of good resources and guidance around kind of the mindset to have when building a, a product, be it on no code or in traditional software.So I hope you find that helpful and thanks for watching.