One workspace for the solo-business back office
Midday aims at the messy collection of tools behind a freelance business. Time tracking lives beside transactions. Receipts and invoices can be matched through the Magic Inbox, contracts can sit in a file vault, and financial data can be exported for an accountant. An assistant answers questions about spending and documents. The intended user is a consultant or small operator who wants one daily workspace instead of several subscriptions and spreadsheets.
The idea is easy to understand because the pain is real. A tracked hour eventually becomes revenue, a bank transaction needs a receipt, and an accountant needs a clean export. Keeping those records connected can remove repeated entry. Midday also lists bank integrations for Europe, Canada, and the United States, although the provider differs by region.
The README is less reliable as a feature contract. It still labels invoicing as upcoming, so readers should not silently convert that wording into a shipped promise. Evaluate the running product and current documentation for the exact workflow you need. The repository is moving, and the short front page does not try to document every current screen.
The architecture is much larger than the pitch
Midday is a TypeScript monorepo built around Bun, React, Next.js, Supabase, Tailwind CSS, Tauri, and Expo. That spans web, desktop, and mobile surfaces. Hosting is split across Supabase, Railway, Vercel, and Cloudflare in the project's own deployment. Background work uses Trigger.dev, email uses Resend, search uses Typesense, payments use Polar, and analytics use OpenPanel. Gemini and OpenAI are also named services.
This matters more than the friendly product screenshots. Self-hosting the code means deciding which parts of that topology to reproduce and which providers to replace. Bank connectivity adds GoCardless, Plaid, or Teller credentials depending on geography. A team can run only the features it needs, but it must understand the boundaries between the dashboard, API, worker, database, storage, authentication, and external callbacks.
The README sends local developers to docs.midday.ai and says that getting-started documentation is being worked on. It provides the technology and service inventory, yet no complete local recipe on the page itself. That is a weak handoff for a project with this many moving parts. Experienced platform engineers can follow the monorepo and environment templates; a freelancer expecting a Docker Compose file will find a different class of project. There is no Dockerfile in the measured checkout.
What happened when we ran it
We cloned commit 5158731 into a fresh Debian container with three CPUs, 8 GB of RAM, no secrets, and an unprivileged user. The repository contained 2,508 files, roughly 352,123 lines of source, and took 71 MB before dependency installation. It uses Bun workspaces. Installing 2,435 packages succeeded in 55 seconds, but the installed tree occupied 3,422 MB.
The test command succeeded in 15 seconds. Our measurement did not provide a test count, so that result should be read only as a successful repository test target. The checkout has three CI workflow files and no top-level tests directory. Tests may live with packages in the workspace, which is normal for a monorepo.
The build did not finish. It exited with code 1 after 77 seconds. Five of six tasks succeeded, and the failing task was @midday/email#build. The final lines show React Email calling through nypm, followed by the package's build script exiting with code 1. They do not include the first error or name a missing dependency, so blaming a system package, network restriction, or code defect would be guesswork. The actionable fact is simpler: the fresh checkout installed and tested, then failed to produce a complete build.
For a prospective operator, that is a meaningful warning. The basic dependency step is repeatable, yet the repository consumes several gigabytes and a production build needs investigation. Reproduce the email package failure with the full log before planning deployment work.
Licensing and security need decisions before launch
The repository contains an AGPL-3.0 license, while the README says it is licensed under AGPL-3.0 for non-commercial use and asks commercial deployments to contact Midday. Open issue 785 argues that this wording conflicts with the standard AGPL text. We are not resolving that legal question here. A business should ask Midday for written terms or have counsel review the repository license before building a paid service around it.
A separate open report, issue 890, alleges that an ordinary team member can call the team deletion procedure because the relevant access check does not require the owner role. The reporter supplies affected paths and a reproduction, and says a May email received no response before the public June report. Another August issue presents several static-analysis findings, including a claimed webhook verification fallback. These are user reports, not maintainer-confirmed advisories, but the team-deletion claim is serious enough to verify before any multi-user deployment.
Project health and the buying decision
The last repository push was June 13, 2026. The latest tagged release, midday-v0.5.0, arrived February 15 and added a desktop download. GitHub reported 16 open issues and pull requests combined. Issue updates continued after the last push, including the licensing discussion in July and a security-audit post in August. That mix suggests continuing outside interest, while the visible code and release activity is slower than the project's audience size might imply.
Midday is most convincing as a product concept and a codebase for teams that want its exact combination of banking, documents, time, and assistant features. It is less convincing as a turnkey self-hosted package. The infrastructure list, build failure, unresolved license wording, and authorization report all create work before launch. Use a staged environment, begin with one bank region and one worker path, and require a clean build plus targeted authorization tests before importing real financial records.