Case Study: Building a Startup in Under 10 Days

Lately I’ve been experimenting with a new philosophy / framework for executing products & startups.

The goal is to get a polished MVP out the door and ready for launch in 10 days.

The timeline breaks down to:

– User Experience (1 day)

– User Interface (2 days)

– App Functionality (5 days)

– Testing (2 days)

Another aspect of building startups that I’m experimenting with is how important a viral loop is to the ultimate success of a product. The philosophy ive began to adopt is that apps should be cool and solve a problem, but the viral loop is what actually makes it ‘work’ as a startup.

Without some sort of referral / activation / acquisition funnel, you’ll be stuck constantly trying to acquire new users, which is no bueno.

The concept used in this case study originated from an old app I built in college at Indiana University called CollegePartyNetwork. It wasn’t my best idea, but there may have been a nugget in there.

The problem I had was that on the nights we would go out – everyone would text each other to figure out which houses had good parties.

It’s not easy texting 20+ (drunk) friends trying to figure out where you’re all going to meet to get more drunk together. There needed to be a better way – everyone was looking for the same info.

I built CPN in my limited free time, but quickly trashed / shelved the app – too niche, and I wasn’t happy with the execution. I still have the 5,000 vista-print flyers I bought in anticipation for launch, haha.

From this initial problem / idea for finding college parties, the seed was planted for what would later become the app in this case study, Status.

The concept behind Status is an app that allows you to see your friends ‘status’ and how far away they are.

If I have meeting in Santa Monica and want to get lunch after, it’s really annoying to text 10 friends to see what they’re doing, if they want to get lunch, how far away they are, etc.

Status solves this problem by creating a single dashboard you can use to see what you’re friends are doing right now, and how far away they are.

It’s a feature that every social network has, from early AIM clients to Facebook and Twitter, but it’s also a feature that no app has really focused on exclusively.

The ‘status’ on all these social networks function the same (short text update), but the meaning behind each of these Status’ are different.

Facebook is for updating friends on your life.

Twitter is for sharing news, thoughts and interesting content.

There isn’t really a social network that tells you what your friends are doing ‘Right Now’.

You wouldn’t really want to clutter your twitter feed with “Anyone want to get lunch?” – especially since any  random person can follow you.

Introducting: Status – Your Real-Time Social Dashboard


The first step after solidfying the concept was to come up with a simple UX / UI to accompany the idea.

One key aspect to keeping the development cycle short is doing all the design myself. This cuts costs significantly, and allows me to design exactly what the developer needs, as well as factor in viral loops, etc.

Basically – if you want it done right, you have to do it yourself.

So, the first step was to figure out the basic design stylization for the app.

While searching around for ideas, I found a great geometric background on SubtlePatterns ( and decided to use that as a starting point:

Next I mocked up a quick logo with one of my favorite fonts, Santeli (

To finish the Logo, I added some iconography to show a little bit about what the app does as well as set the tone for the brand.

The green / yellow / red dots represent the three phases of a status we’re all familiar with (available, idle, away):


Using the logo as a style-guide, I moved on to designing the icon:

Having a pretty good idea of what the app should look like visually, the next step was to work through all the necessary pages of the interface.

The first iteration (below) was rough, but all the main functionality was there which allowed development to move forward on schedule.

Splash Page:

Signup / Login:

Status Page:

Updating Status V1:


Add Friends:


After getting an alpha version of the app on my phone, I decided to re-design a few pages and refine the design style.

I wanted to use a video background in both the app and the website, so I searched through a few hundred pages on before coming across a really great stock video:

Using this, I re-designed the splash page and login flow:

I also felt that the ‘Status Update’ design was lacking, and it also exposed an initial UX flaw. I realized that once I added certain people to my friends list on Status, that I would be forced to ‘edit’ the types of status’s I send.

This meant we needed a way to allow users to ‘update everyone’ or ‘select friends’ to send their status to.


For the website (, I wanted to implement the same video background as on the app, so I found a nice bootstrap template and customized it for exactly what I needed.

I also added a Twilio integration for downloading the app — I’ve found that linking to the app store via the website will lead to a lot of lost conversions because users have to either remember the app name or navigate to your website from their phone.

With Twilio you can have users enter their phone number and directly text them the download URL for your app, which has a much higher conversion rate.

iOS Development:

I hired an objective C engineer I’d worked with before to build out a very simple app using Parse as a backend.

The main functionality was:

– Adding Friends

– Updating a Status (Everyone & Select Friends)

– Push Notifications

The great thing about Parse is they make it really easy to get things up, running and out the door. They handle hosting, databases, analytics, push notifications & more. Really cool.

The development process was pretty straightforward as we weren’t really inventing any hardcore tech for this project.

There was one little  issue we ran into during development which was with users phone numbers / hashes & adding friends.

In order to keep the app ‘international’ we require users to input a country code while adding their phone number.

The issue was that when this phone number hash was created in the database, it would be generated with a country code on the phone number.

On the other side of the funnel, when users would go to add a friend, a hash for that  number is generated & searched across our database for a match.

The problem was that most people don’t add a country code when adding a phone number into their contact book. Our system would not recognize the difference between the actual user (with country code) and the person adding that user (whos contact info doesnt contain a country code).

It wasn’t really a huge bug to fix, but it did take a few tests to notice what was going wrong and why sometimes a user would add perfectly, and sometimes it would add a blank record. 

Once that small bug was ironed out, the app was ready to submit to the store. The last step was to write up the app title / description and mockup a few screenshots:

Boom! There you have it. A breakdown of Status.

Download: Status – Your Real-Time Social Dashboard

All-in-all, the total execution time for Status was around 11 days. That said, it’s a concept that had been floating in my head for a while, so I had a pretty good idea of what I wanted to execute, and that I could execute it in a short amount of time with a minimal technical scope.

If you have any questions / need advice on building your own apps feel free to leave a comment or shoot me a message!

– J