Marketing and Non-Technical Things

Letterbox has officially launched its Android app! Currently we have around 10 users, and our 100 users by STePS has been blocked by a commonly hated enemy, App Store review. Now that the implementation is almost done (we’re working on a new feature), there’s a bunch of non-technical things to do.

Marketing

For a team of 4 CS students, marketing has got to be one of the hardest thing to do. I think we did this part well by printing posters, heading down to take pictures of random strangers to post on our Facebook page, making sure our Facebook page is getting likes etc.

I think one of the lessons learnt from Henry and ShopBack was the conversion funnel. Marketing is only responsible for bringing traffic into the funnel. What’s going on with Letterbox is the lack of actual user conversion rate. Users know about Letterbox, but what next? None of them are using it. We need users, not likers.

Good news is, I’ve gotten over the barrier of speaking to strangers about Letterbox. Talking to strangers about a dating app is really fun, especially when you’re riding on a hoverboard. It’s easy to catch the attention of people when you’re on such a ‘mobility device’ and it could be a business model to rent one of these as a marketing tool. *kidding*

We’ve also got a *secret* video coming up for STePS! It’ll be AWESOME we promise. 🙂

Partnerships

In the meantime, we have also spoken to a few people whom we can partner with. Actually, just one for now. NUStyle. This is a work in progress and I do hope this partnership can follow through!

Pitching

Of course, refining our pitch has always been a priority. We refine our pitch every progress report, and for the class presentation I believe the pitch was more or less final.

Letterbox is a dating app that matches you with people with similar opinions and mindsets.

(The double ‘with’ kinda annoys me)


So what’s there left to do? The deals part of our app is still being implemented, it’s in its final stages now and all we have to do is to test it and seed the database with more deals.

We’re really looking forward to STePS to present what we have, I dare say Letterbox is our ‘baby’ and we can’t wait for it to grow!

:3

Advertisements

Really Overdue Update

Here’s time for a really late update for this blog. The workload for other modules suddenly went on steroids, and coupled with different things we are trying to do with our Letterbox application, this blog seemed to be neglected.

What has been happening so far for 3216?

14859699

Letterbox is a dating app that allows you to meet new people with similar mindset and opinions of life, instead of random matching by location.

(This is a much better pitch as recommended by Colin)

We’ve been through multiple rounds of idea validation with Prof Ben, Colin, and other TAs before we finally agreed on doing the dating app this way.

So what have I learnt so far?

Talking to people is pretty important to get feedback. I think I’ve talked to many acquaintances in Tembusu, and more recently, gathered some feedback from people sitting along the corridors of AS6. (All girls! Pitching is harder than saying pickup lines. Or at least that’s what I think) We’ve gotten some valuable feedback from doing so and I have to admit that it was pretty fun, although a little nerve wrecking.

Down to the engineering part, we already have an MVP done. It needs some polishing and also deployment issues to iOS and Android. Doing a hybrid application is really a pain and I would think that doing a native application would have been much easier.

But we wouldn’t want to miss out on any camps of users, and we did not want to slow down on iteration too. I still think it was a good choice to do it up as a hybrid application.

A few new concepts I’ve learnt would be Angular best practices together with new CSS tricks such as flex-box and CSS3 animations. Still leveling up frontend wise.

The remaining weeks shall be more focused on marketing our application. That’s something that we lack and really hoping that we could figure something out soon.

Here’s to Letterbox’s success! 🍻

Post Assignment 3 Submission

Assignment 3 has been one of the smoother assignments so far. We’ve built LagerApp, a mobile interface for DevOps to read their server logs. It was my first time building such a niche app for developers and it was really smooth sailing.

I think one of the reasons why the process was slightly more smooth sailing was because it was built by developers for developers. Having understood the pain of ssh-ing into a server just to read logs which doesn’t look appealing at all is a pain. Having such an app allows DevOps to understand what’s going on in their servers even during lunch time.

One of the greater lessons learnt from assignment 3 is that a problem becomes much easier to solve when it’s a real and good problem. It might not be a big problem, but having an app that actually solves a problem is better than having one that doesn’t solve anything.

Technical side, I used React again. This time without all the fancy architectures. I think going through so many cycles of fiddling around with ReactJS during 3216 gave me more confidence in this hot, new popular library. Also I tried out things on Sinatra, a slightly more lightweight framework compared to Ruby on Rails. This was a really lightweight application which does what it aims to achieve well.

Learnt a lot from Jingwen, Rahij and Anand as well, they were amazing teammates 🙂

Now that there’s just the final project left, it’s time to go all-in. We just finally refined our idea for LetterBox, an improved version of the previously failed NUSHello.

Let’s work to get it right this time. A quote that often float into my mind recently is this by Samuel Beckett.

Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.

I had this post-it in front of me for the entire year 1, without actually tasting failure. I think NUSHello was a demoralizing start to 3216, but given this opportunity, I want to do things right this time.

Right now is the calm before the storm, here’s to a successful final project. 🍻

Half-time

It’s halfway through the semester and CS3216 has been treating me really well. Remember when I said I should keep count of my hours of sleep? It’s been going up lately. With at least 40 hours of sleep a week. Assignment 3 feels much more manageable when we did not decide to go ahead with something very complicated.

Final project planning has been nothing but full of uncertainty. Having failed assignment 1’s execution once, I think it’s normal to plan more carefully and with better foresight this time. Prof Ben has provided us with a quite a bit of comments and ideas, now it’s up to us to decide how to execute it best. However I am still unsure if we should go ahead with such an idea given that it has failed the first time.

We should not be afraid of failure.

To put what I learnt in CS3216 into application, I’ve been browsing Angel.co for different startups to understand their ideas better. One of the best lessons learnt from this course so far would be to identify the quality of an idea. What pain point does it solve, how is it going to be executed, is there a market for this?

It is common for us computing students to be approached by different people seeking to start their own business. I would very much like to try out being a technical co-founder one day, but not for the wrong ideas.

Here’s to hoping that our final project execution would be done in a more organized and productive way!

2 Down, 2 To Go

Assignment 1 was due two days ago and it has been a whirlwind ride for NUSHello. I think it isn’t very polished and given the sufficient time period, we could’ve done much much better.

One of the lessons learnt from my previous internship was that engineers don’t panic. This advice stuck with me a lot for this semester and it removed that panic attack that I used to get when things don’t go according to plan. However I think this exact advice led me to believe that things are going to be okay when they clearly aren’t. Colin’s comment for both of our app review was that we will fail. Not to say that we didn’t take his advice seriously, but we didn’t know how we could prevent that or improve from it.

Shit also hit the roof when one of our team members dropped the module.

During the last few days before the deadline, I had to tell myself that I don’t build shit products to tide me through the nights. So at least now the product isn’t outright shit.

Here are some of the lessons learnt from it:

Do the mock-ups and wireframes well.

We didn’t really put a lot of effort in the mockups and wireframes so they were not really well done. We only came out with the standard layout of the application of how each page should look like and did not put much thought in the app flow.

The mockups were done more as a way of telling us “okay this is what the page needs” and we left it there without any iteration. None of us touched or looked at the mock ups until the final week and wondered why didn’t we improve on crucial areas, and also how the application flowed.

Frontend development should not wait

Another major mistake we made was waiting for the backend to be set up properly before we began with real frontend work. What we should have done would be to mock the objects from the backend such that both development can go on concurrently. We realized this too late into the project and of course this was due to some severe miscommunication.

What this meant? We did not have sufficient time to iterate on usability and UI/UX improvements. Zero user testing was done and we failed the app review twice because the application simply didn’t work.

Choosing the right tech stack

I believe I’ve written enough on how our tech stack was a total disaster despite choosing all the latest and exciting technologies to use. None of us was that familiar with any of what we’re using so at the end of the day we are all as confused as anyone else in the team.

Productivity was really affected by this, and so was the team morale. I think many of us didn’t feel happy working on this project since sometimes the project was really heading nowhere.


In conclusion, I feel that the idea was fine, but the execution was done poorly. Given another chance to make this right, I would certainly do this all over again. (Who says we cannot still continue work on this during our free time, right?)

Colin’s comment on my previous blog post really stuck with me.

Live and learn.

Here’s hoping I’ll do the two final app projects better after having the experiences gained from assignment 1.

I briefly mentioned before about my experiences with messy PHP code and really messy code architecture. Maybe I’m seeing it for myself right now how difficult it is to set up a code architecture that makes sense. Cloning right off someone else’s project as a base isn’t the right thing to do most of the time. It requires us to fully understand the architecture before implementing it ourselves.

Just to take note for future projects.

What “Things”?

Things is a to do list app that sets out to replace pen and paper.

In my opinion, writing a to do item down on pen and paper is much more easier than tapping on a screen multiple times. My trusty Muji todo pad has been serving me well since the start of University days.

Photo 2-9-15 00 30 09

However, to facilitate learning about what has Things done well, I shall list down the three points about the application which makes it really popular.

It has only four fields to fill in

I feel that this is one of the main attraction of the application. Having only four items to consider when creating something to do reduces the amount of time planning, to actually doing. In fact, I believe that the time taken to fill in those four fields should not take longer than the time to actually write down in pen and paper itself. Also, it gives the app a very clean feel, removing the clutter that we see in forms we encounter everyday.

Clean and efficient UI/UX

Things does what it does beautifully. The UI/UX of Things stands out above the rest as really simple and intuitive to use. User retention is often about how beautiful an app looks and Things have done that well by putting in lots of considerations about their look.

Non-collaborative

Things did not have collaborative features such as Todoist or Trello. (if that is even considered a todo list) I think they hit spot on with this decision since a todo list is something very personal and private. In actuality, we do not write a todo list and share it with everyone to clear it together. (there’s the post-its to do that, but that’s more of a Trello thing) Perhaps we can gather around in a meeting and list down the things we have to do, but a todo list is something that one writes down to set his productivity achievements and target for the day. It is something personal and should not extend to a group.

With regards to Things being Apple-ish about this, “use it or find something else”, I love the attitude too. It shows how much the company believes in their own values and is definitely something worth learning from.


There’s a problem which I cannot get over with about Things. The price. Why would I pay a hefty $10.00 for an app that can be easily replicated with pen and paper, or even something free such as Chrome’s Momentum or Todoist?

In fact, there’s even the Open Sourced TodoMVC by Addy Osmani which makes writing a web version of todo list very easy. (At the same time learn one more new MV* framework out of the 1259812 ones out there)

One can argue that the company needs a small amount of paid users. I believe there needs to be a balance in this. To me, $10 for a todo list app is way too much that I am willing to fork out.

In conclusion, I am convinced that Things might have done certain things right about a todo list app. But to totally replace my awesome Muji pad at a price of $10? Probably not.

P.S. A Muji pad costs something too, but I’m willing to spend that amount for convenience of a tried and tested method, rather than an app that I may or may not continue using. 😀

Over-ambitious

Assignment 1 is due in one week’s time and I honestly do not feel very ready about it.

Like I mentioned in my previous post, our team decided to go ahead with React.js with Redux, and recently shifted from that into Reflux. I think this was one of the major issues that I did not handle properly, leading to a massive snowballing of work. Thinking that it would be possible to dive into a project not knowing my tools well and expecting to learn while building the actual product is a big mistake. We were over-ambitious.

What could be done better?

There are many smaller ways to first fully understand React.js + Redux/Reflux before I actually come up with the skeleton of the project. Our initial repository was a complete clone of a tutorial on Medium and it did not turn out very well since it was bloated with many things we didn’t need.

The lesson learnt?

Never clone repositories you don’t understand.

In fact I wish that I had written the entire structure of the app by myself, which gives me full ownership and control of what I want and what I do not want. Toying with new technology is cool and exciting but at the same time counter-productive. But at least we figured that out halfway and things are moving relatively more smoothly now.

Assignment 2’s presentation is due today and I hope to share with everyone what our team has found out about Medium. Some feel that assignment 2 is a complete waste of time, but for my team I felt that we took into account different perspectives of how such an app with near perfect UI/UX, Medium, have their own flaws. In the process of product development, this is pretty important as well.

So here’s to the presentation later, and to the completion of assignment 1 soon! (Hopefully it ships fine!)