Ship Operation System Operations Platform

1. About the Client

• Industry: Shipbuilding and offshore (ship operation systems)
• Target users: Operations staff who remotely inspect and service ship systems from shore
• Challenge: Moving work done with tools installed on personal equipment to an intranet web platform

This is an NDA project, so the client's name, the system names, internal operating procedures and the security configuration are not disclosed. We were responsible for web platform development.

2. Background

Systems installed on ships are inspected and serviced remotely from shore. For a long time this work was done with tools installed on the staff member's laptop. When the tools live on personal equipment, three problems follow.

What happens when the tools are on personal equipment

First, work records are scattered across individuals. To find out who took which action and when, you have to ask the person in charge. Second, procedures differ from person to person. If the order and scope of the same inspection vary slightly depending on who does it, it is hard to narrow down the cause when a problem occurs. Third, when the person in charge is away, the work itself stops.

Moving to a web platform

From March to May 2026, we moved this work to an intranet web platform. Work that staff used to do with their own tools is now carried out on a single screen, and execution results are recorded automatically. We were responsible for web platform development.

The goal was not to automate the work but to standardize it: to reach a state where the same work is carried out by the same procedure, and a record of it remains.

In one line The goal was not to automate the work but to standardize it.

3. Key Features

We moved the functions of the existing desktop tools to a web platform and added the management functions needed for operation.

We separated running a task from checking its result. Remote tasks take a long time and can fail partway. We split the part that accepts execution requests from the part that actually carries them out, so the screen does not freeze even when a task takes a long time, and the result is reflected when it completes.

Every execution leaves a record. Who performed which task on which target, and what the result was, is stored. This provides evidence to check when a problem occurs, and the task history itself becomes an operational asset.

Permissions are managed by role. The tasks a user can perform and the targets they can access differ from user to user. We built it to check permissions at the execution stage, not by hiding screens.

Main features

Task list management

The tasks that can be performed are managed as a list. Instead of finding and using individual scripts, staff select from the registered list and run it. This is the mechanism that keeps procedures from varying by person.

Remote execution

The selected task is performed remotely on the specified target. Execution requests and execution are separated, so the screen is not tied up in a waiting state even when a task takes a long time.

Execution history

Every execution is kept as a record. The operator, target, time and result are stored and can be looked up later.

Connection status check

The connection to the target system is checked in advance. If a task fails because of a connection problem after it has started, identifying the cause is delayed, so we provided a separate procedure for checking before execution.

Permission management

The tasks that can be performed and the targets that can be accessed are separated by role. In an operations tool, separating permissions is a basic condition for preventing incidents.

Audit log

Actions that affect the system itself, such as permission changes or configuration edits, are also recorded. Operational accountability can only be handled when it is possible to check what changed and when.

4. Outcome

We moved the operations tools that used to sit on staff members' personal equipment to an intranet web platform. The same work is now carried out by the same procedure, and what was performed remains as a record.

With task execution separated from result checking, the screen no longer freezes during long-running remote tasks, and failed tasks can be checked separately.

With permissions divided by role and audit logs kept, who can do what and what was actually performed are now managed together.

Development took about three months, from March to May 2026.

5. Technology

Web — An operations portal based on Next.js and TypeScript. Since it is a tool used on the intranet, external dependencies were kept to a minimum.

Task processing — Execution requests are put in a queue and carried out by a separate process. Long-running tasks do not hold up screen responses, and the status of failed tasks can be tracked.

Data — PostgreSQL and Prisma ORM are used. Execution history and audit logs remain as data.

Structure — The project is organized as a monorepo, with the web app, task processing, domain rules, execution engine and logging utilities split into packages. The web app and the task processing process share the same domain rules, so the same criteria apply whichever side runs a task.

Deployment — Deployed to the intranet environment on a container basis.

Design criteria — The most important thing in this platform is the record. Leaving a record of what was performed takes priority over making the work faster. Consolidating the execution path into one and leaving a record of every execution are decisions that came from this criterion.

6. Project Information

Item	Details
Project name	Ship Operation System Stabilization (Operations Platform Build)
Scope of work	Web platform development
Technologies	Next.js, TypeScript, Prisma, PostgreSQL, task queue, container deployment