Expensify/App: what the open source New Expensify codebase actually is
Welcome to New Expensify: a complete re-imagination of financial collaboration, centered around chat. Help us build the next generation of Expensify by sharing feedback and contributing to the code.
At a glance
- What is it?
- New Expensify is Expensify's chat-first rewrite of its expense product, and Expensify/App is the public repository behind it. This is a review of what the code ships, how a contributor gets it running, and where it stops being the right tool.
- Who is it for?
- Adopt Expensify/App if you want to read or contribute to the New Expensify client, or if you are evaluating a chat-first expense interface before committing your team to it. Do not adopt it as a self-hosted expense server: the README documents a local client that talks to Expensify's hosted API and partner credentials, not a deployable backend.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 2, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The problem Expensify/App addresses, and who it is written for
Expensify/App is not a library you import. It is the client application for New Expensify, described in package.json as "a reimagination of payments based atop a foundation of chat". The problem it addresses is architectural: expense reporting tools usually bolt a chat or comment thread onto a form-driven workflow, while this codebase treats the conversation as the primary surface and the report as something that lives inside it. The repository is the working code for that bet, and it is public under the MIT licence.
The intended audience is narrow and specific. The README opens with local development instructions, a strict Node and npm version pinned in package.json engines and .nvmrc, and links to contributing guides for API details, application philosophy, code of conduct and a contributor licence agreement. This is a repository written for people who will send pull requests, not for teams looking for a package to install into their own product. If you are shopping for an expense backend, you are in the wrong place, and the README never suggests otherwise.
How the client, the API and the local proxy fit together
The data flow visible in the repository is client to hosted API. The environment file defines NEW_EXPENSIFY_URL, SECURE_EXPENSIFY_URL and EXPENSIFY_URL, and the .env.example points SECURE_EXPENSIFY_URL and EXPENSIFY_URL at expensify.com.dev hosts rather than production. Authentication uses EXPENSIFY_PARTNER_NAME and EXPENSIFY_PARTNER_PASSWORD, which the README explicitly notes is fine to be public. Real-time updates come through Pusher, keyed by PUSHER_APP_KEY.
Because the browser and the API live on different origins, the README warns that external contributors will hit CORS errors unless USE_WEB_PROXY is set to true, which starts a second server alongside the development server to proxy requests to the backend. That is the single most important configuration fact in the document, and it is flagged with a warning symbol in the README itself. State management runs through Onyx, Expensify's own store, and USE_REDUX_DEVTOOLS enables Redux DevTools for debugging it. Optional instrumentation is available through CAPTURE_METRICS and ONYX_METRICS, both of which surface in Flipper.
The repository also carries a Mobile-Expensify submodule and .gitmodules at the top level, so a plain clone without submodule initialization will not give you the full tree. That is a real friction point the README does not walk through.
Installing Expensify/App locally and running the web build
The README gives a four-step getting started path. Install nvm, then Node and npm; install watchman; install dependencies; then run a platform script. The strict Node version matters because npm install fails if the version does not match what package.json engines and .nvmrc define.
brew install nvm && nvm install
brew install watchman
npm install
npm run webAfter npm install completes, npm run web starts the web build. The scripts entry for web wraps ./scripts/set-pusher-suffix.sh, so the Pusher channel suffix is set before the build runs. If you see CORS errors in the browser console referencing BeginSignIn, the README's advice is that your .env is misconfigured: remove it with rm .env and try again. External contributors should instead set USE_WEB_PROXY to true.
The README advises external contributors against creating an .env file at all, because a local copy is ignored when upstream variables change. Mobile platforms have separate guides: contributingGuides/SETUP_IOS.md and contributingGuides/SETUP_ANDROID.md, reached through npm run ios and npm run android. The README also notes an optional Claude Code skill at .claude/skills/agent-device/SKILL.md for driving simulators, which requires npm install -g agent-device.
Tests split across two runners. Jest covers components via npm run test. The server directory plus the .github and scripts tooling tests run under Bun via npm run test:bun, and the repository pins a Bun version in .bun-version.
Where the repository stops being enough
The largest limitation is that this is a client. There is no documented path to standing up your own Expensify backend, and the environment variables point at Expensify-operated hosts. Self-hosting is not a supported configuration here, and the README does not pretend it is. If your requirement is data residency on your own infrastructure, this repository does not answer it.
The second constraint is toolchain strictness. Node and npm versions are pinned hard enough that npm install fails on a mismatch, which is good for reproducible builds and annoying if you work across several projects on one machine. On Windows, the README's getting started path is Homebrew-based, and platform guides are the only place detailed setup lives; the top-level README does not cover Windows directly.
The third is documentation scope. Environment variables are listed with one-line descriptions, but there is no documented rollback procedure, no migration guide between release lines, and no explanation of what the staging version tags such as 9.4.91-2-staging mean for anyone outside the project. The README is a contributor on-ramp, not an operations manual.
How this differs from a conventional expense reporting tool
The obvious comparison is a form-first expense product where you fill in a report, attach receipts, and submit for approval, with comments as an afterthought. New Expensify inverts that: the chat thread is the workspace and expenses are objects inside it. The repository reflects the inversion in its structure, with left hand navigation documented separately in contributingGuides/LEFT_HAND_NAVIGATION.md and an application philosophy guide that explains the design stance.
A second comparison is against building your own client on the Expensify API. The README links contributingGuides/API.md, so the API is documented, but the partner credentials in .env.example identify this app as chat-expensify-com, meaning the client is registered as a specific partner. Anyone building a separate client would be working against a different arrangement than the one this repository encodes. That is a meaningful difference in approach, not a detail.
Against a self-hosted expense system, the difference is simpler: those give you the server and ask you to run it. This gives you the client and asks you to contribute to it.
Maintenance, releases and what the licence does and does not cover
The repository is not archived, and the last push was on 2026-09-22. Releases are frequent and staging-tagged: 9.4.91-0-staging, 9.4.91-1-staging and 9.4.91-2-staging all landed between 2026-09-21 and 2026-09-22, and package.json version reads 9.4.91-2. That cadence cuts both ways. You get fixes quickly, and you also inherit a fast-moving dependency tree, which is why the pinned Node and Bun versions exist. There is no long-term support branch described in the README.
Upgrade cost for a contributor is mostly re-running npm install against the pinned versions and re-reading the platform guides when they change. There is no documented upgrade procedure beyond the note that stale .env changes may need rm -rf .rock before re-running npm run ios or npm run android.
The repository is MIT licensed, and the LICENSE.md file is at the top level. That covers the source in this repository. It does not govern the hosted service at new.expensify.com, and nothing in the README states otherwise. Treat the licence question for production use of the service as separate from the licence question for the code, and read the actual terms rather than inferring them.
Editorial conclusion
Adopt Expensify/App if you want to read or contribute to the New Expensify client, or if you are evaluating a chat-first expense interface before committing your team to it. Do not adopt it as a self-hosted expense server: the README documents a local client that talks to Expensify's hosted API and partner credentials, not a deployable backend. Before you invest time, verify that your Node version matches the engines field and .nvmrc, and check whether the platform you need has a setup guide under contributingGuides. The MIT licence covers this repository; it says nothing about the hosted service's terms.
Frequently asked questions
What is the Expensify/App repository used for?
It holds the source for New Expensify, described in package.json as a reimagination of payments built on a foundation of chat. The README frames it as a codebase to develop and contribute to, with local development, platform setup and test instructions.
How do I run the Expensify/App web build locally?
Install nvm, Node and npm, then watchman, then run npm install, and finally npm run web. The README warns that npm install fails if your Node version does not match the engines field and .nvmrc, so use nvm to manage it.
Why does the Expensify/App local build show CORS errors?
The README attributes BeginSignIn CORS errors to a misconfigured .env file and suggests removing it with rm .env. External contributors should set USE_WEB_PROXY to true so the proxy server runs alongside the local development server.
Is Expensify/App the same thing as the Expensify service?
No. The repository is the client code, and its environment variables point at Expensify-operated API hosts and use partner credentials. The README documents local development of the app, not deployment of a backend.
Does Expensify/App have a self-hosted option?
Nothing in the README describes self-hosting. The setup instructions configure a local client against Expensify's API hosts, and no server deployment path is documented.
What licence does Expensify/App use?
The repository is MIT licensed, with LICENSE.md at the top level. That covers the source code in the repository, and the README does not extend it to the hosted service.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/expensify-app)