1
0 Comments

I changed my free tier because it was blocking the real value too early

I just changed the free tier for imdone-cli, and honestly, I think the old limit was wrong.

I’m building imdone because I’ve spent too many years watching developers lose time to scattered work context.

The code is in one place.

The ticket is in another.

Comments, attachments, screenshots, and decisions are spread across tabs, Slack, and memory.

That friction adds up.

Not just in minutes spent hunting for things, but in the cost of regaining context and getting back into flow.

imdone-cli is my attempt to fix that by pulling Jira or GitHub issues into a local markdown backlog in the repo, so story work lives closer to the code.

The problem was that the old free tier often stopped people before they could really evaluate whether that workflow helped.

They could try a little, but not enough to reach the value moment.

So I changed it.

Now people can try imdone-cli on real work without creating an account first, keep reading and local workflow free, and only use the allowance when they write changes back to Jira or GitHub.

I’m trying to make evaluation more honest.

If someone is going to decide this workflow isn’t for them, I want that decision to happen after they’ve actually experienced it, not because the free tier cut them off too early.

Still figuring this out.

If you’ve built a dev tool, I’d be curious how you think about this:

when does a free tier help evaluation, and when does it just create friction?

posted toAvatar for product imdone
imdone