Heh, don't blame you. We did fight for and win approval to write a forward to our privacy policy to make it more accessible. Outside of that, we didn't want to innovate in an area we know very little about and instead deferred to what our law firm told us we should be doing.
Sorry about the bug. We've been deploying all day and made the mistake of pushing something that received new server content before the updated clients themselves had time to propagate. I'm guessing that's what you ran into.
A bit about our process: we catch all errors (server and client) using Bugsnag and pipe them to Slack. Those errors are basically stack traces that hopefully give us enough context to reproduce and fix the bug. If the error was user facing (e.g. interrupted your conversation), we also open a ticket in Enchant that links back to the Bugsnag error. That way we track if/when a user hits a bug and can reach out to let them know when it's been fixed, or collect more info on the context surrounding the bug.
Like most customer support portals, Enchant can be populated with information about the person's account. In our case, we can see things like your first name (that's all we collect from you), when you joined, your phone platform, your app version, and which bank types you've attempted to link.
Does that answer your question?
As for financial data: we don't store your credentials, ever (thanks to Plaid's API, we don't have to). We do store your transactions so that we can serve them to you in-app (hopefully that's not a surprise?), along with the bank type and balance information that you see in your accounts tab. Since they're in our DB, engineers on the team can query that information. We do that on a need-to-know basis only; for example, if someone has asked us to investigate a bug they ran into, or why their numbers look off.
And just because we're working on this idea doesn't mean you can't too. It all comes down to execution. A little competition is healthy for everyone :)
That first Show HN post sent about 700 unique people to our website, of which about 100 clicked the download button and roughly 40 signed up. That may seem like a small number, but it was huge for us at the time. It gave us a lot of new information about where people would fall off in our funnel, uncovered some edge cases we hadn't accounted for, etc.
That FAQ is a little out of date—I'll update right now. Once you remove duplicates, we support closer to 8-10k banks through Plaid, and we have two monetization strategies (monetization was our focus at YC):
1. A premium subscription service that gets you some power features within Penny; we just launched that today.
2. Recommending affiliate products.
It's important to note that affiliates can be a mixed bag. Mint.com was the product that turned me onto Betterment when I was hunting around for ways to invest my money; I'm legitimately thankful that they did since I love Betterment. At Penny, we think we can tastefully and in good faith recommend some affiliate products. Those recommendations fit perfectly into our coaching model too.
Unfortunately, most personal finance companies start pushing credit cards on people that don't need them because it pays the most money. We're building Penny in a way that disincentives crappy behavior like that.
Agreed. We've reached out to Google a couple of times asking if they can display a more helpful message than "not compatible with an of your devices" when the real reason is "Only available in the US". Not a great UX.
1. Those other platforms didn't really exist when we first launched. Messenger launched their platform about nine months after we started Penny.
2. (The real reason) We still don't think we can provide a better experience via a chatbot platform than we can with a standalone app.
To motivate that second point:
The benefit to a chatbot platform is that you meet people where they already are, and "signup" generally has lower overhead.
The downsides are many, though. Most platforms don't allow for things like securely submitting username and passwords, e.g. when connecting a bank account (although Messenger is starting to allow webviews, which can be repurposed to handle this). Browsing your aggregated transaction history, changing the category of a transaction, viewing your balances, etc. are all poor fits for a chat interface (again, Messenger has only recently started to address this). Pre-populated responses aren't first-class citizens in most chatbot platforms. We get more control over the UI, e.g. when displaying animated graphs, in a standalone app than we do within chat. There is/was no way to lock individual chatbot threads behind passcodes to protect your privacy... and on and on :)
Finally, there's also the problem of discoverability, which no chatbot platform has solved in a convincing manner. Downloading a standalone app is a pain, but once you get over that initial hurdle we think the experience is still significantly better than delivering Penny over a chatbot platform.
For what it's worth, we don't think the premium experience (Penny+) is a good fit for most of our users. Locking extra complexity behind a premium version was actually our way of keeping the core experience simple (and encouraging people to not mindlessly turn on extra features unless they're confident they want them). We think the simplicity of the core experience is one of the main reasons people continue to use Penny over time; complexity begets churn, even if users ask for that complexity. We eschew traditional budgets for the same reasons.
Penny (https://www.pennyapp.io) | San Francisco | ONSITE
- Hiring for a well-rounded engineer to join our three-person team working in the personal finance space.
- You can expect to touch every aspect of the business and get serious equity.
- Stack: React frontend, Ruby backend, iOS/Android apps, some ML, etc.
- More details: https://www.pennyapp.io/jobs
I'm one of the two co-founders. Feel free to email me directly if you're interested: mitch ~at~ pennyapp.io.
That doesn't work all that well on mobile apps, since users first have to download a new app before you can record the referral code. Having a link click persist through that process is nearly impossible.
Great point. Typing emojis on non-mobile devices is a pain right now. Cmd+Ctrl+Space on Macs brings up an emoji-picker, but I doubt many people know that.
I guess this should be scoped to mobile-only applications. Web services can also use traditional referral links so a memorable referral code isn't as big of a UX win.
At this point, emoji support is almost ubiquitous (at least in the US). I'd imagine that within the next couple of years emoji support will be within a rounding error of 100%.
You'd obviously want to limit the set of available emoji to avoid any ambiguities but assuming you do—is there anything stopping their use in frequent flier numbers, passwords, etc.?