← All posts

May 3, 2026 · 3 min read

Building two free tools made me realize what I actually wanted Wooven to be

founder-storywoovenwhy-i-built-thisjourney

The hook

Over the last two weeks I open-sourced two small tools — a deployment cost calculator and a package.json vendor lock-in auditor — in the woovendev/wooven-publish repo.

I built them because I wanted to use them on my own projects. Building them in the same fortnight is what clarified the product thesis I'd been struggling to put into one sentence.

A hosted, point-and-click version of each is on the roadmap; today they live as source you can read, run, and pull apart.

Two tools, one through-line

Cost calculator: estimate your bill on a managed platform vs. an equivalent self-hosted setup before the bill arrives.

Lock-in auditor: scan a package.json for vendor-specific dependencies and surface the migration cost before you're under deadline to leave.

Different inputs. Same posture: give the operator the numbers earlier than the platform would.

That posture is the part I want to keep across whatever Wooven becomes.

Why this framing matters now

The deployment platforms I rely on are genuinely good products. I'm not interested in a "platform X is evil" post — those are easy to write and rarely true.

What I do think is true, based on the public migration threads, billing post-mortems, and Spend Management features that vendors have shipped over the last year (e.g., Vercel's pause-by-default spend management, June 2024):

  • Surprise is a documented failure mode of usage-based pricing, not an edge case.
  • Lock-in is most expensive at exit time, when teams have the least leverage.
  • "Where my code runs" keeps coming up in EU procurement and compliance conversations as a first-class requirement, not a footnote.

Two small open-source tools is a small response to a bigger pattern. They don't fix anything on their own — they just make a few of those numbers visible earlier.

What this means for Wooven

I'm not trying to build "another deployment platform." That phrase doesn't even describe the gap I keep hitting.

The version of Wooven I'm building toward, and what design partners are testing now:

  • Bring-your-own-server compute — you own the underlying infrastructure, by default.
  • Cost transparency — the calculator's output, but live and continuous, not a one-shot estimate.
  • Portability as a property of the platform — not a slide in a sales deck.
  • Developer experience that doesn't punish you for choosing transparency.

The last point is the one I won't compromise on. Sovereignty and predictability are uninteresting if shipping a feature feels like punishment.

The name

Wooven = "woven together." Your code, your servers, your control plane — three threads that today live in three different vendor relationships.

That's the bet. The two tools were the first useful artifacts that fell out of taking the bet seriously.

Try them, push back, or both

If the code was useful, that's the goal — it's free regardless of whether the bigger thing is for you. Issues and pull requests on the repo are open and I read every one. A hosted UI for both tools is on the way; I'll link it from this post once it's live.

A note on what this post is not

This is a founder reflection, not a research post. The verifiable claims above link to primary sources. The product claims describe what I'm building toward, not features that are all shipped today — that distinction matters and I'd rather be explicit about it than blur it.