One private place

All your internal tools. One private place.

Platform Zero gives your team one private suite for login, docs, files, chat, notebooks, dashboards, automation, monitoring, and specialist tools. Use it when you want a clean operating layer from day one, not ten separate products stitched together later.

Draft the stack brief Review the repo

The brief asks for five things: roles, workflows, first modules, tools that stay outside, and the person who reviews the repo. Business readers see the suite here; technical reviewers inspect the build in GitHub.

For clean starts For private internal tools For teams that need proof before rollout
Stack decision Choose the work. Verify the build.
Business surface Roles, workflows, modules

Name the work the suite must contain before arguing about individual apps.

Technical surface Repo, manifests, verification

Give technical reviewers the build contract without turning this page into docs.

  • One identity layer across the private suite
  • Optional modules selected around actual workflows: docs, files, chat, dashboards, notebooks, automation
  • Generated deploy bundle with private site inputs kept separate
  • Verification scripts and screenshots for technical review

What you get

Run it. Explain it. Review it.

One login

People reach the private tools through a shared identity model instead of learning a different access story for every service.

One deployable shape

The suite is assembled from manifests, modules, generated files, and deploy scripts, so it has a real operating shape beyond the screenshots.

One module catalogue

Choose the tools that belong together for the work: knowledge, communication, files, dashboards, automation, notebooks, media, search, alerts, and operations.

Use it when

Start clean. Stay coherent.

01

Open one work surface

Give the team one place to work across docs, files, chat, planning, dashboards, notebooks, alerts, and operational tools.

02

Set the pattern early

The first module establishes login, deployment, monitoring, and review habits before more services are added.

03

Choose by workflow

Pick services because they create a useful operating surface together, not because each app won a separate procurement argument.

What is included

Built from parts reviewers can inspect.

The page stays business-readable. The proof path stays technical: shared identity, generated deployment, selected service modules, monitoring, visual evidence, and repository docs.

Shared login

Selected services join the same login pattern, so the suite feels like one environment instead of unrelated products.

Generated deploy

Build from a manifest, sync the generated output, deploy it, and verify the result from a repeatable contract.

Public core, private shape

The generator stays generic while credentials, module locks, activation choices, and private overrides stay outside it.

Monitoring checks

Readiness checks, service evidence, and visual captures make the running suite easier to inspect.

Modules

Add knowledge, files, dashboards, automation, collaboration, search, media, notebooks, and site-specific tools where they serve the workflow.

Technical review path

Technical stakeholders can inspect the source, module contracts, manifests, docs, and scripts in GitHub.

Proof without theatre

See the suite. Verify the build.

Claim

Platform Zero is a private operating suite made from a shared login layer, external site configuration, module-based services, deploy scripts, monitoring, and verification.

Proof now

The public repo shows the generator, docs, module catalog, source layout, build entry point, deployment contract, and verification flow.

Claims left out

No invented ROI, fake customer logos, uptime theatre, or certification language. Those claims need site-specific evidence before they belong on the page.

How to shape it

Design around the work.

1

Name the work surface

List the roles, workflows, data boundaries, and tools that should live inside the private suite.

2

Choose modules

Select the services that create the operating surface: knowledge, files, chat, dashboards, notebooks, automation, monitoring, and specialist tools.

3

Send reviewers to source

Use the repo, docs, module contracts, manifests, and scripts when someone needs to inspect how the suite is generated.

4

Operate with checks

Keep the stack tied to source, configs, locks, docs, screenshots, and verification so the suite stays legible as it grows.

Best fit

Best for teams that want their internal software to feel like one private suite.

Good fit when you want

  • A private home for core internal software
  • One login pattern across many useful services
  • Public platform code separated from private site inputs and credentials
  • Custom modules without giving up repeatable builds
  • A technical reviewer who can inspect source, manifests, and deploy scripts

Bad fit when

  • You only need one hosted app.
  • Your team wants a vendor to own the whole operating surface.
  • Your main requirement is buying a polished SaaS dashboard.
  • You need ROI, uptime, or certification claims before site-specific evidence exists.

Technical reviewers

Verify in the repo.

The screenshots show the breadth of the suite. The repo shows whether the generator, module contracts, build entry point, deployment contract, and verification flow are real.

GitHub source Generator source

Review the source of the generator, build entry point, docs, schemas, and deployment contract.

 Docs Architecture notes

Send technical stakeholders directly to the docs for implementation detail.

 Modules Module contracts

Inspect how deployable overlays, private modules, and site-specific locks fit the platform model.

Next step

Draft the suite brief.

The next step is a short stack brief: who uses the suite, what work it should contain, which modules matter first, what stays outside, and who reviews the technical proof.

Email-ready brief

After that, the review is concrete: choose the first module set, identify private module work, keep external tools where they make sense, and send the technical reviewer to the repo.

Open the stack brief email Open the technical repo Review capabilities