Intro

I still have vivid memories from 2011 when Gergely and I started working on our first startup-like project. We wanted to do something big, I mean really big... Yes, we were very young and ambitious and we had absolutely no idea how we should build a startup, design an MVP and stuff like that. We created an over-engineered kraken for millions of users - at least we thought that it would work for millions. Of course we have never had more than 500 users. Eventually, we shut the business down but we learned more than ever.

This is the story of Tagmint. The story of how we f*cked up. And how you shouldn't.

Tagmint

At Tagmint we had a vision.
A vision that finding the right people can be different.

We wanted to create a semantic social network where people could easily find similar people. In the world of Tagmint everything was a tag. A tag could describe a personality, mood, hobbies - even your location. Tagmint processed your social networks and tried to transform your activities, likes and shares to tags.

If you want to see it in action, watch this video:

So this was Tagmint in a nutshell.

As a developer, DB engineer, CTO, co-founder, startupper, ninja, dragon, etc.

As I mentioned earlier, we really believed that our site will be popular and serve huge traffic so as responsible engineers we designed for the bright future, for tons of users. We started to over-engineer our backend, frontend and everything.

At that time, we only had experience with PHP and Java but we knew that developing in Java is not fast enough for an MVP and scaling with PHP is really painful after that. We wanted to have something else, so we started to look for different technologies.

Choosing the backend technology wasn't really hard, we wanted to give a chance to Node.js and we have never regretted it. It was fast, easy to start with and fun to develop for. Sure, we ran into a lot of antipatterns but it wasn't the failure of the technology: we were just inexperienced. I will show some of the mistakes & failures in the next chapter of this article.

We spent most of our time trying to find a fast and near real-time database that could be scaled horizontally and give quick results for set operations.

I had some experience with Neo4j (the popular graph database) and we thought that we can think about our world as a graph of connections. People and tags can be points and the connections can be edges. We tried to optimize different kind of graph algorithms with the help of our past university teachers to have something what we expected. Actually we created something really cool, but we didn't know that, because after the benchmarks it "just" worked for 500K users. What? 500K users? That is nothing, right? pfff...

Finally, we have chosen Redis for the set operations - we stored only the connections there and everything else in MongoDB. We were very satisfied that it could work for millions of users.

Also, it is not just about performance - choosing the right database for the job is a hard thing. When speaking of this scale you have to consider the CAP theorem (consistency, availability, partition-tolerance) Theorem as well. Let's not dive into those now, as the whole point is of this article is to keep things simple when starting a new venture.

What have we learnt?
MVP is the mosaic word for Minimum Viable Product, it can be a static site or even less. Please don't build a massive executor full-metal kraken, when it's not necessary. It can be fun, but do you have time for this? Go and create two MVPs instead. If your product proves itself, then you can hire a bigger team and deal with all the technology challenges to prepare your product to scale better.

As a front end developer

On the frontend side it also felt like we were in the middle of a revolution, but we were not strong/wise enough to drop jQuery. AngularJS was not even close to 1.0, Browserify was just forming up, React was not even dreamt about.

We wanted to build a mobile-friendly and fast frontend. So we started using Twitter's Hogan.js as a templating system with both server and client side rendering support. It is really good for devices without JavaScript support, or even better, mobile devices: if you render your content on the server a lot of battery power can be saved. It may sound like an isomorphic app, but honestly it was not. The biggest mistake we made here was that we had built our own client side framework. It worked well in the beginning and had some shared code with the server, but it did not scale. It was also really painful that we did not have tools like gulp (did not even exist) or grunt for our own monster. Deploying or even developing involved manual steps like minifying or compiling the templates.

What have we learnt?
Let's not reinvent the wheel, especially when you are in an MVP phase, but instead look for existing solutions and take advantage of them. Look for examples, and ask around - people will help you to choose the right frameworks/libraries for your problem. As you do not know what your product will be, it will change a lot, so be prepared for that.

As a backend developer

I mentioned earlier that we have chosen Node.js as the backend technology.
From the product viewpoint everything was great, we could ship new features rapidly and the whole product was really fast with incredible low response times. Developers were happy - we felt ourselves in wonderland.

In the beginning we had some over-engineering problems, we started to build heavy DAO-like models "thanks" to our past as Java developers. And we were also in trouble with the async control flows: how to do it in a scalable and clean way. We also wrote callback hells (feeling soooo proud), but after we developed our JavaScript knowledge and took the language seriously we could easily fix these problems. And just kept the fun part of the Node.js.

During the MVP phase we realized how important good architecture and the unified REST API design were. Your endpoints just keep growing and growing and without those one day you will find yourself in the middle of a huge mess. We recommend to follow jsonapi.org and Interagent's HTTP API Design Guide.
Good test coverage is also an important part of the MVP - it may seem it slows you down a little bit, but you will win your time back when you don't have to spend days with bug hunting. Also, when creating an MVP, shooting for the whole test pyramid may not be the best thing to do, as things change rapidly. Go for some integration/end-to-end tests at first, then you can refine the granularity test-by-test.

New is always better. - Barney Stinson

Is it certainly right? Should we use every new library with no doubt?
When I looked up Tagmint's source, I found some interesting things in the package.json:

  "dependencies": {
    "hogan-express": "0.3.2",
    "apn" : "*"
  },

Neither one is good - the first does not let NPM to update your dependency if a newer version comes out, while the second one will always update, even if there was a major release with breaking changes. If you are not familiar with these numbers, check out Semver.

Go with PaaS and hosted databases. Sure, it may sound great to pay less for your own cloud machines - but think again. In that case you have to do your own deploy process, take care of backing things up and so on.

What have we learnt?

Premature optimization is the root of all evil. - Donald Knuth

Also what we have learnt the hard way is that you shouldn't build a complex system when testing ideas.

As a mobile developer

We wanted to have a native iOS application but we didn't have Objective-C knowledge that time - neither did we know the SDK. We wanted to keep the development in-house because of the lack of funds, so the follwing was the only way for us: somebody had to learn it. I was always interested in iOS development so I was the lucky one. Here is what I've learned during the Tagmint application development (besides Objective-C):

  • well structured and documented API is the key for the fast development, use jsonapi.org etc.
  • version your API changes and keep the old one supported
  • keep your response size small (possibility to exlude/include fields)
  • optimize your images (EDGE, 3G are slow)
  • use gzip, cache, eTag - iOS supports it well
  • WebSocket on mobile s*cks
  • follow the rules of the platform and create "familiar" UI for your users
  • always test your app with a clean slate (clean simulator, especially before you publish it :P)
  • publishing your app to the AppStore is not as easy as it looks like (certificates, rules, age-limit etc.)

What have we learnt?
Prepare for something new.

Tagmint iOS app

As a startupper

We did most of the failures here, as startuppers. We had absolutely no idea how we should have done it. We were hiding until the launch date without any really useful feedback. We were just heading to the wrong direction during the whole MVP.
After Tagmint was launched we realized that we built the wrong product. We should have built a search engine for talents as a business-to-business software and sell it to recruiters as a service. But we built a business-to-consumer product with registration for people who had too much time.
After the launch we got a lot of feedback from very different people, and we realized that not always the experienced startup "professionals" give useful hints... Actually, most of the time they didn't. You should always ask your customers and pay attention to them.

What have we learnt?
You should always ask your customers and pay attention to them.

build-measure-learn

Outro

Starting Tagmint was a great experience. I have never learnt more before than with this project. It was fun and a really great period of my life. We could try a lot of great technologies and stuff from the password-less authentication to the graph databases and isomorphic-like systems.
Although we didn't win as founders but we gained a lot from what we have learnt. It was a great journey...

Tagmin logo

Facing similar problems? RisingStack can help with development and consulting.