It seems like we are moving up in our levels of engagement. We are starting to see new users (who we don’t know!) start using the app and uploading pictures.

Next test: Will they return to upload more pics?

In these early days of our product release, it is important for us to test the levels of engagement between users and our products. So far we have noticed the following:

- Users who we knew and were able to personally introduce the app to, seemed to like the app, and returned to using it, even when we were not around. This seemed like a good sign.

- Strangers (who didn’t get the personal introduction from us) didn’t have the same level of engagement with the app. They would download it, but wouldn’t interact with it in the same way as the users we knew. 

This suggests that we have to do a better job of introducing the different features in the app. An update has been sent to Apple, which adds a few more tutorial screens. Let’s see if this helps!

So we know that users in Taiwan like to take photos of their food. We now want them to use our app to do so. So how do we get them to switch from the method they are using now, to using our app instead?

Our solution is to duplicate plus offer more.

Most users who take pictures of their food at restaurants do so on Facebook (we’ll tackle Instagram in a future update). So if we are going to duplicate this functionality in our app, we have to let them do the same things they can do in Facebook, in our app. If we miss any of these things, then that is a reason for them not to use our app, which we can’t have. So what are these things?

1. Select the restaurant they are in.
2. Write a description of their experience
3. Tag any friends who are with them.

The current version of our app covers the first two points. The next version will cover point 3.

As far as the plus more aspect goes, the main advantage our app provides at the moment, is being able to automatically post your food pictures into your own Facebook album, making it easier for you and others to review your previous food experiences in the future.

Is this enough to convince users to make the switch? We’ll see. If not, we’ll either need to do a better job of educating them on these features, or add more features to make a more compelling case.

Now that our product is live and available for users to download, we of course want to focus on acquiring users. Before that however, we want to make sure our product stands on its own. For that we need to see:

• Do users understand how to use it?
• Are users actively using it?

If the answer to any of these questions is No, then we need to fix that first, before we begin marketing it.

So far, we have noticed that there are many elements to the app that seem obvious to us, but aren’t obvious to users. So we added an intro screen to explain these areas.

However, this introduced a new problem, as users couldn’t find the X on the top right to exit this page. 

Once we figured out these issues, we still wanted to monitor if users were actually using the app. They weren’t. Users were downloading the app, and looking through it, but weren’t uploading any pictures. Why not?

Turns out in this current version that users can only upload pictures from restaurants that have been indexed by Google. Since Taiwan has a lot of smaller restaurants and night markets that don’t show on Google maps, this meant that a lot of users who wanted to upload photos couldn’t because the matching restaurant wasn’t available for them to choose.

A new version of the app has since been released that fixes this issue. Users can now add new restaurants, not found on Google, to the app.

As a result, we’ve started to see engagement. That’s a good sign - but it’s still not where we would like it to be.

More usability tests have found other issues that need to be fixed, that we are now working on.

Once we are satisfied that we have a product that users actually love and use regularly, we’ll begin to market it.

Now that the drama of submitting our app on time was complete, I could focus on preparing for our IDEAS demo. We were given 6 minutes to present our product on stage. Since we had an app and website to present, that would give me 3 minutes for each portion. In addition, we were given a booth where we could present our product to passers by.

The event began on July 17 with a rehearsal of our presentation. As our team was coming up from Taichung, I attended the rehearsal by myself. I found out that we would need two people for the presentation as my computer and mobile phone were setup to the side, while I was on stage. This meant I would need a different person controlling the app and website while I was talking about it. 

As we were encouraged to look at the audience during our presentation, this made it tricky to coordinate the demo while speaking. This meant a lot of practice that evening with my team member Luise.

In the mean time, I kept checking my email for status updates from Apple regarding our app. As our app was still waiting for review on Monday morning (with our presentation on Wednesday morning), I submitted a request for an expedited review. On Tuesday evening, I received an email saying my request had been approved (woohoo!), which meant there was a chance they could look at it and approve it overnight, just in time for our demo on Wednesday.

Around 3 a.m. Taiwan time (noon Apple time) on Wednesday morning, Apple began their review. I was ecstatic (and yes I was up at the time). It looked like our app would actually be ready for our demo time - talk about cutting it close!

11 minutes later, I received a message that our app had been rejected.

The reason for the rejection was that there was no content outside of Taiwan. So when the tester opened the app, all he saw was a blank screen. In my haste, I hadn’t mentioned to Apple that our app would only work in Taiwan.

Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah!

So that was it. The bad news was that our app wouldn’t be ready for users at the IDEAS to download. The good news was that we could now implement the feedback from beta tests and submit an updated version. Bitter sweet feelings ensued.

I had no choice but to put all this behind me as we had an early train to catch that morning. A couple of hours later it was time to present.

The presentation went well - the practice and coordination had helped. The next two days were then spent at our booth explaining our app and website to anyone willing to listen.

Kudos to Luise for all the talking she did these two days.

While we weren’t able to get user downloads on the spot, it was extremely handy to get impressions from users using our products on the spot.

Along the way, we also made contacts with other teams with similar products who provided very good feedback from their own experiences, so all in all it was a worthwhile experience.

A couple of months ago, while we were in the midst of developing the new FoodJing app and website, we were given the opportunity to present at Taiwan’s annual IDEAS show, where startups get to introduce and demo their latest products. This show is meant only for products that are live - i.e. prototypes of future designs aren’t allowed.

Looking at the schedule, and seeing that this event was at the end of July, it seemed like that should give us enough time to create the first version of our product that could be released to the general public. IDEAS could give us good publicity for that initial launch.

Having that deadline was a good way to gauge our progress over the past few months, as we had a clear target in front of us. Since there was an app involved, this also meant that we had to schedule time for the app to be submitted to Apple’s app store, so that it would be ready in time for the event.

By the end of May, we had completed an early prototype of the app and site and had begun testing it internally. A lot of the functionality that we hoped to have on release day was still missing, but it allowed us to test the concept of going into restaurants, taking pictures of the food and uploading it to the website. All these processes seemed to work, although it was buggy at times and steps needed to be taken to improve the UI flow.

By the end of June, we had completed the overall design of the app and website. Testing continued, but it was still buggy. I was hesitant to get beta testers involved since I could already see the major problems.

In order to meet the deadline of having the app available on July 18 (day of our demo), we would need to give Apple at least a week to approve it. Having heard horror stories of submissions taking a long time to get approved, I set a last case deadline of July 7 to submit the app to Apple. That would give Apple about 10 days to approve the app, which I felt confident with.

By July 5, the app was still in a super buggy state. I was worried since it wasn’t even in a condition to beta test, leave alone submit it to Apple. I reminded the team of our upcoming deadline.

An amazing thing happened - the team worked endlessly on the app all day on the 5th and 6th. By the 6th evening, I was provided with the latest version of the app that I was actually impressed with. All the main functionality worked without issue. There were just a few points to fix and voila, we were able to submit the app on July 7.

Woohoo! Now the waiting game began for Apple to approve it.

In the mean time, I started sending out builds to users to beta test. Yeah, yeah, I know, kind of silly to be beta testing the app AFTER you have submitted it, but I was still confident.

The beta testing was quite eye opening as it introduced a lot of issues that we weren’t familiar with. Usability was a big one. We knew how to use the app, but a lot of the features that were apparent to us, weren’t apparent to users.

We decided to add an intro screen that described the key functionality of the app.

We also found users trying to do things in the wrong order, which caused errors to pop up that we weren’t aware of (silly users!). We quickly patched up those errors as well. It looked like we would have a new, updated version ready to submit as soon as the old one was approved.

While we were waiting, we began preparing for our demo.

As detailed in our previous post, we are in the process of developing an iPhone app and website combination, that we plan to demo next week. In order to do that, we need our app to be available for download on demo day. That requires a few steps:

1. Register our company developer account with Apple.
2. Submit our app to Apple
3. Wait for Apple to approve our app and make it available for download, hopefully before demo day.

During the company registration process, I made the mistake of submitting our Taiwan address with the company name, even though it is a US registered company in Delaware. As a result, Apple promptly asked for our “uniform number”. It took me some time to figure out what this was, since I assumed it was something that US companies had.

It turns out, they wanted our 統編號碼 which is the company registration number that every registered company in Taiwan has. Since we are not a registered company in Taiwan (yet), we didn’t have this number.

Apple sent me an email asking me to call them back. So I waited till midnight for their US offices to open, then called and explained. The person on the phone asked why I didn’t call their local number in Taiwan. I explained that I prefered to speak to someone in English. He then informed me that the staff for the Taiwan office were also located in the same call center in the US, so I could use them next time (good to know!).

After explaining the situation, he suggested I reapply but to put our US address. So I did. The next day I received an email requiring me to fax our company documentation to them. I did that too.

The following day I received another email asking me to call them back. This time I called the local Taiwan office during business hours. Sure enough, I spoke to a lovely sounding American. However since he was in charge of East Asian affairs and we were applying as a US company, it took him some time to figure out what the issue was.

The issue was that they wanted a stamp on our certification document from the state of Delaware, certifying the document. I looked through the documents I had, and found a document with a Delaware stamp. However it was a document certifying the organizational meeting minutes for FoodJing, Inc. I faxed it in anyway, hoping this met their requirements.

Unfortunately the next day I received the dreaded “please contact us” email from them. This time I waited till midnight again to call the US office, since they would be more familiar with the matter. They insisted that they needed to see the stamp on our certification document itself.

I contacted our incorporation agent who informed that such a document could be obtained from them for $85 USD. I paid and he was nice enough to send me the document a few hours later. The next day I printed and faxed this document to Apple. Fingers crossed!

A day later I received the dreaded “please contact us” email again from Apple. What was it this time?!? I let the clock tick down to midnight then called Apple.

We just wanted to let you know that everything looks good and we’ll be sending you a confirmation email, after which you can make your payment for a developer’s license.

Woohoo! They could have just directly sent me the email, but maybe Apple likes to see people sweat. You appreciate results more when you have to work hard to obtain them!

Sure enough, I received the email a few minutes later, after which I proceeded to make my payment of $99 USD.

• Pay by credit card - check.
• Enter card number and expiry date - check.
• Confirm billing address - check, wait, what?

It seems that the billing details were automatically set to our US company registered address. It would have been nice to have a company credit card, but I didn’t have that (yet?). The address could not be changed.

Well this can’t be. Since it was already 2 a.m. by this time, I called Apple back to ask what gives. Unfortunately the response was “it is what it is”.

I could have called connections and borrowed someone’s US credit card number, but this was the card that would then be assigned to our account. Meaning we could then purchase apps and music all day long, which would be automatically charged to that card. That wouldn’t be nice. And we didn’t want to have that temptation hanging over us.

Fortunately, there was a plan B. The other payment option that Apple offered was an Apple store gift card. However it had to be a US Apple store gift card, as opposed to the umm… Taiwanese Apple stores (which don’t exist AFAIK).

I looked on their website to see if such a gift card could be purchased online, and sure enough that option existed. However it would then be delivered to a US address. I needed the number imprinted on the back of the card, and couldn’t wait for it to be delivered.

I then emailed a friend in the US to ask if he could pop down to an Apple store and get me a card. He required that I call him to verify the details, to make sure I wasn’t a Nigerian scam (smart guy he is!).

A few hours later, he emailed me the card details, which I then used to purchase my developer license.

We were all set! Now, all we need is an app to submit. More on that later.

It’s been a while since we’ve reported on anything here, but a lot has been going on behind the scenes.

We had tried a few different “pivots” at Startup Labs, none of which really stuck, especially since we needed a model that we could replicate once we got back to Taichung. So it was actually back to the drawing board once we got here.

What were some of the actions that people were taking with regard to food, that we could turn into a business?

What were other mobile apps in the food discovery market not doing that we could focus on?

We know that Taiwanese like their smartphones. And we also noticed that people like to take pictures of food. Looking back at the posts on our Facebook page, pictures of food seemed to get a lot more likes than generic posts and articles. So it seemed that an app that focused around photos of food could potentially do well.

Looking at competing apps on the marketplace there were several restaurant directory ones, as well as ones with curated listings. The gap in the market seems to be food apps focused around photos.

One of the failures we had before in focusing on menus, is that the success depended on us constantly adding and updating menus, which proved to be an arduous process. So perhaps a crowd sourced model would produce better results.

Looking at the western market, there are several popular photo apps doing really well (Instagram anyone?) that local Chinese speakers seem to be missing out on, due to the lack of a local Chinese version.

So it seems that we could benefit from seeing what is working in other markets and developing a local version, geared around local habits.

With that in mind, we are now proud to announce a new version of FoodJing. It will be a mobile app (iPhone to start with) / website combination that focuses on pictures of food.

Here’s our new icon that we hope captures this purpose:

The product has been in development for the past 3 months. The problem, as found in most projects, has been deciding what features we want to put in now and which to shelve for a later date.

Our main priority was getting a working version out to users as quick as possible so that we can get feedback on whether we’re on the right track or not.

A few weeks ago, we had the opportunity to apply to present at the IDEAS show in Taipei in mid July. At the moment, the site and app are far from being ready, but we know that it would be a great opportunity to relaunch the product.

To have the product ready at that time means we will need time to submit our app to Apple to approve on time. Apps normally take a week to get approved, but to err on the side of caution we should give them more time than that.

Oh, I suppose we should register our company with them too while we are it. How hard can that be? Details coming soon.

Over the past two weeks, one of the biggest constraints of the Startup Labs experience has slowly become one of its biggest benefits. Time, or lack thereof.

Three weeks is a dangerous amount of time since it sounds like it should be enough to validate a concept and test it out. However when you add in the time required to market it, iterate, retest etc. all of a sudden you find yourself in the last week wondering what you’ll have to show for progress once the three weeks is up.

And that’s where we found ourselves, going into our final week. Our two day launch hadn’t produced any significant user traction. We had some ideas on changes we could do before launching again this week, but with public holidays the first two days of this week that only left two days before our demo to get this right. And who knew if we would get that right?

The irony going into this process was that everyone had told us that the toughest part of our business would be getting restaurants to sign up to the program. When we did that, we assumed we were off to the races. But now, even with all these restaurants on board, it was the end user who was rejecting us!

This led to some major introspection for us on Monday morning of the final week. What was it that we hoped to accomplish as a team during Startup Labs and more importantly, what could we take back with us to Taichung at the end of this experience? This led to some interesting conclusions.

1. Even if it was shown that targeting office workers was a good idea (which at this point seemed unlikely), this would not be an easy model to replicate in Taichung, as there are less office buildings to target there.
2. With only a week left, we didn’t have time to build a new prototype and start testing it again.
3. Whatever model we ended up choosing would need the approval of both restaurants and users (go figure!).
4. One of the emphases of the Startup Labs program was a focus on user acquisition as well as developing potential revenue streams. Our main reason for pivoting from the original menu model we came in with, was our user acquisition progress was quite slow, with no sign of revenue anytime soon. 

With all this in mind, we looked back at our original presentation that talked about getting restaurants to offer check-in discounts to influencers. The current plan of action for that model was:

1. Seed initial content (menus) on site to attract users.
2. Create additional features on the site to foster user engagement (submitting pictures and reviews).
3. Create a mobile version of our site.
4. Add check-in functionality.
5. Approach restaurants and boast about the number of users and engagement we currently had.
6. Sell them on offering check-in deals to our users.

With 5 days left till our demo, we certainly didn’t have time to go through all these steps, many of which would have to be validated along the way. 

What if there was a way to speed up the process of validation? We had experience with this early on in the program, selling restaurants on our concept before we had designed it. The missing step in that approach was that we hadn’t bothered to sell the users on it as well.

So now we needed a way to validate this concept by selling both users and restaurants of our concept in 5 days. 

Looking at the original plan, it looked like there were steps that could be cut from there. If the value we are creating for the user and restaurant is the check-in, then the menus and photo uploads, while nice, are a bit of a distraction. So maybe we could start with an app that only let you check-in.

There’s already an app out there that lets you check-in. It’s called Facebook. (Maybe you’ve heard of it). What if we could leverage that to begin with?

From our experience last week, we know it’s possible to sell restaurants on concepts before they are ready. Maybe we could do that with users as well. So all we need is to hone down a concept, hopefully leveraged around some of the work we’ve already done, that both users and restaurants have committed to using, before we have to implement it. To do so, we’ll be going through the following steps in the short time we have left:

1. Create a new Facebook page for users in Taipei who are interested in getting check-in deals.
2. Aim to get at least 1000 likes on this page. This will tell us that we have a willing user base to work with.
3. Find restaurants who are currently offering check-in deals and let them purchase the option to market their deal directly to our new user base.

Accomplishing the above will give us a strong base for developing our own mobile app, which could then offer additional services like loyalty programs for users and restaurants.

Who knew that all the time constraints put on us would force us to eliminate unnecessary steps that we would normally take, and instead focus on validating models before implementing them, since we didn’t have time to get it wrong. Maybe there’s a method to this madness after all!

Our original plan for these three weeks was:

• Week One: Develop Concept
• Week Two: Build Concept
• Week Three: Test Concept

Things were going smoothly until we found out that Monday and Tuesday next week were public holidays, so we would have no users to test on. That meant we would have to test this week which meant we had to have the platform built… yesterday!

After a few days of 12 hour shifts, it was ready to launch. We now needed to print some flyers to promote ourselves.

Step One: Buy the paper

Step Two: Make hundreds of copies. If only there was a 24 hour copy shop near us…

Step Three: Prepare flyers for distribution

Step Four: Hand out flyers.

Hmmn… who knew that it rained in Taipei?!?

Step Five: Man the phone lines

Step Six: Evaluate Results:

While the promotion drew traffic to our site, the sales weren’t there. Why not? 

Exit interviews suggested two reasons:

• The heavy rain meant people didn’t want to go out to get their lunch.
• While users we explained the site to, liked the concept, new users didn’t understand it.

We have now added a new landing page to explain the site, and plan a bigger launch tomorrow. Let’s see how it goes!