Before you scroll to the bottom of the page to jot down how “it’s never that clear-cut on a normal project”, let me assure you, we’ve done stuff the wrong way on many projects. The very reason for writing this article, is seeing how ignoring the rules helped us build amazing products.

One example is the project I hinted at at the start of this article. We were building an employee mobile app for YayHappyFunTimesCorp (before you start googling to see what they’re about — it’s not their real name). It was at MVP stage and based on our user testing we had picked a feature that would benefit the employees the most. Next step: running a pilot in a couple of shops to validate it with real users.

The functionality we were looking at was heavily dependent on the data in YayHappyFunTimesCorp’s internal, legacy systems. In situations like this, we would aim at integrating through an API-based system-to-system communication. Unfortunately, not only were those legacy systems devoid of APIs, they were also extremely internal, to the point of not having any access to the Internet. Of course it’s not the end of the world — firewalls can be opened and APIs can be built — but unvalidated assumptions and impatient employees are waiting.

Once again, we had to take a step back. Find a “quick and dirty” solution, that allowed us to release the pilot quickly. The one we found took “quick” to the extreme — it didn’t require any code. To move data between systems, we printed it out and manually keyed it in. Manual weekly sync. We might have wasted four hours a week for six weeks on tapping on our keyboards, but we validated if we were building what users want (surprise, surprise, yes we were).

Similarly with the finger project, we made sure to not lock ourselves out from refining the solution in the future. Not only that, we actually started working on the improvements straightaway. Over a few months, we moved from print-outs to manually uploaded CSV files, then to automatic CSV imports, to then reach our final stop — API communication. All the while we continued releasing to more people, learning about how our feature was being used and what was required. The experience that we gained meant that the API structure we used in the end was very different to the one we would’ve suggested at the start of the project (This whole story was also the background to an article that our awesome developer Kat wrote about using AWS Lambda).

We started with a completely unscalable solution, which enabled us to validate the need. We then evolved it, step by step, to make it support more and more users. On the way, we learned not only about our users, but also discovered what the technology requirements were. We can only speculate what the outcome of the project would have been if we hadn’t let ourselves find a “quick and dirty” solution.