We are very happy to announce that our Reconciliation and Central Administration feature is now available for American Express corporate cards. Because the feature was such a hit with commercial card holders, we decided to develop for Corporate cards as well. Continue Reading…
Archives For November 30, 1999
Get a glimpse into the minds of our engineering team.
In conjunction with SIGNALFIRE, Expensify threw an afterparty for their University Hack-a-thon… and it was EPIC. Of course we had a great time chatting with quite a few collegiate geniuses about their projects in the hack-a-thon, but that wasn’t the point. We wanted to give them a chance to relax and celebrate their hard work. So, thanks to SIGNALFIRE, all of our participants, and everyone who helped make the party a massive success.
If you didn’t make it, you missed: Continue Reading…
As two interns living across the country for the summer, we realized we could finally visit some west coast tech conferences without having to fly across the country. When one of our fellow Expensifiers mentioned that he was going to Defcon 20, we jumped at the opportunity to join. We’re both interested in security and hardware-hacking and starting pondering the best ways to get there. Continue Reading…
Yes, accounting and finance departments, we’re talking to you!
With 2012 in full swing, everyone at Expensify is excited by the opportunity to make this year even better. Don’t get us wrong, 2011 was awesome! But we’re a startup, and re-thinking the old to build something new is an oft-repeated mantra. As larger and larger companies increasingly drink the Expensify kool-aid – or our own Expensify beer thanks to a resident brewmaster – our sights are squarely aimed at the scary-sounding world of “enterprise accounting.”
As you may recall, in late-2011 Expensify unveiled functionality that allows anyone to create and edit a very flexible CSV export file. This functionality enables our system’s Categories and Tags to speak the parlance of enterprise accounting and CRM packages. It’s called GL Mapping, and we’re super excited about the potential of this functionality, especially in the context of our self-service, bottom-up adoption model. With that said, we are still in the exploration stage when it comes to enterprise accounting and ERP systems, and for some reason, it conjures images of scary pumpkins. So we thought we should take up some white space to learn what’s out there. Thus far, we’ve talked to customers that use Sage, SAP, Oracle, Netsuite, Intacct, and many others.
But more than names, we’re interested to learn about the types of accounting configurations that we need to support. Past conversations have worked out how to export Expensify’s data into a MySQL database before eventually feeding this information into an accounting package. This was luckily solved by a bit of accounting triage; in other words, correctly mapping the columns in the company’s database. We’ve also seen customers that must track a variety of inter-related GL Codes, both at the expense-level and at the report-level, and this has required a good deal of problem solving for all involved.
This brings us to the interactive part! We’d love to hear from you about your GL setup. Specifically:
- Do you have any pain points with Expensify’s existing GL functionality? What are they?
- Do you feel like Expensify doesn’t support your accounting package or setup? Why?
- Is accounting integration the most important factor in your purchase decision, or does other functionality like automation matter more?
Please join this conversation in the comments or feel free to email jmills@expensify.com. Thanks!
Just about everyone at Kynetx Impact is looking to spread the good word and encourage the use of APIs. While developing an API can be a viable option, the assumption behind their rampant production is that an API will help the developer reap some sort of great success. Our very own David Barrett has a different story to tell.
Like everyone, we built out our API with the hope that a bunch of people would integrate, but in fact three things happened:
1) Very few people cared to integrate. Instead, the biggest user of the Expensify API is still Expensify.
2) The vast majority of those people who did integrate never did anything with it. They applied, they talked with our engineering team — in a sense, we paid the entire “cost” of integrating with them, even though they never actually ended up launching anything.
3) Those tiny few people who did actually launch something significant never actually produced any value for us. We had high hopes on both sides that joint customers would see all this combined benefit, but in practice very few did.
Hear David speak and find out the full story of the Expensify API at the Kynetx Impact conference – he’ll be speaking on Wednesday at 11 in room 300. Come one, come all!
Fumigation
There’s always an inexhaustible list of features, user requests, great ideas, and random goodies we would like to implement at Expensify. However, for the past few weeks we froze 99% of new feature development. Instead, this milestone we took a step back and tackled the most dreaded part of any engineering task: Bugs. That’s right, we voluntarily decided to take on the infinitely scrolling list of alerts, warnings, crashes, plunks, thunks, and uglies — and fix them all.
But why would we take a break from making the product bigger? Because first we wanted to make the product better. We wanted to get rid of all that code that was causing unexpected glitches or unacceptable results. The bugs were just plain annoying, both to us and to our users.
Bugging Around
Bugs come in all shapes and sizes. There were big bugs, little bugs, confusing bugs, convoluted bugs, old bugs, new bugs, obscure bugs, scratch-your-head-and-say-wha? bugs. But we tackled them all. I’ve asked the Engineering team for their thoughts. Here are the highlights from this season:
What was most significant/important/enjoyable bug you fixed this milestone?
The most fun one was moving database checkpointing into a different thread so our systems don’t occasionally halt for a second or two slowing down the site. But, really I imagine the one I’m enjoying most now was probably some trivial thing that reduced the number of my daily alerts from 9182739821731982739821 to just 123098218093.
–Witold
I fixed the iPhone app from crashing due to low memory.
–Tom
[Some engineering mumbo-jumbo… in sum, Nate] effectively eliminated the software constraints on the size of PDFs we can make.
–Nate
Fixing small bugs that made a big difference, and fixing things that never worked in the first place. For example, detecting the file extension when uploading receipts before we try to upload the receipt to the server and make it crash.
–Mich
How did you feel about this milestone?
[I enjoy the] fewer emails bugging me about junk. I no longer have 500+ emails each morning.
–Witold
People don’t like things that crash.
–Tom
I did not enjoy working on high bugs because I am a terrible tester and it would take me a very long time to reproduce many of these errors. However I do like the fact that my ToDo list is much much shorter than it used to be.
–Nate
Frustration: how do you reproduce something that is not supposed to happen? Relief: our big red bug count on the dashboard is not a number divisible by 100.
–Mich
Why was this milestone important? What did you get out of it?
[We now get] faster detection of new bugs.
–Witold
The product has become much more stable as a result of our focus on the bug hunt, and I think this will lay the groundwork for future required levels of excellence. Before, each new high bug was a drop in the bucket. Now it will be more like a gong at a funeral procession.
–Nate
The code is much cleaner now, so my OCD isn’t triggered everytime I look at it.
–Mich
Now that our Critical and High Bug count is approaching zero, the Engineering Team is experiencing a mix of feelings. It’s not that we were particularly attached to these bugs, or we’re going to miss them or anything. It’s more of a fresh, clean start feeling, a blend of nervousness and excitement for what comes next. It’s time to stop looking at old code and start creating new one.
May all those bugs rest in peace.
I just read this article about how someone made a Firefox extension to steal sessions from popular websites. Are you kidding me? Security isn’t an easy thing, I’ll admit. And maybe we take security to the extreme. But seriously, it’s amazing how many other sites don’t even do the basics. When choosing any service that involves sensitive information, especially sensitive financial information, I’d suggest always looking for the following:
- Make sure the address starts with https://. (Sometimes this is replaced with an icon of a little padlock.) This means it’s using the “secure” version of HTTP, which is the protocol that powers the web. Make sure it’s there from they very first page you load, and stays there as you browse the site. Sure, it’s a bit more expensive for the company. But it’s the least we can do.**
- Look for PCI compliance. Or, if not that (because it’s pretty intense), at least *some* indication they’re using a third-party approved security framework.
- Look for strong partnerships, such as banks and financial institutions. These guys take security really seriously, so if they’re on board, it’s another vote in the site’s favor.
Real security often isn’t easy. But most important things aren’t.
-david
** Note: I should highlight that this blog doesn’t use HTTPS, but it’s also not asking you for anything. When you sign in to Expensify proper — at https://expensify.com — every connection is secure.
Remember when Danger lost all their backups? At that time I wrote about Expensify’s massively redundant, multi-tiered backup system (to two remote locations in realtime, and to two more remote locations nightly) in a passionate appeal to sanity. Soon after that I turned off my Sidekick for the last time, and turned on my shiny new Palm Pre. (And I ain’t going back!)
But now I read that RockYou has compromised the usernames and logins to 32 million social networking accounts because they didn’t encrypt a damn thing? Come on people! Encryption is so… I don’t know, 1942?
At Expensify, we take security incredibly seriously. We spent pretty much the entire first year building a geo-redundant, PCI compliant datacenter that achieves… actually, now that I think about it pretty amazingly high uptime, while simultaneously remaining super secure. It wasn’t easy. But that’s our job. It’s not an optional thing. Either you do it secure, or you don’t do it at all.
In our case, we use a type of encryption called “split knowledge, dual control”. It’s more complex than this, but we basically split our master encryption key in half, and store each half in a different safe deposit box (Witold controls one, I control the other) such that nobody ever knows the whole thing. This means nobody can decrypt our data alone, not even me.
Additionally, this key is assembled in memory on our servers using a type of “turn two keys simultaneously” system (akin to a nuclear launch panel) and never written to disk. So even if you physically stole the servers out of our hardened datacenters (something you’d be a fool to try), they’d be little more than really expensive paperweights.
Anyway, I understand social networking data isn’t as sensitive as financial data. And I understand most web developers don’t know how to deploy and maintain realtime distributed transaction layers.
But I don’t find those very satisfying excuses, and I doubt you do either.
You might have read how Danger, the company that manages the Sidekick phone, managed to, uh, lose all its data. Like *all* of it. For all customers. Irrecoverably.
Granted, I’m probably following this story closer than most because I have a Sidekick in my pocket. (Actually, it’s not in my pocket this instant because it’s plugged in lest it run low on batteries and lose all its data forever.) I hosted the first developer dinner, when it was still called the Hiptop. I wrote its first calculator. (That’s right, it originally shipped without a calculator or an alarm clock.) I’ve upgraded through four different versions of the handset. I’ve been a loyal customer. Even when Sidekick retargeted its marketing to blinged-out rappers, I stuck by its side(kick).
So the fact that they completely blew this totally basic operation is simply infuriating. I mean, come on. This isn’t hard stuff. There are so many spectacular ways for problems to arise, but no backups? That’s just… demoralizing.
Anyway, why am I taking this depressing walk down memory lane? So I can say this: I commit to you, loyal Expensify users, that this will never, ever happen to you. Not on my watch. (And given that I’m the CEO, my watch is 24/7.)
Here’s why:
Expensify runs three geo-redundant datacenters, located in three different cities using different ISPs, replicated in realtime using distributed two-phase commit transactions. This means even if two of those cities suddenly fell off the face of the earth, we still wouldn’t lose a single transaction. Furthermore, we do 2 different nightly backups of the database to a storage volume that itself is backed up many times over — in entirely different datacenters. All this is encrypted in more ways you can count (including ways that even I don’t have the authority to decrypt), with procedures in place for how to recover from backups or even rebuild the entire site from scratch at a moment’s notice.
Anyway, I don’t know where I’m going with this. It’s just so absurd for a company like Microsoft to lose *everything* on their customers. I mean, we back up even our *log files* twice nightly. To not back up your customer data is downright offensive. Security and reliability aren’t just good ideas. They’re obvious ideas. Obvious ideas that we take incredibly seriously, even other trusted names don’t.
No matter who you are, no matter how careless you are, you can use Expensify.
