Start with an idea

When it comes to rapid prototyping, you need to be clear about what you want. This becomes even more important if you’re working against a deadline.

A short deadline can feel like a lot of pressure to complete something — but it may just be the push you need to focus and actually produce something.

So start with an idea.

Note that it’s an idea — meaning that it’s a focused target.

When we brainstorm for ideas, we tend to come up with a lot of features. Then we fell obligated to implement them all.

You need to split your features into two different groups: core functionalities and enhancements. The difference between these two is that with core functionalities, your app won’t be able to perform its intended purpose properly without it. Your enhancements are things that can be chopped off and your app will continue to work without it.

Wireframe out your flows

If you’re not a designer, wireframing can feel like a tedious task. Or maybe you’re used to someone doing it for you. Whatever the case, here’s a chance to brush up on a skill.

The thing with wireframes and prototypes is that it doesn’t have to be pixel perfect. You only have a limited amount of time to get things right so it’s best to spend it in the places you need it the most.

While you may be tempted to skip this part completely, knowing how your app works on a visual basis can give you an overview of your data needs.

When wireframing, focus on meta details like if you click on something — what happens?

Ask yourself, what’s happening with the data? When and where is it getting pulled and process?

You can move the visuals around later. What matters is that you understand how your app works — not just on a surface level but all the background things that make perform the way it does as well.

Decide on your stack

This is probably the fun part for many developers. Picking your tech of choice is like the ultimate field day — especially when you don’t have to try and convince other team members or the boss.

For most developers, we have our areas of expertise. Whatever they are, you need to consider the four different facets of launching a fully functional app:

• the frontend
• the backend
• the data source
• the infrastructure

For the front end, it usually boils down to HTML, CSS and some sort of JavaScript implementation if you’re creating a web-based application. These JavaScript implementations can be frameworks like Angular or libraries like React, Vue or even jQuery.

For the backend, you might not actually need one. When it comes to apps, your backend is is the thing that connects up your data source and returns the contents in a way that’s useful and easy to deal with for the front end. If backend is not your main focus or specialty for this prototype iteration, you can just use Firebase to mock your initial data and connect it up to your app for the live data changes. This, in turn, also covers your data source.

For the infrastructure, if you’re already using Firebase, then hosting your app is already sorted. Google comes with a free hosting tier that’s quite generous. If you’re deploying your app to the App Store or Play Store, you only need to worry about where your data and backend is going to sit.

Most cloud providers offer a free tier for you to play with. But be sure to keep an eye on the limits. Stuck instances can happen and balloon up a bill out of nowhere.

When it comes to prototyping up an app from scratch, mix your stack with things you know and things you don’t know — unless you’ve got the time to support it. This is to de-risk yourself from too much stress when things go wrong.

Pseudo out your code

If you’re new to a framework or language, pseudo-code can be a game-changer. This is because pseudo-code acts as your road map on what you’re supposed to code.

If you think about it, all code ends up doing the same thing — just written differently. It’s sort of like the difference between saying the same thing in French and English. The words might look and sound different but the general meaning is the same.

When you pseudo out your code, it also gives you clarity on what’s expected from the app. It lets you see from a bird’s eye view perspective on how everything connects up with each other. It also lets you see where the potential points of inefficiencies are.

When we’re skilled in a particular language, framework or library, we often skip this step and forget to do it for things we’re unfamiliar with.

Pseudo out your code, unload your mind and save yourself from trying to remember how and why everything is going to work.

Start with the big things

For some of us, we get sidetracked by the little things — like the way a particular box-shadow looks or fiddle around with formats.

Start off by getting the barebones version to work.

It’s easy to get sidetracked by trying to get your app perfect the first time around. But remember that you’re on a time limit. Keep to that time limit.

A trick I often use to get things moving for MVP sprints is to code in layers. You start off with the barebones working version and then slowly work your way up towards dressing up the front end.

If your end-to-end coding endeavors is like building a house, you’d want to do the proper groundwork and inspections before moving the next part of the build. It’s hard to do that if you’ve got a finished house interior that’s plastered on a shoddy build. Wallpaper can only hide certain cracks but can’t fix a leaky roof.

Deploy working version

When you have a working version on localhost — deploy.

Test it out in a live environment.

Apps tend to work super fast on your localhost because, well, it’s localhost. There are no latencies or download delays involved. Emulators can also only take you so far. But when it comes to putting your app into a live test environment, you can discover some rather interesting things about its behavior.

When you deploy a working version, it also gives you the opportunity to get feedback from potential testers.

The thing with non-coder feedback is that they’re looking at your app from a user perspective. They don’t know the ins and outs of how things are configured. This is your chance to observe, see where they go wrong and rather than stepping in the help your tester out, watch them suffer so you know when and where to save others from the same fate.

Don’t take these user experience blunders too personally. Unless you specialize in frontend development, there are certain patterns that you might not be aware of until your users complain directly to you.

Whatever happens, this is your chance to improve on your prototype.

But the point is, you have a working prototype now. It’s just a matter of refining it in the time that you’ve got left.

Final thoughts

The quicker you get to the end of this process, the more time you’ll have to add refinements, and maybe an enhancement or two that you cut out in your original iteration.

It may seem like a race to the end and perhaps it is. Real-life MVP sprints often happen in 1 to 2 weeks iterations. If you can finish your entire app in a week, then you have 3 potential improvement iterations to play with.

If you finish your app in the second week, then you’ve got an extra one or two cycles to make improvements.

Don’t spend the entire four weeks (plus a few extra days) trying to get your prototype to work because you might end up missing the deadline. Instead, aim for a just working state and iterate improvements on it.

It’s a much safer strategy in the long run — and you’ll definitely end up with an app of some sort.