Back to all work
— Project 01
Internal SaaS platform

AMOS

Asset Management Operations System

AMOS is the operations hub Aspen’s asset team uses every day to run a fleet of solar sites from one place. It started as a six-figure outsourcing proposal; I built a prototype in a few days, made the case to bring it in-house, and took ownership of the product decisions, design, engineering, and launch. It has been in daily production use since.

Role
Solo Founder + Lead Engineer
Period
2024 to present
Status
Production
FastAPISvelteKitPostgreSQLOpen Policy AgentWebSocketSelenium E2E
— Chapter 01
System shape

How the system fits together.

Click a block to zoom in
The production system at a glance. Click any block to see how that part works.
Fig. 01 — AMOS architecture
— Chapter 02
Decisions and outcomes

The calls that shaped it.

  1. 01

    I took it from an outside vendor’s proposal to a product I own end to end. The biggest growth wasn’t technical — it was learning to make the call on what to build, what to cut, and what “done” actually means.

  2. 02

    The whole idea was to give the team one calm place to work. Data that used to be scattered across several monitoring platforms and spreadsheets now lands in a single, fast interface, so people spend their time on decisions instead of hunting for information.

  3. 03

    Different roles need to see and do different things, so I built access control that admins manage themselves — no engineer in the loop to change who can do what. Getting that boundary right matters more than any one feature.

  4. 04

    It has to be dependable, because the team leans on it daily. Everyone sees live updates in real time, automated testing catches regressions before users do, and I keep it fast as the workload grows.

  5. 05

    I brought machine learning into the workflow too — forecasting site output and flagging equipment likely to fail in the next couple of weeks — so the team can act before something breaks, not after.

— Aside
The interesting work isn't the stack. It's the boundaries.
— Chapter 03
How it runs

What it runs on.

  • 01
    Python / FastAPI backend with a SvelteKit front end
  • 02
    PostgreSQL for data, with a Valkey cache in front so the app stays fast
  • 03
    Open Policy Agent enforces permissions as code
  • 04
    Live updates over WebSockets
  • 05
    Machine-learning models for forecasting and failure prediction
  • 06
    Runs on AWS with automated, zero-downtime deploys