AMOS
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
How the system fits together.
The calls that shaped it.
- 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.
- 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.
- 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.
- 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.
- 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.
The interesting work isn't the stack. It's the boundaries.
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