Hacker News new | comments | ask | show | jobs | submit login
Don't bother creating a mobile app (medium.com)
242 points by marwann on Dec 10, 2015 | hide | past | web | favorite | 175 comments



This is a productivity app, and productivity apps are a real hard sell on mobile. Think about it, you're asking someone to embed a particular piece of software directly into their life. It has to provide so much value over not having any app that they have to remember to use to make using it a no-brainer.

Your app isn't really competing against other productivity apps, it's competing against the fact that an app is not going to be most people's best approach for improving their lives. The process of integrating a tool with life is not fun, it takes work and there's only so much that things like reminders can do for you.

I use two productivity apps on my phone. Reminders and the one I'm building. It's an ongoing experiment in how one can use software to improve life. Right now the only thing I've managed to integrate is spending tracking, and even that took months of back and forth consideration. Do I want to tag individual expenditures? How do I want to categorize them? How do I want to add an expenditure to a category? What should I call the act of spending something and what should I call the category? How do I want my reports to look like? Do I want reports in the database, or should they be generated dynamically? How should I represent common transactions that I do every day in a way that doesn't clutter up the main interface?

The whole exercise has left me unenthused about productivity software as a viable product category. Adding an expenditure now is easy as pie, for me, and only me. All of the work I had to do to figure out how I spend money and how I should build an app to manage it essentially has to be redone for every single person who wants to use software to help them manage their life. The domain seems simple, but it's actually incredibly complicated, because it's different for everyone.


You touch another important issue here.

>>> Do I want to tag individual expenditures? How do I want to categorize them?

Friction.

There are a lot of apps that might be useful but the friction is so high (a lot of manual entry, etc) that it might overwhelm the value provided. Ideally, you want the app to 'just work' and that's the hard part.


And it's not just mobile apps that suffer the problem of friction. Last night my wife sat down to put a holiday card together on Shutterfly. When she had it to her satisfaction she started the ordering process. A message displayed on the site telling her that she needed to login. She dug out the user name/password and logged in. Her card was lost. I tried for 15 minutes without success to get it back. At 11:15pm, after a full day of work and family activities, she had to start over. Her comment to me was, "Why the hell does software have to be so hard to use?"

Excellent question.

(Note, we've had issues with Apple's service as well, so I'm not trying to make a point about Shutterfly's service being better/worse than competitors' services. I'm just using Shutterfly as an example of a mature service creating friction for users.)


> There are a lot of apps that might be useful but the friction is so high (a lot of manual entry, etc) that it might overwhelm the value provided.

It was an act of faith for me to structure the app around manual entry of transactions. I thought for sure that I'd wind up abandoning it after a few months. Didn't happen, I'm still using it, but I remember for a few weeks struggling to eliminate the friction, and I still haven't gotten rid of all of it. That would require implementing some kind of custom keyboard, as well as the aforementioned interface to put in common transactions that have the same amount each time.

There needs to be a streamlined interface for adding these common transactions, because I might have to do it a few times a month.

I'm repeating this entire process for a to-do manager, as Reminders just doesn't eliminate enough friction for all use cases. Now I need to figure out how to get transactions to live on the same page as my agenda.

When I'm finally done with this three years from now, I'll need to write a book and do a bunch of YouTube videos to teach people how to use it productively, either that or I'll need to spend just as much time making the interface discoverable.

What other people will need out of a dashboard is bound to be completely different than what I need out of it. I have a list of transactions for this week, broken down by day, someone else might need the whole month, broken down by category. I don't have automatic recurring transactions show up, someone else might want those. Each of these requires significant design work.

I have tried at various points to interest someone else in helping me develop it. Ha. Ha. Ha. Nobody cares.


You could look at the ecosystem around the Ledger command line accounting program for ideas about simplifying transaction creation.

People often bring up Ledger because it uses a text file as input, I don't mean to point at that, I mean to point at all the various heuristics people use to extract meaning from their history of transactions.


I'll take a look at it, thanks.


Good on you for persisting with it.

I developed a mobile manual entry personal finance tracking application as well, stuck with it for two years, but I'm back to manual entry using Ledger because of the pain in the ass it is to enter data on mobile, whereas I can use automation to import my various bank accounts data (e.g. https://github.com/cantino/reckon) with Ledger.

The reporting on the data is the gold, for me, the mobile app didn't really add that much value, so I just gave up.


The canonical budgeting advice is to simply track when you pull cash out, and count any cash you withdraw as already "spent".


That's hardly 'canonical', and goes directly against many budgeting/tracking philosophies. It definitely doesn't solve the 'where'd it all go' problem, and teaches you nothing about your spending habits and patterns.

Of course if you don't have any money problems, and don't need to break bad spending habits, then go ahead and do it that way - I often do as well.


Of course it teaches you stuff about your spending habits and patterns. Cash withdrawals are either earmarked as you withdraw them (for example, hitting an ATM up before visiting a strip club or bar), or they're withdrawn for facilitating impulsive purchases. You know the category of things they go to, because you record it when you withdraw it - you just don't know exactly what you did with it or when.


I think this only works if you follow a "zero based budgeting" philosophy.

https://www.daveramsey.com/blog/zero-based-budget-what-why


If people would have the patience of building a habit using such apps, there wouldn't be a friction problem. Time spent on FaceInstaSnapCrush is also manual labour, but so much more fun. /s


If they had the patience to use an app, they would have already built workflows to do it without apps. My grandfather uses ledger books, pen and paper.

I used to think there was a large enough market of people in between the already organized, like my grandfather, and those who can't organize, period, like my sister. People who, if they just had the right app and could be convinced to put in some minimal amount of effort, could get organized.

Now I realize that software is the wrong tool for the job.


> Now I realize that software is the wrong tool for the job.

tl;dr: most productivity apps are marketed to disorganized people. I say target the already organized and make their lives easier by automating all the things.

For getting lazy or disorganized people organized, yes, that's going to take more than software. But, there may still be a market for taking the result of the manual process (like the one your grandfather uses with ledger books) and digitizing it. For example, "whitelines link" are notebooks that make it easier to digitize written data cleanly by taking a picture of it. Evernote (or any competent OCR program) could then turn that clean digitized version into text. From there, all the data could be organized, broken down by category, etc. You could automatically generate any number of reports based on that information and, most importantly, it's all backed up in case something unfortunate happens to the physical ledger.


> they would have already built workflows to do it without apps

I'd argue that the effort and workflow used without apps is larger then with them. So if someone can't be bothered to even use the apps, it most certainly isn't doing it "oldschool".

> My grandfather uses ledger books, pen and paper.

Well he had to do it manually before the age of the smartphone (and when people had more patience).Your grandfather would also probably find carrying a point and shoot camera and a map around to make sense.


Your experience is actually the same one I have when writing enterprise software. I always start an enterprise project with a vision of people happily using a good product to achieve a goal. After wading through conflicting user preferences, the Legal Department chiming in, etc, I realize the the application is going to be a Frankenstein monster. At that point, the vision is shattered and I try to produce something that is somewhat useful, to as as many people as possible, and with as little friction as possible. Compromising the vision always sucks the enthusiasm from me.


I feel you... Legal department requirements alone can make software unusable... I maintain an universally reviled application that requires you to print, sign and physically mail any changes to the user's address or other data (because legal), and that people have to use because it's output is a requirement for many bureaucratic procedures, which usually are needed ASAP... it's a usability and support nightmare.


There really should be a support group for people who have to support systems like you describe. (Sympathetic sarcasm, of course.)


In general, I find that with respect to tracking expenses, if you do something, anything, organized so that you remember it and have the appropriate proof to be reimbursed you've won at least 80 percent of the battle. At least for me, it's not so much about having a properly categorized/filed electronic copy as having something to remind me that I bought a coffee at Starbucks.

To your broader point, a number of years back I was looking at software to track consulting activities at our company. One of the things that struck me was that the utility of the software out there depended a lot on the type of activity you wanted to track and how you wanted to share it. Lots of independent and largely discrete events called for a different solution than larger projects with a defined workflow and milestones.


This really struck a chord because I've spent the last couple years working on a productivity app and it took me a few iterations to get people coming back. It uses spaced repetition to help users remember what they read on the web. I feel like I've removed a lot of the friction of apps that did this before (Anki, Supermemo) by making it really easy to add information to it. It would be possible to replicate it with a simple word processing tool, some copy-pasting, some typing, calculating review intervals, and adding reminders to a calendar to review a specific portion of a document. By eliminating that friction, I've appealed to a small but growing crowd of people, like us, who are too lazy for the pen and ledger approach, but are willing to put in some work (in this case, to reread a few lines of text each time they get a notification).

The "productivity" designation is an inadequate one. There a few obvious productivity apps that translate well from processes that people are used to in the real world, like note-taking apps, that don't require much education for the user to understand. It's a notebook. Cool, got it.

Onboarding is such an important facet of this discussion, and you do mention it below:

> I'll need to spend just as much time making the interface discoverable

Unfortunately, developers do get so close to their product that they forget that users often don't know where to start, so I think that having to build an onboarding process is something to be expected. Education is the only way to make one UI for many people. I think the questions that need to be asked are: 1. How long is it going to take to make my users proficient at my app? 2. Can I make it fun for them?

I don't think the moral of the story is "Don't make productivity apps", I think it's "Don't make an app that's hard to explain to its users"

Unless they have an external pressure like: - In the case of B2B, complying to company policy (Slack) - In the case of B2C, it's social and everyone is already on it (Facebook)


> This really struck a chord because I've spent the last couple years working on a productivity app and it took me a few iterations to get people coming back. It uses spaced repetition to help users remember what they read on the web.

I wouldn't exactly classify this kind of app as a productivity app by my thinking. I would call it a utility app. I'll try to articulate my rationale.

A productivity app, in order for it to be useful, has to take something people normally do as a routine task in their lives, like make purchases, somehow better / faster / more queryable / whatever. It aims to make everyday life better.

A utility app aims to take something people have already chosen to make a real effort to do, like learn a language, and amplifies their efforts. Once you've chosen to undertake whatever task underlying the app, 90% of the onboarding is already done. Now it's a question of choosing which method or app to help out. Utility apps really do compete with other apps in their space.

This is what separates enterprise expense tracking with what I'm building. Enterprises already have the legal and financial need to be aware of what they're spending, enough so they can hire people and pay them money to make it their quest in life.

Most people, well, don't. They have this amorphous understanding of what's in their bank account and how much they have to spend and what their bills are, seeing this all down in black and white is likely only going to depress them. Even if their corporate job is accounting and they already have the skill to manage accounts, that won't necessarily translate into the need or desire to do it in their home life.

A productivity app, as I've defined them, is categorically interested in changing a person's lifestyle. It's the whole point of the app, without lifestyle change there's nothing. I fully intend the to-do manager I'm building into my personal app to fully overtake how I conduct my work day, my after work time, and weekend time. That's the whole reason I'm building it, the vision in my head of how awesome that would be is so compelling, that it's worth spending 10000x the time I would spend earning the money to buy someone else's app, on building my own.

It is for me, by me, can only work for me, because only I had the thoughts and lifestyle that makes building it worth it. I believe that this kind of integration is the desired end point of all productivity apps, if it doesn't accomplish this, then it's really a waste of time, bound to eventually end up in the dustbin.

I read GTD awhile back and thought it was amazing. But there's a real reason he never really endorsed any software tools or made a software tool a primary component of his system. My to-do component is heavily GTD-influenced, but it is designed to work with other, physical aspects of my life.


There is plenty of money to be made in this space. KDS [1] for example are selling their solution into large enterprise clients, each with thousands of users paying per user pricing. Enterprise money and enterprise deals.

Expense management is a challenging market with lots of issues that need to be addressed. For example, there are lots of legal taxation rules concerning the digitisation of receipts and invoices, and each country does it differently.

Now they've built their new app on top of Slack's API. I can't see that going well long term. Haven't people learned already not to build businesses on top of walled gardens?

[1] http://www.kds.com/


Lots of money out there, but you can't make it by fixing your own needs and expecting that design to work for bigcorps. Really it's two different product spaces.

You need big money development, meaning big money firms. I'd just prefer to let them do it, and move on to some other promising niche. I'll develop my app for me, because no other app will do it the way I need it done, and not try to productize it, it's a waste of time.


It's always obvious when you are dealing with founders who likely won't make it. Specifically, when they're so so close to their own product that they start to blame anything else for failures rather than take an objective look at their own missteps.

In this case, buried among some semi-coherent arguments, we reach the point where one should ask "Was this product compelling compared to other solutions that tackle this pain point?"

Obviously not, but don't expect the company to smell the coffee. In their opinion, their "few competitor apps" didn't matter, but they lasted longer, so they probably did. Oh, but of course "they weren’t doing it as well."

Take a look at the comments rolling in here, some of which note that the product didn't seem like compelling standalone option but that would have done well as part of a larger solution. Others inquire why certain features were left out that would have adequately addressed the entire pain point, but left the product feeling incomplete otherwise.

Of course, these potential customers were all wrong, because "other apps felt heavy and complicated."

Founders considering mobile, don't make the same mistake(s) this company is making. Rather than write some clickbait Mediun post after the fact, remember that a great UIX, onboarding and maybe even a mascot might be necessary for mobile success, but they definitely aren't sufficient. Nothing beats product market fit, and if a mobile app is necessary for said fit, you better not only bother with mobile, you should embrace it...objectively.


... we reach the point where one should ask "Was this product compelling compared to other solutions that tackle this pain point?"

Or even, as might be the case here, "is this even a pain point that needs a product?"


"the product didn't seem like compelling standalone option but that would have done well as part of a larger solution"

The new approach as a Slack bot addresses that issue precisely. Lots of useful things aren't a compelling standalone solution. Slack bots and other in-messenger apps mean this kind of software can become part of a larger overall experience.

Don't know if Birdly will make it but their argument here is onto something.

https://www.getbirdly.com/


I don't know that a Slack bot is the right type of larger solution though. For instance, I use the ExpenseIt app on my phone because it's paired with Concur. That's got a much more flexible input when it comes time to do the actual expense report, and it's already processed all of those receipts for me. Now I just need to go through and pair it all up with the transactions on the card. Is Concur perfect? No. But the ExpenseIt app works there because it allows me to add data on the fly then toss the receipt.

I don't think I would be compelled to use a Slack bot to do the same thing, even though we use dozens of other Slack integrations.


This looks like someone trying to take the blame of failure out of their shoulders.

The questions are right, the answers are wrong. The app did not (judging by the text, I never heard of it before) add the value they thought. Maybe it did not even work as well as they thought. Actually, I doubt that.

I won't argue too much into it, instead I will give you counterexamples:

1. I should be on the target audience, and I have never heard of the app before. 2. Concur seems to be doing really fine, working on the same problem - so they have either a better marketing or a better solution.

Bottomline: don't shy people away of doing anything because you failed.


The app was only distributed on the French app stores, which is why you may not have heard about it. We're not trying to prevent anyone from creating mobile apps, but after spending a year doing so (and sure, making many mistakes on the way), we're just sharing our humble piece of advice


Wait, what?

Hang on, this should be the number 1 point of your entire blog post. Honestly, if your post was titled the obvious "Don't make mobile apps only for one region" then you'd be getting a lot of comments saying "Well, obviously".

Seriously your problem here is not that you made a mobile app. Your problem is very clearly that you excluded 99% of your user base. Any chance you can explain the reasoning behind this..? I can't even begin to understand it. Outside of government required tax applications, I cannot think of a single successful single-region productivity app ever.


I am baffled as well. My brain is hurting trying to understand this decision.


It's a decision that may seem obvious for many, many product categories.

But I can assure you that regarding anything finance-wise, it's simply impossible to launch an app that that complies with local laws everywhere at the same time, especially without proper funding. Take Quickbooks, it exists for 5-10 years, and they're still postponing their launch in the French market. We've gone global since then, and we've grown in 10 weeks way faster than we did in 1 year.


One suggestion: Start thinking about details like foreign laws once you actually start to generate significant profit.

Before that no one on earth will even care about your product enough to sue you.

On top of that it's quite expensive to go to France and sue you there as a foreigner.


I'd think they meant the state going after them. Not everyone wants to be a carefree outlaw.


I'm not an outlaw because I am ignorant of the laws and regulations of every single state on this planet. I put an app into the store that mainly follows Google/Apple policies/guidelines and does not break any laws in my country and that is sufficient for the start.

These policies are reasonable and by following them you will rarely get into trouble in Western countries.

Of course some other country might object, then the app might be modified by me for this country or removed.

How many apps or website would exist today if checking every law everywhere would be the standard procedure? Probably around 100 websites and 25 apps in total would exist because only big corps can afford this.


If you choose to sell your app in a particular App Store, you're submitting to the law of the jurisdiction it operates in.


No I don't, Google and Apple do. They are distributing the app and are responsible that the content is compliant with all the countries where they sell apps in.

Aside from that I don't understand what point you are trying to make here.

Are you suggesting that a developer should not release apps without first making sure that the app doesn't comply with any laws of any country?


It's both about local laws and local accounting customs. They are so different depending on countries that you almost have to develop a separate system if you want to enter another country. Or you keep it so simple that the value added is close to none...


Just a question. You say the following is obvious. How is that obvious? "Don't make mobile apps only for one region" then you'd be getting a lot of comments saying "Well, obviously"


"If you want mass adoption, don't build apps with a max penetration of 1% of the global population" seems pretty obvious. Other variations: "If you want mass adoption, don't build apps only usable on Blackberry".


France is a massive homogenous market with high penetration of their target platform, and large comfortable middle class. It's probably easier to pilot in France than it is in most other markets. And launching globally has non-trivial implications for cashflow & risk.


I'm sure there are some strategic advantages. But when a French-only mobile app languishes, the lesson isn't necessarily "don't make a mobile app".

And it's not something you casually forget to mention in your postmortem (ctrl+f for "France" and "French" in the original article).


I agree with your feelings about the article. It read like an exercise in denial. We also use Concur and it works quite well, and therein probably lies part of the author's problem: many people who care regularly about capturing expenses are doing so for business reasons and are told what app to use by their employer. Market research for the win.


It's a pretty easy market too, you don't even need an app, just contact any senior sales person and pitch them on a solution to do their expenses, they just have to send all their receipts and a sample expense report sheet to expenses@mycoolcompany.com.

You do a few manually, then put together scripts to automate each user with the correct sheet format, cover pages, currencies, categories, etc. by using the manual ones as a template.

Charge them a fee (maybe a flat fee for each report, say $40) and ask them if they'd like you to include that charge in the report from now on.

This is a tech solution for a services problem, imho.


That sounds harsh but is more or less accurate. It sounds like the developers fundamentally misunderstood the purpose of productivity apps on mobile. They fell into the trap I've seen a lot of others fall into, which is taking a task normally done on a computer and building a mobile app out of it, without considering why users would want to actually perform that task on their phone.

Expecting someone to create and file their expense reports entirely on a phone is absurd. Most workers would prefer to do this kind of thing at a computer, being on a phone will simply slow you down: lack of a real keyboard, tiny screen, poor multitasking, etc. There's no reason to prefer a mobile app for this task over a desktop version.

Mobile productivity apps are generally best served as companions to existing web/desktop apps. Either to provide access to your data when you're not at a computer (not really relevant for this app), or to improve the workflow of something that would normally require a computer. For example, you might consider it a pain to have to save your receipts so you can later scan them into your computer and import them into your expense tool. A mobile app can improve this workflow by allowing you to immediately take a photo of the receipt when you get it, and having that receipt automatically synced into your expense tool.

Off the top of my head I can name two companies (Expensify and Shoeboxed) that provide this ability. That these guys dismissed their competitors as "heavy and complicated" seems to have missed the point.

Taking this experience and concluding that you shouldn't build a mobile app is simply throwing the baby out with the bathwater.


1) I have never heard of you. Does this mean anything? No. He just admitted his app failed, they do no marketing and they have problems getting people to use the app. If you HAD heard of them - you would likely be spewing off "it's a mobile app with no desktop web app WTF". So - your first point is really just a jab - centered around you, not the app he wrote about. 2) concur is another provider in the space who existed before the rise of mobile apps. They are implemented across fortune 500's and many more. They have a huge install base. They are used by companies and imposed upon their employees. They have 'distribution' - which is what Birdly needed from my reading of the post. I can assure you, as a former user of concur - many people hate it. Or try TriNets incredibly terrible expense app.

I was surprised there was no mention of Expensify - which I suspect is the business they were looking to disrupt - their UI is not awesome. BUT the UX is great. Take a picture of you receipt and done, email receipts handled, etc. but I use it mostly on desktop to submit reports - and use my mobile to take pictures of receipts.

Anyhow - your last line is a bit of a doozy. Are you suggesting that someone who wrote 2000 word post about their pivot to a better solution (this slack idea is great IMO) should just shut up because it might dissuade others from making the same mistakes he did? Based on your "counter examples" - I think he did the right thing. I hope OP keeps sharing his learnings - because it encourages me to keep trying different approaches. AND I'm going to install his slack bot for my whole company (giving them distribution). I hope you can hide under a rock so you don't get dissuaded from doing something. Sharing is caring, even if they failed.


Productivity apps are never in top 10 on app store. The efforts you spent building your app did not pay, but I don't think you should blame app store for that. I would suggest not to take it as a failure of the mobile app concept. Learn form your experience and think about what you can improve.


PDF Expert and Notability are in the bestseller lists right now. There have been productivity apps in the charts, although they don't dominate.


This tells me a lot more about the founders not understanding the market than about mobile apps in general.

> The mobile app was doing something really cool: you only had to take a snap of a receipt, and tap a button to export all the data into a beautiful Excel expense report.

That's a feature not a business. That feature already exists in all of the major expense tracking SAAS products that I'm familiar with.

So who is the target market? The sliver of people that have enough of a problem to want to buy a solution but not enough of a problem to buy the major existing solution is just not that big.


I was going to say something similar, but I think you put it better. "Had it been done a million times?" They say nope, but I think they were looking in the wrong area. It may have done bad in standalone apps, but that's not where the real competition was. It was a small feature in many apps. I know I keep an app for this exact purpose on my phone all the time, even though I use it once every few months. The problem, for them, is that the app is part of the expense reporting software we use at work. I think there was no real way to sell this app as a standalone thing. It needs to be connected.


I think it's hard to give people the big picture of what the thought process looked inside the company in a 5-mn read. We've cut through some info to focus on a unique message, but we know our target market, researched as much as we could, conducted (literally) hundreds of interviews, tried to determine painpoints, use/edge cases, etc.


I can't find the app to see exactly how it worked, but did it have any integrations with expense reporting systems? As someone who files expense reports monthly for work, that would be the biggest issue for me - if it doesn't have a hook into QuickBooks or whatever system the company is using, then it's not going to get an enterprise following since users still have to manually enter info, which decreases value a lot.

The other issue is that if, like me, you travel a lot then a large number of your receipts will be in emails or PDFs (I book airfare and hotels online, and take Uber instead of cabs), so taking pictures of paper receipts and tracking driving miles would only get me half-way to completion.


They didn't mention this in the article, which makes me wonder if they really understood it. Companies have specific tools they require you to use to file expense reports. You would have to get the entire company to embrace this solution. Although they talk about the CTO trying to get it installed, I wonder if they ever really got the whole company on board. You've got to get the CTO and the CFO in this case.


It just doesn't work that way, the best audience for this is big co (because the combination of strict expense rules and big sales force makes it perfect) and yet it is absolutely impossible to get an enterprise signed into something like this.

Yet when the sales guys are putting in their expense reports every month (because it's too much money to ignore it for longer than a month) you could save them time with something like this, and guess what, they can expense the cost too, but only if you give them a report that is ready to send in the format they need it.


I'm the target market for this app, as I lose hundreds of dollars a month in unclaimed expenses.

This is completely useless for me, it was as an app and even more so as a slack bot - I work in the sales department of a large co (as will the most profitable segment for this kind of app) and here's the things you would need for anyone at my workplace to use it:

- Concur integration of some kind, otherwise your "beautiful" PDF Is useless, because my expense department will not pay anything without the proper cover sheet.

- As you said, you want to give me some kind of email address* that I can forward an uber, air or hotel booking to and it will automagically add it to my expense report.

- Slack-only rules out the entire big co space as it doesn't run behind corporate firewall, so it's not allowed. If you want to integrate with a chat solution, go for Chatter, Yammer or Lync... or better yet, use email.

* Why email? because it's standard, and it's the way sales people are used to send tickets to salesforce.


True that. Before moving to an "invisible app", we were developing integrations for such accounting software, and we had an email forwarding function as Uber was also a big part of the expenses filed on our app. Still, a SaaS like ours had a hard time living only on mobile, and through our own mobile app


Sorry, but this article is pointless. There are no numbers whatsoever, everything can be squeezed down to "if it's not a messenger or a game¹, people won't use it", and there's not even meaningful comparison to any alternative approaches. Like the users that forgot the app magically won't forget to talk to that Slack bot once in a month.

Literally, this article is nothing but an advertising for a refreshed product, with some wanna-be-viral-marketing attempt at sparking discussion by somewhat controversial statement of "not on app store". (Uh, sorry for being cynical here, but seriously...)

___

[1] Not a full list.


Sorry you feel this way. It would be nice to update the article with actual figures indeed.

And if I had to squeeze down the article, that'd be : "if you app doesn't imply repeated use, doesn't leverage context, takes room in your phone, if you don't have the necessary resources to develop it and update it on all platforms, and if it has to be integrated to a professional workflow for many users at once, don't go for it"


Without numbers, however, it reads like you're just making educated guesses.


Even with numbers, a whole lot of things in this world are nothing more than educated guesses. Or did you already find the meaning of life?


Looks like they replaced the app with a Slack bot. That is more interesting than the article.

There are some services which would be more convenient as a bot on a chat platform than a "portal" site or a mobile app. Some issues with service-specific site / apps:

- password that's perpetually forgotten (unless the site plays well with the password manager)

- proprietary, doesn't explicitely support integrations unless the authors implement them

- yet another set of notifications to deal with.


Totally agree - when I saw the pivot to Slack, I thought "That is REALLY interesting, more interesting than their failure at mobile"


I suggest you have a look at this article we wrote about Slack as a platform: https://medium.com/inside-birdly/there-s-no-app-for-that-sla...


It is obvious what people want. A single app that does it all. Seriously.

We need a general purpose application that can be used for 80% of all use cases. When you think about it, all apps pretty much re-introduce the exact same features. Preferences, contacts, notifications, authentication, sharing, etc.

I want to use the exact same interface and language to order a package from China to my house, or to hail a cab to move me from work to home. I want the estimated ETA and cost prediction to be displayed the same. Tracking a package or the real-time location of a cab should be done through the same interface. I want to be notified the same way, whether it's my package or my cab that's late and/or has arrived. I want to pay for the package and cab ride the exact same way. Reviewing the received product and reviewing the cab driver, should be identical processes. I think the same should apply to pretty much any interaction, be it to ask my coffee machine to brew a cup, to be notified that my colleague will be late to a meeting, to pay for a meal, to review a movie, to schedule an appointment, to locate a friend.

My thesis is that all communication problems (which are what apps solve) are difference instances of the same one.

An app is not any tool. It's a language. We need to implement a general purpose language, and then all use it to interact with different agents/services.


> It is obvious what people want. A single app that does it all. Seriously.

We need emacs mobile!


But text is an evil medium.


> It is obvious what people want. A single app that does it all. Seriously.

This is the vision of SIRI. Now you know the goal. Please deliver.


Siri's mistake (which also applies to Cortana and Google Now) is to bet on natural language. I seriously believe natural language to be a mediocre interface, and we have the opportunity to do much better. We need to create a completely new language.


This is actually a really interesting point. So we have English (optimized for person->person), standard programming languages (optimized for text->computer), and now you're saying we should make Language X, which is optimized for speech->computer.

I disagree with it, but it's still interesting :)


We need a language optimized for human->computer->human. We already have a few, they're called GUIs. But there's little to no standard surrounding them. Sure, some patterns like "x" to dismiss something or pinch to zoom are widespread, but they don't constitute a complete language.

The binary equivalent is Akinator [1]. It's big on Tinder too.

Basically, you want a language that lets you point at things you don't like. This gets converted to a need, which is then communicated to an array of agents whose job is to come up with solutions. Then enters the flow where you pick a solution (most of which come with conditions, such as completion time or cost), which then becomes a contract that feeds the timeline/calendar/task management system that drives your day to day actions. There's not a lot more to it.

[1] http://en.akinator.com/


Akinator UX is like a marketing survey, a bit tiresome after the first dozen questions with no end in sight.


Yes - natural language is dependent on facial expressions, tone of voice, shared mutual history, shared culture, and so many other things that you don't have, or even want, when interacting with a computer. People can learn a set of imperative commands for interfacing with an AI. People aren't dumb. But the execution has to be good enough to make it worthwhile.


Problem being that you're now relying on the willingness of people to learn your new language, which creates a friction point, like someone here was talking about.


Check out WeChat. They have a lot of work to do, but they're basically embracing this idea of a universal language for all computing tasks.

In their case, it's centered around messaging but can cover a wide range of uses.


I heard about WeChat a long time ago, but I've done some research about them just the other day and I was amazed by the array of services and use cases they manage to cover.

I'm not a big fan of the way it's implemented (it's like nested web-based mini-apps), but it's much better than anything we have here in the West.


How would you implement the meta-app differently with the constraint of extensibility for third-party services? E.g. should the app be updated for each new service or use a central broker? What's the separation/security model for user data that is private to the device, visible to central broker, visible to all 3rd-party services, or visible to one service?


You start with a semantic knowledge graph. Then you program agents that manipulate that graph. Think semantic web. Nothing is centralized.

The challenge is the UI. We need some kind of AI that understands the context and user's preference in order to dynamically generate the best interface, taking into account both data consumption and input.


If the graph is not centralized, does that imply it is public? Or could segments of the graph be private to individuals, groups, companies, nations, etc?

E.g. the industry currently has FreeBase/Wikidata (public) and Google/Facebook/Microsoft semantic graphs (private). Would client endpoints arbitrate between these non-intersecting graphs?


Ideally, everything would be public. Not only does it make the design much simpler, but it also happens to fit my total transparency ideal (I'm not a big fan of privacy).

I have not given any thought about the co-existence of public and private graph segments.


There's the small problem of the public graph being less complete than the private graph, due to corporate investment in the private graph.


I don't see a problem.


The problem is that users will have less functionality on the public graph than a competing client which can access both the private and public graphs. Less functionality means less adoption means less resources to improve the public graph means less functionality ...


I'm confident there won't be an incentive to introduce fragmentation.

In any case, users will decide.


That's basically Facebook's model: barely good enough at so many things in one place with your friends already there. Works great for them.


- I can't buy stuff on Facebook.

- I can't sell stuff on Facebook.

- I can't hail a cab on Facebook.

- I can't unlock my doors on Facebook.

- I can't turn the lights on on Facebook.

- I can't play a song on Facebook.

- I can't pay for my parking spot on Facebook.

- I can't reserve a table at a restaurant on Facebook.

- I can't manage tasks on Facebook.

- I can't review products on Facebook.

- I can't track my sleep on Facebook.

Unless you consider Status/Messages/Comments as an interface to all these things. In which case we could all use IRC and live happily ever after. Which doesn't work because IRC is text, and text is an poor medium.


Oh, I see what you mean. Something doesn't do a lot in one app unless it runs all software on Earth in one app (or some subset thereof). I think you meant operating system or runtime platform instead of app. I recommend Android or iOS for your needs.

Back to apps and my claim, Facebook directly provides email, messaging, phone calls, group activities, meetup, games, and so on. Hence, the claim their model is to do much of what people need in one app good enough for convenience to ensure a win. No single app is going to do all on your list because users would reject it outside maybe South Korea where such a mixed bag is common. People always look for a better app with better interface, integration, price, whatever. No incentive whatsoever to build an app with your exact combination of features if 99+% of people prefer to have a set of apps best for that and aren't vendor loyal at all.

Not to mention, what startup is going to build that app for $1 or so in an app store? The functionality you describe could cost hundreds of thousands to millions to develop. With no expectation of a return. Not happening any time soon.


There seems to be some misunderstanding. I'm not talking about one app with all these functionalities as distinct features. I'm talking about one app that enables the use of a modern computer-assisted general-purpose language with which people can achieve most of these tasks. The app won't know anything about cabs, sleep, restaurant tables, doors, lights, parking spots. These things are part of a lexicon that exists outside the app, as part of the graph that powers it. Think of this graph as a knowledge base which smart (automated or not) agents can interact with.

Once you nail the UX algorithm, you don't need to manually craft unique user interfaces for all possible use cases. It is all done automatically.

Also, I don't understand where this need to discuss cost or revenue comes from. Projects that have the largest impact are not motivated by self-interest or money of any kind. What I'm describing will be entirely free, open source, decentralized, etc.

It's closer to "English" or "The Internet" than it is to "Instagram" or "Amazon".


I think you're describing what Semantic Web or agent-oriented computing (esp bots) before it tried to achieve. It would be nice but it might not be possible. The reason is it's against most vendor's and service's interest to standardize their data formats and interfaces for that level of 3rd party integration. They monetize and control more if they do the opposite.

Interesting enough, inspired by Siri and AI craze, Facebook is developing a human-assisted AI that might fit the bill. I read about it recently:

http://www.buzzfeed.com/alexkantrowitz/time-to-meet-the-wiza...

Watson might be able to pull it off, too. But most people underestimate how hard this stuff is. My stuff long ago used a Tcl variant with restricted use of English verbs and grammar. It was still difficult, slower, and so on. New stuff uses deep NN's, GPU's, etc. You might get your app in next 10 years if they keep progressing as they do.


People won't interact through natural language. That's the big different. I understand how difficult NLP is.

I'm talking about creating a completely new language, that looks nothing like English, French or Esperanto.

The plan is to introduce this language to kids through a smartphone app. Once they're hooked, the world will change forever.


Start with something like MIT's Scratch, maybe? They used different shapes and colors like legos to intuitively help kids understood what statements fit together. They ran with it and made all kinds of stuff.


If you think "build it and they will come" applies in the mobile space, you're completely wrong and about to light a bunch money on fire. I'd be very interested to know if this team talked to 25+ people smack in the middle of their target audience about their expense-tracking pains before starting to think about building the app. It really seems like they thought of a problem (or what they perceived as a problem) and then built the app. If they dove deep on the problem and talked directly to people who they thought would most benefit from the app, they certainly would have uncovered more information about why Birdly would or would not work for them and could make important product choices based on that feedback.


I use Expensify to track expenses for work and WaveApps for some consulting I do on the side. I disagree with the thesis of the piece, because I'm perfectly happy to keep installed apps that I use once per month, or even once per quarter.

WaveApps is great for invoicing, but their expense reporting module is ludicrously bad (it does OCR on the receipt images, but then doesn't include them in a nice report, so you have to download the images separately and convert them to a PDF manually).

I would have used Birdly if I had known about it. Anyone know about another Expensify competitor, preferably one who doesn't charge for single users?

As for Birdly, good luck with the Slack pivot, which looks clever.


This was a great read, and I was right with the story line.

Yep, you're right. It's hard to get to your target market from the app store. Yep, they forget about your app. Yep, Yep, Yep.

Oh look, there's a link at the bottom to the new Birdly! Let's see what their new approach is!

It's a.....slack bot? Wut?

Just being honest here: I think that's one of the stupidest pivots I've ever seen.


It's funny - I had the same reaction at the first parts, but I thought the Slack bot pivot was genius actually. Very different than expensify and the "others".

No UI...is the New UI.


Genius? So your new business model is to exclude a huge number of people (despite what you may see here on HN, most people writing expense reports don't use slack), and tie your business to a third party closed platform.

Ok...


Very different, and I imagine probably even more frustrating than a high-friction data entry form. It would take a lot of convincing for me to think submitting an expense report via bot would be better than, say, putting receipts as attachment in an email and sending to a person.


I am using a mobile app to track the milage of my car and thus pull it up only at the gas station. While a little more specific than general expense tracking, it seems to be similar enough for a comparison. According to the article these apps are a hard sell because they are used so rarely. I can't comment on how the app creator is doing but it's still an app that I would pay for. But maybe the market is too small and the simplicity of the app creates an unsustainable race to the bottom.


Me too! It's an Android app called aCar which I did end up spending the $5 on (for no ads and IIRC more advanced backup options). I use it infrequently, but A) it takes less than a minute to enter a new "fill-up" record right after I get gas, and B) I programmed in all the reminders for oil change, tire rotation, etc., so entering the fill-up records (with mileage) means I keep on top of maintenance.

It provides value (B) with no friction (A), so pretty much a no-brainer.


To track car mileage I get out the manual and look up the size of my tank. Every time I fill up I reset the trip odometer in the car. At fill up I calculate the mileage. It's so easy, why is an app needed for this? May be the calculator app but that's all that should be required unless it's doing something else.


A) Why would you need to look up the size of your tank? The gas pump tells you quite precisely how much you used since last fill-up

B) Nobody said they needed an app for this

C) I'm not really sure how pulling up the calculator app and punching in numbers is any easier than pulling up the mileage app and punching in numbers

D) If you use your imagination very slightly, you can come up with other obvious features such an app would provide, such as tracking average miles driven per day/month/year, average MPG per day/month/year, gas prices over time, service records (when was the last oil change/tire rotation/brake job), etc.

E) I also explicitly talked about another feature it provides (reminders), so I don't get the impression you actually read my comment before replying


I think you're one of the exceptions, figures showed people were mostly opening it once a month, and not contextually as we wanted them to. We're still on mobile, but without an app now! More about it here: https://medium.com/inside-birdly/there-s-no-app-for-that-sla...


I wonder if they considered breaking the app up into smaller parts that can be sold to different markets:

  * API that accepts the scanned images, parses and returns the receipt data.
  * API (that does the above and) stores the data to allow later exporting of
    receipt data in Quickbooks, Excel, and other formats.
  * IOS and Android Libraries that integrate with the API.
  * Birdly app build on top of the library and API.
Birdly could be used as an end-user application, but also as a showcase for the API usage. Other application developers could license the libraries and API from your service; sure it creates competition, but you'd be getting a slice from a larger pie.

Also if there was a solo API plan, I would probably consider something like this for some personal expense tracking software I've been thinking about writing for myself.


I've always been curious how, in this business model, you protect API tokens if the users of the API deploy mobile apps. Embedding them in an app isn't secure: anybody could reverse engineer the app and use the key for themselves free of charge. And there is no way in Android or iOS to know which app makes a request from the server.


You can create a sneaky change to the protocol, or something that looks unnecessary, but still works without it temporarily. (or check the order in which the headers are formed, or something.) Then you can detect which clients don't conform exactly to the internal specs. And then you can send those accounts an email telling them they'll be banned if they continue to use external clients.

This strategy only works if you have a single blessed version of a client, and it's really only because of security by obscurity. For the mentioned business model, it would not work unless you created a single authoritative server that acted as a proxy to the other API or consumed data from that API without giving the app a key.

Snapchat may or may not have used this strategy. (The external client emails were real; as for the detection strategy, who knows.)


It's worth noticing that this is not only an app problem. When it comes to Corporate systems, the fact that a user has to work with different systems is incredibly painful. In fact, it's so painful that having 1 person managing the system and everybody else just sending email requests to this person works wonderfully.

One thing they could have tried is human support. Like let's give them a human who takes care of things or helps out or is always available to give training.


Do users actually hate "app clutter"? I have plenty of apps I only use rarely, but when I need them, I need them. Space isn't a concern unless it's a huge game or downloads tons of media. 100MB or less is nothing.


I do get sick of the updates. Every day, "14 apps updated" or even worse, "3 apps need your approval to update".

Whenever there's an update pending, I ask myself, "have I opened this app since the last update?" If no, then I delete it.


Auto update option... no approval needed.


And then suddenly one day you notice that Facebook now has access to your phone logs, microphone, and camera without your knowledge.


This is not an issue on iOS. Does Android actually automatically increase permissions without opt-in from the user?


No, that's why they need your permission to update.


This is one thing iOS does much better than Android. Apps don't request permissions until the moment they need them, instead of the entire laundry list at the installation time. This allows auto-updating of all apps, while still preventing permissions creep.


Android Marshmallow changes the permission system to work like that.


Good to hear. I left Android a few years ago for iOS because Apple's system was much, much nicer. These days I may be making the move back. iOS continues to suck more with each new release, and Android is (from what I hear) moving in the other direction.


No.


I can't speak for everyone but I hate having apps I don't use. They just take up space and annoy me with notifications either within the app or through updates. Google Photos has helped greatly with the space issue on my phone though as before my photos and videos used up nearly all my disk space.

Plus if I'm looking for something, having another app there is just another app I have to look through before I get to whatever I'm looking for. Either that or it's not on my home screen in which case I get convinced I'm never going to use it so I just remove it.

This is not helped by the fact I find the Android home and apps screen to be horrendous.


Completely anecdotally: if I haven't used an app in a week then I delete it. I can't really justify it, I have 64gb of space on my phone - it's more of an OCD thing than anything else.


I'm guessing you're using an iPhone. On iOS all the apps are displayed somewhere on your homescreens. When I tried iOS that bothered me, because coming from Android I was used to being able to choose which app icons are displayed on the homescreens.


I'm similar, but instead of a week of not using it, I wait until it upsets me some way. Completely irrational, but that's what I do.


Really weird to read this being someone who is using the Expensify app on a daily basis. Super simple, I just photo the receipts as I go about during the month and then at the beginning of the next month I create my expense report.


For me the main pain point of expenses is feeding the data into the archaic web app the company uses for expenses and matching every receipt with the right project number and project activity. Any solution that doesn't remove my need to interact with that web app isn't solving my main problem.


If all of our users were like you, we would have kept it I guess, but figures showed batch uses once a month instead


In that case you didn't go after the right users. Expensify just did a $17m Series C so must obviously be a lot of people like me.


A productivity app that involves the camera? The slowest workflow on the phone? No thanks.

The right answer is to get those receipts into a digital format some other way, not with the camera.

I would have deleted this app after I tried wasting 30 seconds taking a nice little picture of a $20 receipt the first time.


I would beg to differ with that opinion.

I use JotNot Pro on my iPhone to track receipts. As soon as I get a receipt - say at a restaurant - I immediately snap a photo of it. JotNot takes a black and white contrast-enhancing picture of the cropped receipt that's as good as what comes out of a scanner and adds that image to my ongoing collection of receipts for that business trip.

At the end of my trip JotNot allows me to email a PDF of the collected receipts (or upload it to my DropBox).

I never lose receipts. I never have to deal with receipts that have rapidly faded because a little restaurant grease got on them (looking at you, Jimmy Johns). I never have to worry about finding a scanner and how to place each receipt on the scanner bed.

When I show co-travelers my process, they normally immediately download JotNot or find some alternative on Android since JotNot is iPhone only afaik.

I would be really sad if I had to go back to holding on to paper receipts and scanning them in via some other method.


Maybe I'll give the "taking photo" thing another try. I always end up finding it too fiddly and go back to sticking the receipt in my wallet but it's probably worth reconsidering.


The way I track expenses is using Scannable (it's an Evernote app). The main point there is to capture the receipt - and it's really, really good at that one thing: capturing.

Then I throw away the receipts and fill in the expense report later in whatever system I'm told to use.

I can't imagine an easier way to digitize a receipt, short of a receipt that's emailed to you from the get-go.


>I can't imagine an easier way to digitize a receipt

For me, it ends up being sticking them in a wallet/envelope and then scanning then in bulk when I get back. If I had a phone app that integrated with a back-end expenses system, I could probably be persuaded to use it because it would largely eliminate the manual process of creating an expense report. However, as it is, something like Expensify trades a one-time batch operation for a bunch more fiddling at the point of spending.


Are you using Expensify's "SmartScanning"? It's worth the $0.20 per receipt image. It basically send the receipt to a person, who then extracts the info from the receipt and enters into expensify FOR YOU....

Try it out!


Well, then I would have to transfer everything from expensify into the back-end system that we use to actually turn those receipts into numbers in my bank account :-)


Camera interfaces are getting better all the time.

For my banking app, you can take a picture of a check to deposit it. Instead of needing to frame, focus and snap the picture (which is how it used to work a few updates ago), a frame appears on the phone screen - you merely line up the check inside the frame, and when it's lined up sufficiently the shutter clicks and takes the picture for you. It's quite nice actually.


How else would you take a physical receipt and turn it digital? Enter the info manually? I'd think that taking a picture is actually the fastest and lowest friction option.

I do it every time I deposit a physical check into my bank account with my BofA app it's pretty awesome, it even recognizes the deposit amount.


Expensify goes a step further and gets a person to look at your receipt photo and then enters/confirms the information and enters it as a text into your expense report. It turns pictures into expense report rows.


Expensify: Take a picture of your receipt. It gets sent to someone in India/Phillipines/etc. Who then look at the total, the name of the plae and ENTER ALL THAT INFORMATION FOR YOU.

When you get back to your office - it's available in an excel sheet.

I'm not following your argument...


This is a good shutdown analysis. But they didn't really mention that their sector has been pretty heavily dominated by traditional accounting software like Quickbooks for quite some time. I'm not sure how long, but I remember using Quicken in the 80's.


And what has it been like moving to Slack? Are people using Birdly more?


Yes they do, and I think it's also because of the "emotional" factors. People talk to a bot and have this feeling they have a personal assistant guiding them through the process.


Saving four hours a month is great, and if you have a captive audience who is being told to use the mobile app to submit expenses, that will force adoption.

Trying to get individual users to adopt a workflow is going to be much harder.

The target audience for the mobile app might not be the users themselves, but their managers.

Also, your workflow of using Slack to enter expenses, which looks awesome btw, might actually be easier for people to use than stopping midstream to use a mobile app.


Completely agree with the point that the managers are the target audience. People use all kinds of poorly-designed an inconvenient software at work because they're forced to by their boss are the company IT department. Well-designed software is already a leg up, but only if you can properly sell it to the correct decision makers and make it easy for them to switch over. This app wasn't inherently flawed — if it had started to get traction from a couple companies using it, then word-of-mouth spread because of how easy the app was to use, it could have gone a lot better. I can imagine my friends who are management consultants using this to keep track of all the expenses they're playing on the company card or billing the client.


I cant believe i'm reading this.. How is saving 4 hours per month useful, and how in the world is it worth learning a new app for that.

Maybe this isn't really the right place to say this, but the moment the world will realize how crazy this whole startups thing is getting..


I think your place of wonderment is misplaced. If someone can save 4 MINUTES of an activity they HATE to do - it is worth learning an app.

There are all kinds of companies that basically help you save time doing what you hate: Premium Pickup Laundry Services, On-demand Valets, On-demand cars. When was the last time you said "fuck it I'm going to take a taxi because I don't want to learn this new UBER app"?

Companies reimburse BILLIONS of dollars to employees every year.


The new service looks really useful but I'm bummed out it's only available as a chat bot?!


Would you prefer it to be a mobile app?


I'd prefer it to be open sauce self hosted web app


I, for one, would love to try and use this app daily. I currently use Microsoft Office Lens to snap all my receipts. Unfortunately, it has some very awful ways to store it which is primarily in the Photo Album... Would be lovely to have a generated excel of things.


Try Expensify - take a picture of a receipt, it is automatically OCR'd, read and verified - and it becomes a row in an excel spreadsheet you can send to your accountant.


I like this article because for anyone who has not tried to sell a product, it can be very easy to become deluded about how hard it is, due to the endless noise from the press and VC community that tends to talk up successes and gloss over the difficulties (the notable exception to this being Ben Horowitz).

I've found this thought experiment to be useful when evaluating new product ideas: People will buy your product for sure if a) there is a law saying they must, otherwise go to jail or b) by doing so they straight away save a significant amount of money vs something they were already doing/buying. If your product isn't close to either of these cases, you are likely to fail.


I've tried several receipt tracking apps, and they all failed to overcome the OCR challenges.

If there is even a 20% chance the app cannot recognize the total amount (ignoring taxes and tips), then suddenly I am manually reconciling unrecognizable receipts.

So, if I'm always manually reconciling expense reports, then why bother with an app... I'll just continue taking pictures and forwarding them to my email for manual expense reporting. 100% of the task can be done in one sitting.

That being said, I SINCERELY HOPE somebody WILL develop the machine learning algorithms necessary to get 99% OCR accuracy in this space.


There are plenty of companies that just have a human read your receipts. Hell it can even be automated with Mechanical Turk.


Is the problem more that this is a feature, not a product? That is, integrated with expense report systems, tax management, any other business tools, this makes sense. But as a standalone, it feels like an island.

This was similar to TripIt which organized your trip based on parsing confirmations. At the end of the day, it was a great feature, but struggled to grow beyond a certain point as a product.

Love the idea behind Birdly... but I think it belongs in other apps/tools used for more frequent and broader business needs. (i.e., here's hoping for a great acquisition and adoption for you!)


This guy's business was "take a photo of a receipt for every single thing you buy, then upload it to us, and (supposedly) save four hours a month." It's hard to imagine it not failing.


OneNote & OfficeLens has replaced many apps on my phone. It's true that the other apps were better tailored to the problem, but the effort to install and maintain so many apps with a couple mobile devices (tablet and phone) is just too much: app features and layouts keep changing, credential info needs to be re-entered and then I get to my desktop and there is no application for Windows or Mac. For better or worse, if the requirement can even partially be met with OneNote or Evernote, they will probably just use it.


It's not a terrible write-up but I think it may be a little delusional both ways. I'm not totally convinced that they type of app they built could not find a decent audience. The app "makes sense".

And "Don't bother creating a mobile app" is terrible advice. But if you are going to create a mobile app, you have to really try an understand if it makes sense, how people are going to find it, if it's compelling enough, if it takes advantage of "mobile-ness". Etc.


Likely would/could have found a bigger audience if it hadn't been limited to the French app store only...


I'm not that surprised. I would never remember what an app named "Birdly mobile" did, when finding out I installed it last month.

Neither would I find it again, if looking for that "receipt scan app I installed last month".

I tend to forget what apps I have installed, what they do, and their names, and anything else than a really descriptive name, such as "RunKeeper", would not get used much in the long run.


Reading the article, all I could think was "sounds like a problem with getting users to form new habits."

Those categories they listed are apps you'd use on a daily basis, or that have some kind of notifications (read: dopamine hits) built in. They build up a habit loop by making the app fun to use, and emitting notifications to keep the users coming back during that formative early usage period.

Monthly expense reporting (or monthly anything, really) seems like a rough road for building habits.


From my own patterns, I sort of agree with the conclusion but there's one app that I keep even though I only use it a few times a year and it's a PDF "scanner" app. The difference is it replaces an expensive piece of hardware and it does it better than the hardware. I'm not sure Birdly really solved any problems that couldn't be solved just as easily with built-in apps or even pencil and paper.


I think they fell for the myth that "ideas don't matter, execution does"

If you start with a flawed idea there's no saving you, no matter how hard you try.


I'd like to use something like this to verify that my credit card statements are accurate. I don't want to give an app access to my bank logins (as I believe Mint requires). So I envision a workflow where I snap receipts, the app digitizes them and produces a transaction list which it either compares against a monthly statement PDF, or I do the verification by hand.

Anyone have a good, established workflow for this?


I imagine it is very hard to make money with the types of apps that fall within those most popular app categories. Mostly free apps with advertising.

I guess I don't really understand the shift of ONLY creating a mobile app for productivity or business type stuff. Seems like these types of apps can more easily be monetized with a web app and "maybe" complimented with a mobile app.


i believe that we - as programmers, product managers, ... - often have the wrong ideas about mobile. three examples from my experience:

idea: an app that helps people find shops with offers nearby

how people use it: users look up offers while they are already in the shop (nearly always inside big supermarkets.)

idea: vegan restaurant finder

how people use it: users look up pics of food of that restaurant while they already sat down in the restaurant (but as Instagram has more pics, they always switch to Instagram)

idea: apartments for rent app with awesome "find apartments nearby" feature

how people use it: to look up the newest apartment in the city while in the metro home

i believe it will take a few years more until we get mobile more right than wrong, until then be prepared to question your product hypothesis! (and best do it while you are running around, stressed, on your way to work or during business travel, you know, while you actually are "mobile" / or at home at your couch (also a mobile scenario) ... not while in the office in front of your mac book pro)


Really weird to read this being someone who's using Expensify on a daily basis in exactly the use cases they describe.


LOL - totally. However, their interface actually looked sexy compared to expensify. But epensify works and I can use it on desktop....that's the killer. The mobile app is awesome for capturing but I like desktop for putting together reports.

Ultimately - I believe in Expensify's VISION - which is to GET RID OF EXPENSE REPORTS!

That's why I'll stick with Expensify - and I'm now at my third company that I am bringing it into....that is how software expands its footprint. By excited users bringing it into new businesses.


Yesterday I put together a guide for making profitable mobile apps that might interest people - https://medium.com/@PuzzleBoss/actionable-steps-to-make-mone...


It looks like you made the right pivot, moving away from a native app to a web app.

FYI - your mobile navigation isn't working.


I too was expecting a web app but it looks like it's just a slack bot now which is...interesting.


Is the title meant to be linkbait? Cause this is quite the blanket statement.

How do you know what I'm building (if anything) and if it falls in a category that might benefit from being a native app and the distribution that comes with it?

What worked or did not work for you need not apply to every other business.


I think this is a good article, but I don't like it when someone uses just one experience to generalize about something as broad as whether someone should or should not build a mobile app.


The title was provocative on purpose. As said in the article we believe mobile is very relevant in a lot of cases. We’re definitely not trying to prevent anyone from creating mobile apps, but after spending a year doing so (and sure, making many mistakes on the way), we’re just sharing our humble piece of advice and lessons learned.


This is a sincere question. Is number of times app is used per week/month/year a good metric to build an app? Wouldn't that be a typical utility for a Uber/Lyft?


But do bother to advertise your new product on Medium!


Might a monthly reminder notification have helped?


Every user received a monthly reminder, and it did help, but having an idle app on your phone for the other 29 days didn't, unfortunately


[deleted]


Why unsolicited?

User had set up an app that they care about just once a month, and that's a long time, so reminders are actually helpful - from end-user perspective. I have an app that I run about just once in a few months, and I'm actually grateful that it does ping me.


How does Birdly/Bill do the processing of the receipts? Is it OCR software, a person,...?




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: