How to Fail a Tech Startup: A Step-by-Step Guide – Part 2 of 3

Jun 13, 2024

This publication is the continuation of “How to Fail a Tech Startup: A Step-by-Step Guide – Part 1 of 3”. If you missed Part 1, you can ​catch up here​.

Stage III – Mockups and Business Problem

Once I had the business plan and a “clear” idea of what I was doing, I moved to the next step — design and mockups.

For those who don’t know, “mockups” is a term from software development that refers to building a visual prototype showing how your product would look and how it will function.

I must confess that it took me a lot of time. Back then, I was employed at a company with a full-time job, so I had to work after work and during weekends.

So, as I explained earlier, I aimed to develop a “rocket,” a product of high complexity that would satisfy “all” customer needs. As a consequence, visualising the product was quite a complex task. There were many screens, buttons, relationships between them, interactions, etc. If I remember correctly, it took me about 4 months to finalise the mockups.

I vividly remember sitting at my desk at home, staring at the screen, and realising that the complexity of Peoplegogo vastly exceeded my initial expectations and that I needed to do something about it. I decided to develop only part of the product — around one third of it — and to develop the rest later if and when it started generating income.

Now, from my current position and with the knowledge I have, I would say that users may not need all the services you have in mind. In fact, they need a solution to one specific problem. Everything else is just a bonus.

If you want to open an online store to offer a vast variety of shoes, that is the real problem you are solving for the user. All other services gravitating around this one are most likely unnecessary at the beginning.

The situation is similar with Peoplegogo. The real problem I sought to address was providing users with a tool to publish socially-oriented campaigns. This would allow them to attract tangible and intangible assets to promote a social cause. Everything else was superfluous.

In fact, simplifying your initial business model will lead you to a point where you can test your business idea on the market with minimal effort. In my case, for example, I could build a simple website (based on WordPress) and test the idea to see if people were interested in it and only then to build a complex product with a pile of features on top.

Stage IV – Architecture and Technologies

Once I was ready with the mockups, I had to move on to the next step, which is choosing the technologies I am going to use to build the website and the platform.

I wanted to make it perfect, and by “perfect,” I mean the following: I had a thought in mind — choose technologies that are scalable, easy to learn, and whose code is easy to comprehend.

I decided to adopt this approach because I didn’t want to build a system that would need to be rewritten later if more users began to use it and I needed to scale it. Additionally, I wanted the code to be easily understandable in case a new developer joins the team, allowing them to start writing new code and implementing new features as soon as possible.

Let me give you an example. Back then, Angular was a very popular framework for building the front end — the visual part we all see every day when opening a website. Unfortunately, after a short consultation with an Angular developer – I understood that this technology has downsides. First, the learning curve is steep, which means that if you hire a developer today, and he starts to learn Angular, he will only be productive a few months later. Consequently, the business is losing money to teach someone a technology that may no longer be in use next year. This leads me to the second point: Google was releasing new versions of Angular quite often, and each subsequent version had major differences compared to the previous ones.

So, I decided to opt for a much simpler solution that anyone with basic knowledge of JavaScript can easily understand (think of JavaScript as a programming language used by every website you visit on the Internet, one that every web developer is familiar with).

Regarding the database, I decided to use MySQL (for those who are not familiar with this term — imagine it as a bunch of Excel tables where you store data). But MySQL has a downside — it is slow. I wanted to build an internal messaging system similar to Facebook Messenger, and I needed a database that is fast when it comes to writing and reading data. The reason for these requirements is that if 1,000 people start to chat with each other, they should not experience slow communication, and therefore the database that stores these conversations should be really fast. After some research, I chose to use ElasticSearch, which falls into the category of NoSQL databases.

After a month of research, I was finally ready with the list of technologies, I set up the servers to host my code. I could finally start the development.

Overall, for the business planning, the mockups, and choosing the tech stack, I spent 6 months! In today’s world of startups, this period is too long. If it takes that long, you’re doing something wrong. My only excuse at that moment was that I was working a full-time job.

Stage V – Hire a Person to Build the Front-end

Back in then, I was primarily a back-end developer. For those who don’t know, this is the person who writes software code that operates behind the scenes, which the user never sees. On the other hand, front-end developers write code that is directly related to the visual part of the software — that is the part the user interacts with (images, buttons, text, etc.).

I knew I could handle both roles, but considering the vast amount of work that needed to be done, I decided to hire someone to help me with the front-end.

So, I began my search on LinkedIn.

I was lucky! It took me only a week to find a really good developer based in Bulgaria — a true professional.

And so we started.

Stage VI – Development

As the owner of the project, I was playing the role of a team lead. I decided to adopt the following approach: I would develop the code that operates behind the scenes, and then the front-end developer would create the front-end code that communicates with the back-end code I had written.

Imagine the whole process as a ping-pong game: me to him, back to me, and so on.

I forgot to mention that I also took on the role of a QA. I extensively tested the solution for bugs, even though I had no prior experience as a QA.

I must mention — because it’s important — that throughout the whole development process, I generated a large volume of documents, believing they would all be important one day. Here’s a shortened list to give you an idea of what I mean:

• Branding Specification. This is a document that outlines the specific details about a brand’s visual identity – logo, colour palette, typography, imagery, voice and tone, etc. To give you an idea of how meticulously I was documenting everything, I’m going to share it with you – click that link to ​download the branding specification of Peoplegogo​.
• Pitch Deck. That’s a brief PowerPoint presentation, used to provide my audience with a quick overview of my business. If you’re curious and want to take a look at the Pitch Deck presentations of Peoplegogo, you can check them out here – a ​Pitch Deck for customers​ and a ​Pitch Deck for investors​.
• Financial plan.
• Legal documents related to third parties I have worked with.
• Technical specifications.
• Marketing strategy.

Another six months later, the platform was finally ready and released. It cost me approximately £10,000, which I paid from my pocket to the front-end developer.

Continue the Journey