LARA
Internal platform for service planning and resource sizing.
An internal application for planning services: defining work fronts, sizing the resources each one needs, and generating the resulting requirements. Built on the same backend foundations as MIRA, for the execution side of the business.
Proprietary system — no source code is shared.
- Status
- In production
- Period
- January 2026 — present
- Context
- Metso · Internal system
- Domains
- Planning · Work fronts · Requirements
The problem
Deciding what personnel each industrial service needed ran on email. A planner filled in a spreadsheet template, attached it, and sent it. A correction meant another email with another attachment, and the templates themselves drifted — no two arrived in quite the same shape. The current version of a plan was whatever was latest in someone’s inbox, and the history of how it got there was spread across a thread. Nothing about that record could be queried: not which services had been sized, not what changed between versions, not which plans were settled early and which were still moving days before execution.
Approach
- 01Modelled planning explicitly: services, work fronts, resource sizing and the requirements they generate.
- 02Versioned every sizing, so a plan has a history instead of a thread — what changed, when, and who changed it.
- 03Kept email as a notification channel rather than the system of record: the message tells you to look, the platform holds the answer.
- 04Turned a manual sizing routine into a repeatable calculation backed by a REST API.
- 05Produced requirements directly from the plan, removing a re-typing step between planning and execution.
- 06Made planning behaviour analysable — how far ahead each plan is settled, and how much it moves late — which was unrecoverable when the record lived in inboxes.
Architecture
How it is put together.
FastAPI + SQLAlchemy over SQL Server
The same backend stack as MIRA, deliberately — shared conventions, shared operational knowledge.
React + TypeScript client
Planning screens where the interaction is genuinely stateful: building fronts, adjusting sizing, reviewing generated requirements.
Planning domain model
Work fronts and resource sizing as first-class entities rather than rows in a sheet, so a plan can be revisited and explained.
Stack
- Backend
- Python
- FastAPI
- SQLAlchemy
- Front end
- React
- TypeScript
- Data
- SQL Server
Outcome
- 180 services sized in the first six months, each with a versioned record of how the plan was built.
- Monthly reporting now runs off a single dashboard: what planners record in LARA becomes the view of which resources need to be contracted each month.
- Standardised how service plans are built and sized.
- Made planning itself measurable: which plans settle early and which move late is now a query, not an archaeology exercise across inboxes.
- In production since March 2026, in daily use by the planning team.