One foundation for employee-built apps.

The platform decides the plumbing.

Moshu is a workspace apps platform. A workspace app is a tool, an internal application, or a site that runs inside the company's identity and reaches the company's services through one SDK. The builder of an app decides what it does. The platform decides how it signs people in, where it stores data, how it sends a message, and where its logs go.

We did not rebuild those services. Each Moshu service is a thin adapter over a component the client already operated. The work was to give the adapters one consistent shape, and to make them the only path an app could take.

Context arrives with the request. When an employee opens an app, the platform has already established who they are, their team, their site, their role, their manager, and their language. The app reads this context; it does not collect it. A depot tool built in Hamburg works in Leipzig without changes because the site comes from the directory.

Access to a service is not access to everything behind it. Business data is scoped by the user's sites and by the app's declaration, and the owning engineering team approves write access. The controls described here cover what apps can reach; they do not replace the permission model of each underlying system.

Describe, preview, publish.

Employees build in Moshu with an AI-assisted builder. They describe the tool they need, check a draft in a preview, and refine it. The builder generates code against the Moshu SDK and a library of patterns: a form with an approval step, a board, a scheduled report, a site with pages. People who want to edit the code can. Most do not.

Every app declares what it uses. A declaration lists the services, data products, and audience of an app. The builder writes it, the publish step checks it against the code, and the runtime issues credentials only for what is declared. An app that does not declare shipment data cannot read it, whatever its code says. This was the difference from guidance: the constraint moved from the prompt into the platform.

One line of development. Each app has one draft and a list of published versions. There are no branches and no pull requests. Two people can edit the same draft; the editor shows who is present and what changed. Publishing creates an immutable version. Rolling back means publishing an earlier one. Builders never see a server, a container, or a deployment pipeline.

Review depends on the declaration, not the code. The review tier follows from the audience and the data classes an app declares.

Reviewers see the declaration, the preview, and the audit trail from the draft. They do not read generated code line by line, which would not have scaled. The platform team's involvement per app moved from integration work to reviewing a declaration.

Thirty-one apps on the same services.

By August, fourteen teams had published apps on the platform. The examples below show the range. Their common pattern was a small tool, owned by the team that needed it, using services it would otherwise have had to rebuild.

Twenty-one of the 31 apps replaced tools found in discovery. Ten were new. The delay notice app is the only one that uses model access; a customer service agent still approves every message before it is sent.

From a photo in the yard to a manager's decision.

The damage report app shows how the pieces fit together. A driver finds damage on a trailer during the pre-departure check. Before Moshu, the depot used a Lovable form with its own login, an email to a shared mailbox, and photos in a personal cloud folder.

1. 01 · Sign in Open the app on a phone

   The driver opens the app from the workspace and is signed in through single sign-on. There is no separate account and no password.

2. 02 · Context Know the driver and the vehicle

   The platform supplies the driver's depot and shift. The app reads the assigned vehicle from fleet data, scoped to that depot.

3. 03 · Capture Record the damage

   The driver takes photos and marks the location on a trailer outline. Files go to platform storage under the retention class for vehicle records.

4. 04 · Decide Keep the decision with the fleet manager

   The fleet manager receives a Teams message through the notification service, checks the report, and decides whether the vehicle leaves or is blocked.

5. 05 · Record Keep the trail

   The decision, the evidence, and every access are written to the audit log. Errors and usage appear in the observability stack under the app's name and version.

The app processes employee data, so it was published in the Organization tier. The Data Protection Officer reviewed the declaration and the retention class. The works council was informed that the app records who reported damage and when, and that it does not evaluate driver performance. That review took four working days.

The builder, a dispatcher at the depot, produced the first draft in an afternoon. What took longer was agreeing the retention period and the wording of the notice to drivers, which no platform can shorten.

The constraints had to live in the platform.

The builder followed the contract only when the runtime enforced it. Early versions of the builder still generated direct network calls, embedded credentials, and local user tables when a prompt hinted at them. Prompt changes helped and did not settle it. The publish checks and the runtime without egress did. Guidance alone had already failed before the engagement; the platform had to make the shared path the only path.

Directory groups did not match how teams worked. The directory organized people by cost center. Depot teams shared people across shifts and sites. Workspace groups owned by team leads, mapped onto directory groups, solved most cases. Keeping those memberships current became a maintained task with an owner.

Employee data needed a defined path. Under German co-determination rules, the works council has a say in technical systems that can monitor employee behavior or performance. The Data Protection Officer and the works council agreed a review path with the platform team, triggered by the declaration. Two apps that could rank individual drivers by performance were not published; they require a works agreement that was still under discussion at handover.

Some apps outgrew the model. Two apps grew into products with several contributors, integration tests, and change requests from other departments. They moved to engineering-owned repositories, still using the Moshu SDK and runtime. One draft, one owner, and immediate publication suit tools; they do not replace product engineering.

Ownership had to be explicit. When a builder left the company, two apps had nobody responsible for them. Every app now has an owner and a deputy. Apps whose owner leaves are flagged, and are unpublished after a grace period if nobody claims them.

The platform team took ownership.

Two client platform engineers paired with Sinumo from the first sprint and had commit ownership by June. At handover, the team owned the platform, the builder, the service adapters, and the review tooling. The identity and access engineer owned the group model. Reviewers for each data class were named.

• Code and infrastructure for the platform, the runtime, and the service adapters, as infrastructure as code.
• The builder's pattern library and evaluation suite, which checks that generated apps use the SDK correctly and pass the publish checks.
• Operating guides for the runtime, quotas, service adapters, and incident handling.
• A written publication policy covering tiers, data classes, the works council path, and app ownership.

The account also records two services added by the client after August: label printing at depots and electronic signatures. Both followed the adapter pattern. They are separate from the twelve services counted at handover and reflect the objective of giving the platform team a system it could extend.