Getting to Know Pyck

Right after building a working prototype and getting the first traction.

An interview with Alexander Braunreuther, CTO at Pyck
September 2017

NOTE: the Pyck project is not actively developed by now, as Instagram published a feature covering the main functionality of creating surveys.

Can you tell me a bit about the company?

The company is called Snaptrack, back from the original idea, our main project right now is Pyck. You can find it at pyck.it. Currently, we are three people. Marvin and I are the founders, Dennis is helping with the design and iOS development work for Pyck.

What’s the product?

The product is a survey tool, inspired by an Instagram game. If you search for “Instagram bingos”, you’ll find it. The target group are mostly young people, 11-17 years old and 70% of them are female. You can use the tool to create entertaining surveys, which people can answer by choosing from different emojis displayed in a grid. For each survey, there’s a single question like “what’s your favourite summer sport?” or “who do you like better?” with answers like “my father” or “my mother”. Any user can create surveys, the question and the answer emoji.

The app displays all surveys in a scrollable feed, and other users can participate by choosing their answers. When you answer one of them, you can see who provided similar answers and how you compare to everybody else. We have over five thousand users right now.

What most important for the company right now?

We built an MVP, it’s working pretty well and attracting users. The problem is, it’s built around one a single feed for everybody. Because there are so many users right now, that the feed delivers too much content and little of it is really relevant for a single user. We need to ship a new version, with a personalized feed like Instagram or Facebook. Also, we want to have more kinds of content. Right now you can just answer a question by choosing an emoji, but we want to have other content like images in there as well. Those things are what I’m working on right now.

What’s the story of the tech behind the product?

From the beginning, we wanted to keep the tech as lean as possible. First, we just built a landing page with a bit of marketing content. The landing page was built using react I’m most fluent in that stack. We used Firebase hosting for it, as it’s really fast to set up. If you want to deploy an app quickly, I recommend you check it out. You get SSL out of the box and it’s well configured.

Once we saw that people liked the idea we pitched on the landing page, we created an iOS and Android app backed by Firebase. As we could use the Firebase database, there was no need to create our own API. We had to use Firebase Cloud Functions for 2 or 3 things, like a few denormalization issues, attributing points to a user account in a safe way or the login, as we had to interact with the Instagram API for that.

Did you invest effort into automating parts of your development or deployment workflows?

Not for the MVP. We didn’t need any automation as the process was so straightforward, apart from the cloud functions. I just developed them on my local machine and deployed them by hand once they were ready.

The only annoying thing about that is testing new versions. Even though we have backup scripts, we’re trying new things on a mirrored environment. We create a duplicated Firebase app and copy over the production database. Once I make changes to a cloud function, I’m testing them there first to see if it works as intended.

Before we switched to that workflow, I made a change once and just deployed it to the production version thinking “that’s an easy change, it will work for sure”. That change made our complete database unusable, and I had to restore a recent backup. It wasn’t that bad as I deployed during the night and there were few users, but not a nice experience nevertheless. That elaborate workflow is the reason why I’d like to switch away from firebase. Applying changes right away is a bit too risky, and if you want to do it right and in a clean fashion it takes a really long time.

You want to switch away from Firebase?

I’m a Node developer, so I’d just build something new using MongoDB as the data store instead. The data we have would be a good fit for SQL as well though. Originally, I wanted to use Firebase Cloud Functions for everything, but the problem was that each time a cloud function runs, it would need to connect to connect to the database. Especially if using Mongoose, an ODM for MongoDB, the startup time for crunching all models would be 100 ms every time, which means your function call is 100 ms slower that it would be, which is not cool.

That’s why we’re using cloud functions as worker processes only. Those evolved as well over time. In the beginning we used Redis with a Node module as task queue, but then I took a look at Google Pub Sub. You can use it to trigger Firebase cloud functions or Google cloud functions. Usually, when handling a task you’d put it into Pub Sub and, your workers would start working on it at the same time. With cloud functions, a function is started for each item, the task completes and the function terminates. We don’t need to handle scaling of task workers with that method, as that would be like a completely managed queue.

I chose the stack we use, because I did not want to handle manual scaling issues. I’m not really experienced doing that. Apart from that, we’re using many SaaS services. That’s something I tend to do - as long as we’re a small team, I try to avoid coding up anything which could be taken care of otherwise. That’s why we’re using Algolia for search, GetStream for our feed services and some image processing services like imgix to create scaled-down versions of images on the fly and similar tasks. We’re doing it to save on development time mostly.

What’s most important for you about your current setup?

What I like about MongoDB compared to the Firebase database is: you still have to denormalize a lot for it to stay performant, but you have the option of writing queries. You can query MongoDB, as other databases, with joins and all that. (Note: Firebase has published this feature since the interview.) You can simply say “give me all users who have logged in at least once yesterday” that’s not possible in Firebase. You’d have to completely denormalize the data in that regard and that’s no fun at all after a while. Of course Firebase has its strong sides, such as realtime stuff, but we don’t need it for that project.

Apart from that, I really like the solution of using cloud functions to process lots of tasks. You don’t have to care about keeping a task queue running. Instead, you can simple use Google PubSub and can rely on it. It won’t break on you, there’s no task queue which will be overwhelmed or similar issues. We’re trying to manage as little services as possible ourselves. For MongoDB for example we’re using the Compose service, we’re not hosting an instance ourselves. It’s a bit on the expensive side, but given our data that’s not much. Until your dataset grows to a few GBs, it’s going to cost 200€ per month. Right now we’re paying 30€. That’s worth it, as we’re saving a lot of work.

What’s the biggest problem?

We have a few problems with the frontend. As many users are on very old devices, I have to optimize the experience for those devices as well. That’s not much fun.

As the product is in a very agile phase, it changes frequently regarding features. That means that we need to migrate our data quite frequently. That’s not much of a problem in development, but doing that in the live environment is not that cool. That’s why we want to rewrite the application, instead of extending the MVP. This is a Firebase-specific issue in my opinion. It will be an issue with MongoDB eventually as well, or with APIs but not as tedious.

Also, we’re switching away from the Instagram sign-in. There’re just too many problems with it. Some users can’t log in – I got in touch with Instagram about that issue and their answer was “yeah, we’re aware of that problem but can’t help you with it”. That’s why we’re switching to phone authentication, using the mobile number. As we want to have one single method to authenticate, we’re going to have to switch the Instagram users who signed up with Instagram to phone auth, have them link their Instagram profile, so we can merge their data and a lot of similar tedious business.

What’s painful regarding deployment or automation in your current projects?

Well, the workflows on the iOS side were always a bit annoying. You usually have to ping the guy who works on the iOS app to push a recent version up to Testflight. If that doesn’t happen, nobody has access to the latest version, nobody knows what the most recent state of the app is. So it goes like “so, there was no progress?” and he goes “yeah sure there was”, “so why isn’t anything on Testflight”, “whoops, I forgot to upload it”. That issue would be resolved if we automated the upload part.

There’s gonna be a similar issue in the backend. I really like automation, and always have been using it, but I’ve been doing so for frontend projects where I’ve automated very, very much. Any tasks which needed to be done regularly, I configured to run once there was a push on GitHub. Build servers somewhere got busy, and did everything which needed doing. I’d like to do it for our backend as well, but I’m lacking experience for that stack, as I haven’t worked with it frequently.

What’s your biggest learning regarding deployment, infrastructure, automation or tech in general?

In the past, I’ve always been eager to code up my own solutions for problems. By now, I taught myself to prefer using services, instead of rolling out my own solutions. This saves a lot of development and maintenance effort.

There are downsides with this approach as well. For example, when writing unit tests, it’s super annoying to write stubs for all of the services you’re relying on. This sometimes leads to skipping on tests, but I really like having them. But that can mean that the code is not in a good state yet, as it shouldn’t feel like an enormous effort to write tests.