Lessons from developing a user based web application

Overview

In august 2018, while driving down Highway 101, with a beautiful view on the pacific ocean, I came up with a simple but yet fascinating idea (I thought) for a web application.

The main idea was a website where students (like me) could create a community and share summaries or notes for different lectures or modules at a specific university. For example “Introduction to Economics” at the University of Bern.

I knew there were already a lot of such services available, but I was sure that nobody was doing it targeting the exact lecture of a university. As I learned later, this was not enough to be successful in this competitive area.

So me (software engineering) and my brother Darius Stulz (business and marketing) started Spickr together.

In this blog post, I don’t want to tell you the whole story how we developed spickr.io but rather show you the most important errors we made and also one or two things we did right. Some things are pretty trivial, others are a bit more difficult to detect.

Let’s get going and start with some things we could have done better.

1. Know your target group

When we started with Spickr, we were absolutely sure that this is a service students wanted and needed. Because we ourselves are both students at the University of Applied Sciences Bern and we both thought this would be awesome. Therefore as a logical step, we never bothered to really dig deep and ask our target group if the service would be useful and if they would use it.

This is probably one of the most critical points, because no mater of good your product is, if nobody wants to use it, it’s useless. Especially in a network, where users provide the content to attract new users.

So make sure to get to know your target group, before you start developing a product. Because if you can identify the pain points very early in the process it’s going to be a lot simpler to solve them.

2. Have a plan

This one is quite easy. HAVE A PLAN. While I know a lot of software developers (I’m one of them) who just jump right into coding the damn thing, this is often not the right thing to do.

When I started coding Spickr, I didn’t really have a plan what to code. Don’t get me wrong, I had a vague image in my head how the first version should look like. But if someone asked me to lay the plan out for them on a piece of paper, a lot of unresolved question would pop in my head.

As the project grew bigger, I started to create Trello boards, UML diagrams and created database schemas. I did this because the project grew so large, it was impossible to have the whole plan in my head. For example if I had to add a feature and create some new database tables, I could just look at my schema and figure out the best way to introduce them into my existing system. Instead of thinking it all in my head and missing some important details. It just makes work a lot easier when stuff gets more complicated.

In the end, I think I could have saved a lot of time in the development process if I just had put my thoughts on paper and have a visual plan of how it should look like and what the steps would be to get there.

So my advice here would be, always create a plan according to the size of your project. Depending on how big it is, this can just be a Trello board and a few mockups. If it is bigger, so is the planning. For example a database scheme, UML diagrams, GANT chart and detailed mockups could be helpful, but there is a lot more out there. And you have to figure out was supports your development process

3. Don’t forget to market your product

We tried to create a social network, where users provide and consume content from each other. Therefore, to succeed we needed a critical user mass and we needed initial content for the first few users. To acquire them, we printed out flyers and started some ads on Instagram and Facebook. But in retrospective this was not really enough. Don’t get me wrong, the ads on social media gave us a lot of traffic for a really small budget (100–200 Swiss francs), but to spread the word and gain the few thousand first essential users we would have needed a lot more funds.

In the end you have to sell your product to the people, and I think we didn’t do that enough or good enough to get users.

So always think about how you are going to sell your product and how you are going to reach your target group.

4. Registered users are not active users

Lesson six also is connected to the network problem. Initially, we rolled out Spickr at the University of Bern and high schools in the area of Bern and Zurich.

In two months we had around 300 registered students on our site where around 200 were enrolled at the University of Bern. The University of Bern has 17'000 enrolled students. So let’s say we had about 1% registered users on our site. This wouldn’t be a bad number for sixty days the website was online, but here comes the big difference: About 99% of these users were one time users. They visited the site, wanted to see what’s around and never came back. There were two reasons for that, number one is that we didn’t have enough content on our site to make them revisit. Number two that these users didn’t want to share their own summaries or create content. They just wanted to be consumers. But we get a little bit more into that later.

The lesson is, it doesn’t matter how many users you initially pull to your site, what matters is the users that stay. So give them a reason to stay, in our case this would have been more initial content.

5. Identify your problems

This one is simple but also fundamental, identify your problems.

The best way to do this is just getting feedback by your users. With Spickr we realised we were getting traffic, but there was just not a lot of content shared. So to dig deeper, we actively contacted our current users as well as potential users to ask them what the problem was. In the end, we discovered that the students would like to get content from our site, but just did not want to share their own created summaries with fellow students. This was something we did not predict, and it was one of the main reasons we stopped developing Spickr.

If you don’t know what your problems are, it is really hard to improve your product. So invest time in getting to know the weak points. If you can’t do it own your own it is always wise to ask the people who actually use the product.

6. Fail fast and get feedback

This was a lesson I embraced from the beginning. I got the idea from “The Lean Startup” from Eric Ries. By the way, this is an amazing book, which not only demonstrates how to start successful startups but project management in general, so if you haven’t read it yet, I highly recommend you give it a shot.

Build-Measure-Learn feedback loop With Spickr we developed an MVP (Minimal Viable Product). We only developed the essential features for the product to work. Why? Because after we got our MVP, we went out and got feedback and then iteratively improved our product with the features and improvements we got from the feedback. This is an iterative method which is also widely used in agile methods like Scrum. The thought behind this process was to fail fast. We wanted to test our product on the market as fast as possible to see if we have any chance of success or if we have to pivot (extreme change in the business model and or product).

In conclusion, get to market fast, get feedback and fail fast. This will save you a lot of time in the development process and will give you valuable insights in what direction you should steer.

7. Don’t waste time on details

This point is similar to the previous one. If you create such projects, time is your most valuable asset. Especially if you are doing it like me in your free time after work or university. Then it becomes really essential on what you spend your time on. Because in the end, you don’t want to look back and realise that you wasted your time.

One thing that I have learned is to not hang yourself up on details. What do I mean by that? Focus on the essential parts of the product. The parts that are absolutely needed to get feedback. Early on in the development process, you are mostly going to change a lot in the future, so make sure that your core features are solid and reusable. But don’t invest a lot of time in things you are going to change anyways. For example, with Spickr I did not invest a lot of time in the details of the design, or if I should use an email or a username to login, or what color button xy on page xy has, because I knew I had to get some feedback first on my essential features or else the time would be just wasted.

Focus on your essential features, get feedback and adjust details later in the process. This will save you time and a little bit of your sanity, if you don’t have to code and design your login form all over again after you spent 10 hours developing the current one (believe me, I know the feeling).

Conclusion

Although there would be a lot more lessons to talk about. Those seven lesson were the most important ones I learned.

Even if we didn’t produce the big breakthrough with Spickr, we still learned a lot! Not only about how to develop such complex systems, but also about business, validating ideas, marketing and much much more. I can only recommend not only software engineers, but also everyone else, to just start on the project you always wanted to do. Even if you fail, you will have gained a lot.

If you are just starting a (web application) project, I hope you can take one or two of those lessons and save a little bit of time not doing the same mistakes I made.

Also, I will get into the technical aspects and a lot of other stuff and projects (A lot of machine learning) in future blog posts.

Since this is my first post all kind of feedback is appreciated, especially on things I can improve.