HeyPuter Everything: An MIT-Licensed Monorepo of Web Applications

What HeyPuter Everything Contains

HeyPuter Everything addresses a broad problem: replacing proprietary application categories with software that can be inspected, modified, and hosted under an open-source license. Its intended users are not limited to one profession. The repository includes applications aimed at office document work, meetings, team communication, email, contacts, records management, and other categories. The visible catalog positions Spreadsheet as an alternative to Microsoft Excel, Google Sheets, and Apple Numbers; Documents as an alternative to Microsoft Word, Google Docs, and Apple Pages; Presentation as an alternative to Microsoft PowerPoint, Google Slides, and Apple Keynote.

That scope matters because Everything is a mono-repository rather than one deployable application. Based on the repository layout, applications are stored separately under paths such as src/spreadsheet/, src/documents/, src/presentation/, src/meetings/, and src/teamchat/. Each listed application has its own source directory. This arrangement lets a developer focus on one app without installing or evaluating the entire collection as a single product.

The project is more accurate as a source collection than as a unified office suite. The README does not state that the applications share a user account, common file format, deployment process, or integrated editing environment. Calling the repository a complete Microsoft 365 or Google Workspace replacement would therefore exceed the documentation. Its clear value is access to many separate MIT-licensed application codebases, while feature equivalence and cross-application integration remain unstated.

The Monorepo Structure and Application Flow

The repository layout separates shared project infrastructure from application code. Top-level entries include src/, assets/, dev/, .github/, amplify.yml, and customHttp.yml. Applications have their own directories below src/, while icon files and source links appear alongside the relevant catalog entries. This points to a frontend-oriented development model, and JavaScript is the primary language.

The README supplies hosted URLs for several applications, including Spreadsheet, Documents, Presentation, Whiteboard, PDF, Records, Meetings, Teamchat, Contacts, and other entries visible in the catalog. It also links each application to its directory in src/. Those two paths serve different purposes: the hosted site offers a browser-based destination, while the repository provides source for local development. The documentation does not explain the backend services, persistence layer, synchronization protocol, authentication system, or production deployment architecture for an individual app.

That missing detail is consequential for adoption. A source directory and a live URL do not establish that a local instance will have the same backend, account system, storage behavior, or collaboration features as the hosted version. The repository metadata includes amplify.yml, but the README does not say which application uses it or explain its settings. Likewise, customHttp.yml is visible without documented responsibilities. Engineers should treat the repository as a collection of frontend sources unless the selected application's own files define the required services.

Running Spreadsheet From the Repository

The README documents one generic local-development path rather than per-application instructions. It requires Node.js 22.12 or newer and tells contributors to clone the repository, enter an application's directory, install its npm dependencies, and start its development script. Spreadsheet is a concrete first target because the catalog provides both a hosted URL and a source directory at src/spreadsheet/.

The following commands are copied from the README. Replace the bracketed application name with the directory selected by the reader. The README does not state what URL or terminal message appears after npm run dev, so those details cannot be confirmed here.

git clone https://github.com/HeyPuter/everything.git
cd everything/src/[app-name]
npm install
npm run dev

A first useful check is whether the selected directory installs cleanly under Node.js 22.12 or newer and whether its development server exposes the application expected by that app's own source. After that, open or create a basic spreadsheet through the running interface, then inspect how the app handles an ordinary cell entry. The README does not identify supported file formats, maximum workbook sizes, formula support, or collaboration controls, so those checks must be made against the selected app rather than inferred from the project description.

For developers wanting only a hosted trial, the README provides https://spreadsheet.puter.com/ for Spreadsheet. That URL can be used before cloning, but hosted availability and local feature parity are separate questions. The README establishes neither parity nor feature completeness.

Office and Collaboration Alternatives Have Different Boundaries

Everything takes the position that proprietary software categories can be rebuilt as open-source alternatives. The strongest breadth is visible in the catalog: Documents, Spreadsheet, Presentation, Whiteboard, PDF, Notes, Records, Meetings, Teamchat, Email, Contacts, and Calendar are all represented by named projects. Creative and engineering alternatives appear in the project topics and introductory scope, including Photoshop and AutoCAD.

The practical alternative is therefore not one product for one product. A prospective Everything user may consider it against the named reference applications in different ways. Someone evaluating spreadsheets may compare local source access and licensing with the account, file, and collaboration model offered by Excel or Google Sheets. Someone evaluating Meetings may compare it with Zoom, Google Meet, or Microsoft Teams. The README lists those alternatives but provides no feature matrix, interoperability statement, deployment guide, or account requirements. It does not justify assuming functional equivalence.

A more mature adoption route may be to use an established office or collaboration service and retain its documented compatibility and support model. The difference is architectural and operational, not simply a claim about code quality. The available repository information does not document migration support, enterprise administration, compliance controls, offline behavior, service availability, or technical support for either approach.

Feature Parity, Persistence, and Collaboration Are Undocumented

The largest limitation is the gap between category labels and operational documentation. The README identifies an application as an alternative to several established products, but it does not enumerate implemented commands, keyboard shortcuts, formats, APIs, or interoperability levels. For an office suite, even basic claims can conceal important differences: a spreadsheet may handle formulas without matching Excel workbook features, while a documents editor may save a file without preserving every layout property.

Collaboration introduces a separate unknown. Meetings and Teamchat are presented as alternatives to dedicated communication services, yet the visible README does not describe identities, presence, permissions, call quality, message retention, notifications, or data storage. The same issue applies to Email and Calendar. Their names establish intended categories, not verified feature sets.

Based on the top-level entries, Amplify configuration and custom HTTP configuration may be relevant to deployment, but the README does not map either file to an application or explain required services. Engineers should therefore not infer that cloning one directory creates a self-contained production platform. Any backend dependency, account connection, storage requirement, or external service must be confirmed from that app's own files before the project is placed into an evaluation environment.

There is also no GitHub release history. Without versioned GitHub releases, the repository does not give users a release feed to consult before upgrades or a conventional package version to anchor an operational decision. The last push was on 2026-10-16, which indicates recent repository activity, but it does not establish the maturity of every application.

MIT Licensing and Monorepo Upgrade Scope

The repository is licensed under MIT. That provides an open-source licensing basis for studying, modifying, and distributing the covered code, subject to the license text and applicable obligations. The README does not identify separate licenses for hosted services, trademarks, third-party packages, fonts, or other assets. License review should therefore cover the selected application, its dependencies, and any separately deployed services rather than assuming that the repository-level label answers every distribution question.

The mono-repository has a direct effect on maintenance. A pull request, dependency update, or shared configuration change can affect a project-wide surface even when development begins in one application. The README's setup path installs dependencies after entering an app directory, which limits the initial installation scope, but the documentation does not explain workspace configuration, shared package versions, migration procedures, or compatibility between apps.

No GitHub releases are available, so upgrade planning cannot rely on published release notes or a simple release-to-release upgrade guide. The absence of releases does not mean that development has stopped. The repository is not archived, and its last push was on 2026-10-16. The practical boundary is that repository activity and application-specific stability are different facts, with only the former documented here.

Editorial conclusion

Everything fits developers who want to inspect or run one of its individual open-source web applications under the MIT license. It is a poor fit for organizations expecting a documented, feature-complete office suite with release notes, migration guidance, and stated compatibility guarantees. Before adoption, inspect the selected app under src/, run its documented npm development command, and verify that it covers the actual files and workflows required by the project.

Frequently asked questions

Official sources

1. HeyPuter/everything on GitHub
2. Issues
3. License: MIT
4. README