Expenses, Mileage & Receipts In A Windows Phone App!
We’re proud to announce that you can now log your mileage, track expenses and scan receipts on our 4th mobile app – this one for the newest kid on the block – Windows Phone 7!
What’s included?
|
|
And of course, thanks to our cross-platform mobile library, all the good stuff from the Android and BlackBerry apps.
To install it, first upgrade your phone to “Mango” (Windows Phone 7.5) if you haven’t already. And then just click here, or go to the Windows Phone Marketplace and search for “Expensify”.
The first wave of reviewers already seem pleased:
“This is the most elegant and seamless way of keeping track of travel expenses and generating reports. Thrilled to see it available on Windows Phone!!! A must have..”
Let us know what you think of the app in the comments!
Sync with receipts, expenses in Evernote
We just finished a joint integration with Evernote that enables you to create expenses from receipt images and churn out clean, searchable PDFs of expense reports! So even if you can’t remember everything, you’ll still be able to search for it.
Create expenses from receipt images
Put all of your plane tickets, hotel invoices, car reservations and other receipts in to the Expensify folder. We will sync with it automatically and scan the merchant, date and amount from each receipt image to create an expense entry. So easy, you may forget how to type.
Keep track of your expense reports
A new export option allows you to send your created reports back in to the Expensify folder inside Evernote. Want everything done for you? Enable automatic export and any time a report is submitted, approved, reimbursed or just has its status changed we’ll update your Evernote account with the latest copy. Fully searchable PDF expense reports are now at your fingertips!
Give it a try – link your Evernote account!
Markup Your Images with Receipt Details
To streamline and simplify Expensify even more, we’ve made some subtle but significant changes. Introducing…
Receipt Details!
This site-wide update let’s you manage your receipts in ways you’ve never been able to before:
- Annotate receipts with Categories, Tags, and Comments
- Scan annotated receipts
- Attach receipts to reports and submit them (without the need for expenses)
- Scan receipts on reports
To support these features, we polished various parts of the site. The receipt edit dialog has been revamped to clarify that details and an expense are optional additions to a receipt. The new expense dialog was also changed to reflect the changes.
Improved Expense/Receipt edit dialog
New report section: Attachments
A new section on the report contains “attachments”, or images without attached expenses. You can add supporting documents to your report, or compile a collection of receipts and simply submit that to your accountant. It’s a versatile section and we’ll be adding more functions soon.
New Reports Feature: Attachments
Report it and Forget it
You don’t need to wait for receipts to finish scanning for expenses; feel free to add receipts to a report straight away, then scan them directly on the report. They’ll transform into full-fledged receipts with expenses.
Scan an attachment and it becomes a receipt with an expense
Here’s a really handy workflow:
- Capture receipt photos with our mobile app, adding details on the spot (“Lunch with Alice”)
- The receipts are queued for automatic scanning
- Add the receipt on a report — it’s still queued for scanning
- Come back later, and your receipts are all scanned and correctly attached to the credit card expenses
- Submit the report!
Very soon we’ll also allow you to add receipts to reports from the mobile apps, so stay tuned.
Please send us feedback!
We read every piece of mail sent to us, and this feature was created because users asked for better receipt management. If you’d like to play a role in fighting sucky expense reports, please send us a message at help@expensify.com or leave a comment below.
Thanks and happy expensing!
~ayumi
Log Mobile Offline Expenses and Odometer Readings
Behold!
We’ve just released the new Expensify Android & BlackBerry 2.60 apps:
 |
 |
What’s included? Let’s take a look a few new features:
Receipt comments
So you love uploading receipts direct to your Expensify account, but what if you want to add a quick note to your receipt, so you don’t forget that important detail? Now you can. We actually made quite a few changes to the core Expensify system to enable this.
Odometer entry
Now you can enter your start odometer reading before you go on a trip, save that value, and then after you get there, enter the end odometer reading, and we’ll calculate the distance and add that mileage expense.
 |
 |
Business cards
Now you can add business cards to your Expensify account, straight from the home screen of the mobile app. We give you the choice: invite the person from the business card, and we’ll give both you and them 5 free receipts scans; otherwise, it costs one scan.
Outbox & offline mode
This has been around for a few versions already, but we thought we’d mention it in case you haven’t heard: The mobile apps have an outbox that can be placed into “offline mode” which makes them not even attempt to send expenses & receipts, which is very handy for when you’re overseas, and don’t want to be charged for extra roaming data – you can tell our app to save uploading them until you’re back in WiFi range. The outbox will also save up your added expenses and receipts if you’re out of service range as well automatically.
 |
 |
Also, for those feeling left out: this will all be coming to the iPhone soon as well, in the form of a new Expensify “lite” app, and we may even have something in store for those on the Windows Phone side…
Enjoy!
Tom.
Expensify Mobile.
Import expenses from your PayPal account
Lots of you have PayPal accounts that are used on a regular basis to help run your business. In an effort to help bring more of your needs together in to one spot PayPal has just been added as an option from which to import expenses and purchases. Importing your PayPal account is the same as importing any other credit card or bank account.
Log in to your Expensify account and import your PayPal account to bring in all of those expenses automatically. Let us know if it helps simplify your life!
Expensify Hiring a .NET Programmer! Seriously!
Recall a certain blog post about Expensify and .NET? Odds are you stopped reading about five paragraphs in, and possibly missed how ”.NET on your resume isn’t an instant showstopper” only that it will “raise questions during the phone screen”. Similarly, you might have missed that .NET is the “only choice” for Windows Phone 7 development. Well at risk of dredging up old grievances, I’m happy to announce:
Expensify is Hiring a .NET Programmer!
(Windows Phone coders please apply)
As for what we’re building, it’s no secret: we’ve got a cross-platform mobile layer that needs porting to WP7. It currently works on Android and BlackBerry, and we’re about to launch an iPhone version. We’re thinking of open-sourcing it if there’s adequate interest; leave a comment below if that appeals to you. Either way please check out our Elance post for complete details, or just read on:
Port Expensify cross-platform layer to Windows Phone 7
Hello! Expensify has apps for iPhone, Android, BlackBerry, and webOS. A little known fact is that we built our own cross-platform layer, such that we have “write once run everywhere” on these platforms — using native controls. Your mission, should you choose to accept it, is to port this platform to Windows Phone 7.
I somewhat famously blogged about how much I like .NET for Windows Phone, so I’m very excited to start on this project!
It works like this on all other platforms, so we need you to build the WP7 equivalent:
- We instantiate a JavaScript interpreter. This is *not* an embedded browser — on Android and BlackBerry we use Rhino, and on iPhone we use JavaScriptCore. I don’t know what is the best JS interpreter to use on WP7, so it’s up to you to pick it.
- That interpreter loads our cross-platform application logic, written in JavaScript. (This code is currently packaged with the app itself, though could conceivably be downloaded at runtime.)
- The JavaScript calls out to the native wrapper, instructing it to do things like create and position controls, take pictures using the camera, make AJAX calls, get GPS coordinates, and upload photos to our server. We’ll provide you with the JS application code, but you’ll be expected to actually implement all of the JavaScript callback functions.
- All JavaScript code executes in a single thread. So UI events — even if they happen on a different thread (and I’m not sure they do, I’m just saying *if* they do) — should be passed to the JS thread for processing by JS.
- Similarly, most of the JS functions are “blocking”. When the JavaScript asks for a particular UI control to be created, you needn’t (and shouldn’t) return until it’s complete.
- However, some JS functions are “non-blocking”, namely network calls, camera actions, and GPS queries. These should return immediately and be processed in another thread (or even by kicking off an external app and waiting for a response). When they complete, like UI events, the callback should come from the one single JS thread.
- Persistent storage is currently very simple, using flat files on the file system. (Typically writing and reading JSON files.)
We are looking for a long-term contract, ideally with the opportunity to hire on-site in SF if all goes well. (Remote hiring or just remote long-term contract is also fine.) Accordingly, we prefer individuals over teams — especially individuals who like what’s written here: https://www.expensify.com/jobs/need I should also mention that if you’d like to skip the contract and go immediately into hiring talks, that’s fantastic too.
This is a big project, so I’d recommend we split it up as follows:
1) Develop proof of concept. It is a standalone app executing in the emulator that instantiates a JS engine that loads a “hello world” file, which calls a single “alert” function to pop open an alert box. For simplicity, please include a “fixed bid” for this first deliverable, along with an hourly rate that we’ll switch to for future milestones.
2) With proof of concept in hand, flesh out the remaining UI controls. It includes what you’d expect — text, number, date picker, checkboxes, images, etc. A complete specification will be provided; if you prefer we can also handle this second milestone as a fixed bid.
3) Add networking and camera. Historically this is the part that gets hard, as for some reason HTTPS support on every single other platform has been dicey — especially when uploading binary images. This was true for iPhone, Android, BlackBerry, and webOS, so I expect it’ll be true for WP7 as well. Accordingly, I suggest we switch to an hourly rate for this.
4) Release to the Windows Marketplace for Mobile and interface directly with uses to diagnose and resolve issues experienced in the field.
How does this sound? Please let me know, I look forward to talking soon!
-david
Founder and CEO of Expensify
Anyway, I look forward to hearing your cogent, well-considered comments below. Thanks!
CEO Friday: Premature Optimization is the Root of All Evil
Years ago Witold and I joked that performance is a problem we’d “love to have”. It means that you have so many people using and liking the thing you’ve made that it’s starting to slow down. After all, an iPhone has enough horsepower to power most websites: it really takes a lot of work to overload an actual business-class server anymore. If you’re experiencing genuine slowdowns, it’s a sign that things are on the right path. It’s a problem you should love to have.
However, it’s still a problem. In our case, things aren’t quite as snappy as we’d like. We’ve increased from 3 to 5 datacenters, vastly increased hardware, and the users keep coming. So we’re embarking on a much more deliberate optimization campaign than we’ve ever done (or had need to do) in the past. And that’s great because optimization it’s fun! It’s full of all sorts of “classic” engineering problems — phrases like “Big O” get tossed around with nary a chuckle.
But like most fun things, at its heart lurks a deep evil. Here’s what I advised our team, and I thought I’d share it with you as a public awareness campaign highlighting a universal problem.
Premature optimization is the root of all evil. I mean that in the most literal and expansive way possible. Resist this devil with all your might. Here are some tips:
1) DON’T OPTIMIZE IF YOU DON’T KNOW IF IT’S SLOW.
I repeat: don’t make something faster if you don’t actually know how fast it is. It’s possible — in fact, highly probable — that it’s actually adequately fast as is. I’d estimate that 80% of optimizations have absolutely no beneficial effect, and actually make code slower and less maintainable. Don’t be “that guy” who spends all day optimizing something that doesn’t need it, while ignoring the enormously huge low-hanging fruit all around.
2) BENCHMARK BEFORE OPTIMIZING.
Optimization is a field where you can spend an unlimited amount of energy accomplishing precisely nothing of value (or even less). The best protection against this is measure its real-world performance before starting, as this is the only effective way to prioritize areas to optimize. The best measure is that which is experienced by the end user.
3) BENCHMARK AGAIN AFTER OPTIMIZING.
If you don’t know that your optimization worked, it’s safest to assume it didn’t — just like the vast majority of optimizations. If it didn’t, then revert the change. It doesn’t matter how long you spent building some fancy caching layer or tweaking settings in ways that “I’m sure” are better. Don’t trust your gut, trust the numbers. If the numbers say you’re wrong, you’re wrong.
Note: Optimizing is not the same as refactoring, though often they go hand in hand. If you’re refactoring code to make it cleaner and simpler, then it doesn’t matter if it goes faster, so no need to revert a cleanup if it has no speed improvement.
4) FOCUS ON ABSOLUTE TIMES.
It means nothing to say that something is 50% faster if it was already fast enough to start. Don’t even think about problems measured in “miliseconds per X” until all of the “seconds per X” problems are already handled.
5) DO THE MOST IMPORTANT OPTIMIZATION FIRST.
Not the one you just found, or the one that’s been nagging you, or the one that lets you use that really awesome algorithm. This is the absolute hardest of all: when you find something new, add it to the list, but always start with the optimization at the top of the list. If the thing at the top of the list hasn’t already been benchmarked, benchmark it. If after benchmarking it you find that it’s actually not as important as something else on the list, log your benchmark results, then put it back on the list at a lower priority.
6) SHOW LOYALTY TO THE USER, NOT TO A LAYER.
Don’t optimize something merely because it’s the slowest in a particular layer; always do whatever increases end-user performance first. Trace the issue and benchmark through all layers before deciding how to speed it up. Leave no layer unturned.
7) CHANGING USER EXPECTATIONS IS THE BEST OPTIMIZATION OF ALL.
Remember, the goal is to make the user satisfied. One way is to actually live up to the user’s expectations. Another is to change their expectations by adjusting the flow in such a fashion that they just don’t expect as much. Some blocking operation really slow? Make it asynchronous such that the user doesn’t care how long it takes.
8 ) BROADCAST BIG PLANS BEFORE YOU DO THEM.
Before building out some really crazy ambitious awesome thing, email to the team explaining what you’re going to do. *Sell* your change, based on the benchmarks. Be proud of your plans; if you feel hesitant it’s probably a sign that you don’t really know what you’re doing or why — and thus probably shouldn’t.
I’m serious, premature optimization is what sinks ships. It’s the tarpit of any engineering organization; it’s where clean and simple architectures go to die. Resist the devil. Be strong.
Expensify goes to the shooting range
When we say we work hard and play hard we mean it. A week ago we went to the shooting range in San Rafael. Naturally, we had a blast…
Photo Credits: Thomas Genin, Ayumi Yu
Welcome to Bullseye Shooting Range, San Rafael, CA
Guns. Lots of guns.
This gun costs $2500. We shot it. (Wilson Combat CQB)
.45 ACP ammo. shiny!
Remember kids, safety goggles!
Zombies? In *my* shooting range?!
David rocks the 1911 like a boss
The AR-15 was definitely our favorite though
And afterwards, we went to IN N OUT!! (dude I love in n out.)
Dude seriously. In n out is so good. I want some right now.
awesome moustache, Matt
You should join us 
We’re hiring awesome people!
New Feature: Crop and Rotate Receipts
Good news everyone!
You can now crop and rotate your receipts in Expensify!
Click on a receipt to bring up the Edit dialog:
Adjust the image as you like, and click the check to save!
How do I undo?
Previous versions of the image go to Deleted Receipts. Change the receipts dropdown from “Unreported Receipts” to “Deleted Receipts”, and you can restore old receipts.
Best wishes,
~ ayumi
CEO FRIDAY: The Bottom Up Adoption Curve (4/6)
After a quick halftime break, let’s resume the second half of the series. As mentioned in the past, this is the fourth in a six-part series elaborating on a presentation I gave at the AlwaysOn OnMobile 2011 conference titled “Disrupting the Enterprise”. I suggest reading from the start (or watching the video) and then continuing on below.
Recap: The Three Conditions Underpinning Sales (N+1).0
So there are three interesting conditions at work:
- The “Consumerization of IT” empowers employees to promote products up the chain in an enterprise
- “Word of Mouth” has become a “Winner Takes All” phenomoneon where early dominance of the global conversation becomes self-reinforcing
- There was a one-time “Cascade of App Stores” that gave a substantial and lasting advantage to first movers
The upshot of all of this is I feel there is an enormous opportunity to reach into previously inaccessible parts of the market using a sales strategy that I call Sales… 3.0? 4.0? Let’s just say 10.0 to get ahead of the curve. The very modestly named “Sales 10.0″ strategy conists of three principles:
Principle #1: The Bottom Up Adoption Curve
Many industries share a common chart: a very wide base of customers at the “bottom” of the market, narrowing down to a very pointy tip of customers at the “top”. What “bottom vs top” actually means and how it’s quantified depends on the market. But if you’re reading this blog, odds are you’re targeting the “bottom” of the market while some other big company has a stranglehold on the “top”.
At some point, the big company at the top will decide it wants to capture some of the action down at the bottom. It’ll do this by instructing its massive salesforce to start going after smaller deals — probably by adjusting their commission incentives to make smaller deals more attractive than they’d normally be (or by hiring a new sales force devoted to just this). If they’re really serious, they’ll come out with some new product targeted squarely at the small business space.
But don’t worry, because odds are no matter what they try, it’s not going to work. The product and skills needed to operate in and maximize the value of the top of the market just don’t translate down market. Small businesses aren’t small versions of big businesses, they’re an entirely different beast. Any company optimized to hunt whales just isn’t suited to trap squirrels.
This is where the “bottom up adoption curve” comes into play.
In the top-down sale, you typically start talking with senior management — nobody really experiences the product until they’ve already signed off on it. But the bottom-up sale reverses the process, giving a trial of the product straight to the rank-and-file employees, before senior management even hears of it. So while a top-down salesperson would fight tooth and nail to get a limited trial authorized by senior management, the bottom-up product just walks in and starts a trial on day one. Top-down requires some high-level introduction to start a conversation with a new customer, while bottom-up can start with anybody, anywhere in the company — the lower the better. While the top-down company builds a wide range of complex features that appeal to management, the bottom-up company builds the few core features that the actual users of the product love.
The end result is the bottom up adoption curve reaches out directly to the innovators in every company, empowers them to initiate a limited trial without the need for anybody’s permission, and then champion the results internally — essentially giving you an “inside man” pulling for you in every sales lead.
So it’s “bottom up” because you start with the users first, and percolate up to senior management only after the trial has already successfully completed (and thus, there’s no reason to say no). And its an “adoption curve” because it takes a graduated “innovators first” strategy where those who come before learn and train the people who come after (as opposed to a top-down sale where all users are signed up at the same time). It allows your product to be pulled into organizations by the people who need it most, and then sold to all internal stakeholders by someone intimately familiar with the local conditions — all without you ever picking up the phone.
So it’s a system that definitely works in the small business space. It’s very hard to design a product to accomodate it, and it’s very hard to get all the incentives to line up. But when you do, it takes off under its own steam, with each new user expanding your salesforce — and thanking you for it. Everybody wins.
But it’s also “bottom up” in another sense: with this technique, you start with the bottom of the market, and gradually work your way “up” to the top.
Granted, this is the only thing that will work at the very bottom of the market. The deals are so small, and there’s just so damn many of them, you absolutely need to have something like this to survive. The most important feature you ever build is the one that finds the next customer, automatically, while you’re asleep.
And to be fair, if you were only going to sell to the top of the market, you wouldn’t bother with this. It’s really tricky stuff, and it’s so much easier and more effective to just go out and get a sales force (assuming the cost of sale is substantially less than the revneue it brings).
But if you *do* start out at the bottom, and if you *have* already gone through the trouble to make this work… why not use it upmarket as well? After all, there’s nothing about this process that doesn’t work in large companies as well as small. Sure, big companies have bigger requirements. And you might need to get more clever about how exactly you support your internal champions — giving them the tools they need to start a trial without anybody noticing, and promote your product up the food chain in a non-disruptive fashion. But maybe it’ll work there too?
The bottom up adoption curve is a strategy for not merely taking over companies, but taking over markets. And as we’ll see next week, holding onto them forever when you get them.
Thanks for reading, keep an eye out here to read more next Friday!
Previous: A Cascade of App Stores (3/6)
