NEXPLORER or a steep learning curve

The project

The idea behind NEXPLORER seemed simple, yet innovative. Create your own Swiss cross by answering a set of questions. The defined questions determine your core values. Each corner of the Swiss cross represents one of those values. If a value is not as important to you, it moves towards the centre, or outwards, the more important it is.

As soon as you save those core values and your answers, anonymously of course, you get your very own Swiss cross. With all saved answers, a “new Swiss cross” can be created, representing Switzerland’s citizens.

We created a prototype for this questionnaire in only two weeks.

The greenfield

The client gave us free rein to choose the technology we saw best suited. Given the time frame, though, it made sense to choose something lightweight and fast. We chose Nuxt and Tailwind for the frontend, as they allow reusing components and require only a little configuration for the basic things.

And why create a backend at all? There are tools to create a REST API from a Google sheet. Added bonus: Free administration interface, no extra access control, no extra server. Nice!

All of a sudden, boundaries!

To be honest, using a Google sheet as an API and only building some frontend seemed too good to be true anyway. There were several problems. First, the API would automatically be public. No backend to conceal the underlying data structure. The tool allowed DELETE calls on every sheet, too. That’s a No-go as all data could be gone within seconds. The single largest problem: It didn't work. Such a project is prone to API changes by Google. Nevertheless, we had a backup plan: from another project the team already knew MongoDB and how to build simple APIs with Node.

Nope, not really. After we had a first look at the target server, we realized there was a crucial thing missing: Node.

Adapt and overcome

There are several approaches: Require full-admin access and just install whatever you need (who's going to maintain that, though?), installing it via proxy (there's nodejs-installer) or you have to live with the given slightly smaller greenfield and adapt to it.

Whilst working on a project during my studies, I heard a lot of good things about and got to try out Slim. The problem of the database still existed though. If Node is missing, so might be MongoDB, and it indeed was.

Another school project I thought about was using SQLite. Small database files, absolutely portable, doesn't need any extra tools, a backup is as simple as copying a file.

We weren’t really familiar with either of them, but took it as an opportunity to learn something new. In the beginning it felt a little awkward. Searching the internet for hints and solutions every 10 minutes under time pressure didn't seem very effective, but in the end, it worked out. We could have always gone to a better known framework, such as Symfony.

The risk of learning

You might lose valuable time when trying something new. With a tight budget, this might seem like a waste of money. However, investing time and money on innovation and building up expertise is a winning opportunity. You can't really eliminate all risks every time, except for when you don't take the opportunity at all. The benefits of succeeding can still be tremendous. What can you do to mitigate risks when learning something new?

1. Don't switch too often

In case you can't work with your newly discovered gem, don't just switch to another one. In such cases, switching to something you already know saves you time. Instead of focusing on innovation, shift your focus back to getting the project done. In any case, you have at least learned the drawbacks of this new technology and found a case where not to use it.

2. Have a plan B

If your newly chosen framework just doesn't cut it, have another one ready to switch to at any point. Chances are, you've already established the necessary concepts in your mind to only repeat or, even better, copy/paste and amend just a little of what you've done already.

3. Innovate - but don't overdo it

It doesn't always have to be the complete unknown. Know a framework you've already built some small Hello-World-like things with before and want to do something more advanced with? Choose that over completely unknown technologies, especially if budgets are tight and you assess the risk of timeloss as high.

4. Do one step at a time

Don't switch your entire stack at once. Maybe use another backend framework and keep doing what you're good at in the frontend. Try another CSS framework that looks promising, but keep your frontend boilerplate and the backend stack the same. Try document-oriented or graph-oriented databases instead of relational ones. You will learn a lot and build a lot of confidence in the newly chosen technology already, while maintaining the pace that your expertise gives you everywhere else. If you feel uncomfortable learning entirely new technologies, keep some parts that you're good at, so the entire project doesn't feel like entirely uncharted territory. Once you're comfortable with the new technology, try to change another part of the stack the next time.

Takeaway thoughts

Even when building something really fast, don't be afraid to try new things. Especially in moments of high pace. You will learn the most by stepping out of your comfort zone. This two-week project taught me to take greenfield opportunities, trying new technologies even when under pressure – the benefits might be huge. Most of the time you can go back to the old technologies when you realize you went down the wrong path.

My summary: Never stop learning and take learning opportunities wherever possible, but be aware of the risks and know how to mitigate them.

What is a tech stack you always wanted to try?

Further links

Read Alain Frapollis’s blog post about designing: NEXPLORER: Designing questionnaires that don’t suck