If you listen to the marketing folks for some of the most popular no-code platforms, you might think that you can build a major platform for $100.
While it is true that you can easily build a lot of things without writing code, software development’s Achilles heel has rarely been about the code itself. Instead, most issues with projects stem from poor planning, poor scoping and so on.
And, in fact, at least 50% of a project’s cost has little to do with the actual initial code and everything to do with what came before and after the initial coding marathon.
So, when it comes to no-code projects, the risk is less about the ‘no-code’ aspect of the project and more about the same things that affect development projects of all kinds.
Thus, when planning and executing a ‘no-code’ project you still need to focus on the “planning” and “execution” parts just as much as focus on the “building” or “no-code” parts.
In other words, to run a good no-code project you still need the following:
- Functional specifications
- Technical architecture
- Testing plans – alpha & beta
- Deployment plans
- Loading and capacity testing, planning and/or forecasting
- Upgrade architecture
- And more.
With no-code tools you might spend less or more time in these areas compared to using other tools. For large scale projects or projects that you expect will serve a large number of users, the chances are you’d spend the same amount of time. For MVPs (“minimum viable product”), you’ll likely spend less time.
If you’re new to software development then you might not know how to use each of the items listed above. Below is a relatively short explanation that should help!
Functional Specifications
This is the part where you decide what you will build. You need enough information here that will give your developers a really good idea on what the final product will look like. Effectively, this document makes the “definition of success” quite clear.
Some items that you include in this phase are:
- Define the problem you’re attempting to solve.
- Audience definitions – who’s going to use the product? Who’s going to manage them. User role definitions.
- Screen mock-ups or wireframes including transitions between the screens. You can use your ‘no-code’ tool to build this out if needed without any logic or database elements.
- Interviews with stake holders if building a product for internal company use.
- interviews with end-users if building a product for end users.
- Define expected load (number of users per hour, number of transactions per hour etc.)
- Break down the end goal into phases so developers know what’s critical vs what can be done later.
This is where a lot of no-code projects skimp on time. And it causes a TON of issues on the back-end of things because the product has to be constantly rearchitected. Just a little more time in this phase can save you tons of time and dollars later.
On average you can spend anywhere between three days and multiple weeks on this.
Need help with developing your functional specs? We can help!
Technical Architecture
This is where your developers will take the functional specifications and create a basic architecture designed to meet the defined functions. In particular, this is where you can do a lot to solve any future scaling issues such as defining data structures that do not bog-down your chosen no-code tool(s).
As with the functional specifications, spending a little more time here can pay off in spades later.
It is not expected that the output from this will be perfect. But at least the major issues will be thought about upfront.
As with the functional specifications, you can expect to spend anywhere between three days and multiple weeks on this.
Testing Plans
Generally, you want to start to create some idea of how you’re going to test this thing. I’m not talking about unit testing where you write code to test your individual code component. I’m talking about end-user/end-product testing in real-world environments.
Depending on the development methodology you use (most use “agile”), you’ll define what needs to be tested, who is responsible for the testing, what kind of data will be used for testing and more.
Generally, for each functional phase you can expect to need 2 – 3 beta cycles.
At some point you will also need to plan for load testing – to make sure that your app isn’t overwhelmed by an unexpected volume of users!
This phase can be done simultaneously with actual software development but it should never be done after the fact.
Upgrade Architecture
So, how many times do you just get one version of an app and that’s all you need? Hint: Exactly zero times.
So, from the get-go, you need to build in plans for upgrading. And make sure that the code that is being written always addresses this issue.
It’s usually a part of the technical specs phase but it’s important enough that we always break it out into its own section.
Deployment Plans
How are you going to move things between development, testing and production? Some no-code tools provide a basic architecture but generally, even that’s not enough without you creating some processes, procedures and code of your own.
Writing the “code”
No-code tools primarily use a visual environment for building things. With some “real-code” sprinkled in as necessary.
But on large projects you’ll likely find yourself writing a lot of “real code” to fill in the no-code tools’ gaps.
Regardless, many shops favor writing the code in “sprints” of 1 – 3 weeks followed by testing and feedback.
Regardless of how it’s approached, all the planning elements described above can be broken down into assigned tasks to one or more developers, testing & QA analysts and deployment specialists.
If the functional and technical documentation were done properly, your developers will know if they’ve hit the target.
And if the functional requirements change? That’s ok, because then at least everyone will know WHAT changed and why. Not having a base-line from which everyone started means not having a context from which to evaluate changes. And that just spells trouble.
Wrap Up
The bottom line is this – the more work you put in up-front, the better off the final product will be. If you or your client do not want to pay for it now then they’ll pay for it later at quadruple the cost. Even in a no-code or low-code environment, lack of planning means cost overruns and/or failed projects.