Why I'm building Strawly

There are dozens of FinOps tools. Here's why I decided to build another one, and what I'm trying to prove in the process.

What small teams are stuck with

FinOps tooling has matured, but mostly upmarket: built for enterprise teams with dedicated practitioners and months to onboard.

01

Small teams pay enterprise prices, or go without

A team spending €500 a month faces the same per-seat licenses and percentage-of-spend fees as one spending €50,000. Most small teams opt out entirely and manage cloud spend through billing consoles and spreadsheets, so savings get missed and anomalies surface only when the bill arrives.

02

The goal: FinOps a small team can actually run

Strawly is my attempt at a different answer: a tool a three-person startup can self-host in an afternoon, that costs nothing to run beyond compute, and that gives you the visibility and optimization you would otherwise need an enterprise contract to get.

What I believe in

These aren't marketing points. They are the principles that shape every decision in how Strawly is built and distributed.

Source-available licensing

Licensed under the Source First License 1.1, with a grant that lets any organization run Strawly for free on the cloud accounts it owns. Fork it, read it, modify it, host it yourself. If the project disappears tomorrow, you keep everything. License details.

Your data, your infrastructure

Strawly is self-hosted. Your billing data never leaves your environment. There's no SaaS endpoint receiving your cloud spend, no vendor with a copy of your cost data.

Moving away from big tech

Strawly is self-hosted on a private Forgejo instance, not GitHub. I try to practice what I preach: a healthier software ecosystem means actively choosing alternatives where they exist and are viable.

Repairability

Software should be something you can open up and understand. Strawly is built so that a developer who has never seen it before can read the code, find what they need to fix, and fix it.

The joy of tinkering

I build things to understand them. Taking apart how something works (hardware or software) and putting it back together better is what drives this project forward.

An honest note

I work as a cloud engineer. My day job is Azure and AWS infrastructure, not application development. Strawly is the project where I learned to build one: the backend, the frontend, the database schema, the APIs that connect them, all from scratch.

The source is public because I want people to look. If you find something you'd do differently, open an issue or a pull request. That's how a one-person project gets a second set of eyes, and it's the fastest way I improve it.

Review the code before you run it anywhere that touches sensitive data. Feedback, bug reports, and pull requests are always welcome.