On this page
A trial asks you to evaluate a product on the company's clock. That is awkward when you are building something in the evenings, returning to an old project, or trying to see whether a new tool will fit the way you work.
I want a small Bisonflow workspace to remain useful without a countdown. I also need the paid product to support the cost of running it. Pretending those two goals never conflict would make for pleasant copy and poor pricing decisions.
This is the reasoning behind a proposed new offer. It is not implemented. Current plans, checkout, and subscriptions still apply, and this article does not change what anyone pays.
Free should let a real project begin
The proposal includes a permanent Free plan for one person, with two projects and a small creation allowance. The working limit is 200 issue creations over the workspace's lifetime. That is deliberately different from 200 open issues.
A limit that refills whenever you delete work encourages people to destroy the history the product is supposed to preserve. I would rather be explicit about the allowance than teach that behavior.
Reaching a quota should stop the next action that exceeds it. It should not hide existing work or turn an export into a ransom note. The details still need implementation and testing, including retries, imports, and how retained projects count.
There will also need to be clear limits for storage and AI usage. Those resources cost money to provide. I won't advertise unlimited usage while the actual policy is undecided.
Sharing should not require the most expensive standard plan
The current Individual and Team distinction is too blunt for the direction of the product. A small group can need a shared workspace without needing configurable roles or team structures.
The proposed Basic plan would include the core project workflow and shared membership for small groups. Business would add budgets, team groups, and configurable permissions. Enterprise would remain a conversation about agreed requirements and services.
That separation needs to be visible in the product. A person inviting a collaborator should understand the relevant limit before they send the invitation. An account owner should still be able to manage security, remove a member, and transfer ownership without buying a higher tier for basic administration.
The plan names are useful only if those boundaries make sense in ordinary use.
I am not publishing a price table before the rules are ready
There are working prices in the proposal, but a price without a precise billing unit is incomplete. Which members count? How do pending invitations work? What happens during a downgrade? How does a current subscriber move to the new offer?
Those questions affect an invoice. They need answers before a polished card suggests the offer is settled.
The direction is per-member billing for the paid self-service plans, with monthly and annual choices. The final rates, allowances, eligibility, and transition terms will be published alongside the implemented offer. Enterprise would use an agreed annual contract.
Until then, the current pricing page describes what is available. It should not silently change because a blog post introduces a future plan name.
Existing subscriptions deserve a separate transition
Renaming Individual to Basic in a planning document is not permission to change a customer's charge. The same applies to Team and Business.
The implementation needs to preserve existing subscription mappings, rehearse upgrades and downgrades, and make any proposed customer transition explicit. Work that exceeds a lower plan's limits must remain accessible. A downgrade must not delete projects, documents, or people to make a quota look tidy.
Before a billing change reaches customers, I need to verify the actual invoice behavior and communicate the effective terms. That is a release of its own, even if it follows the 2.0 redesign.
What I want the offer to encourage
The free workspace should give a solo builder enough room to find out whether Bisonflow helps. Basic should make collaboration a reasonable next step. Business should earn its place when the organization needs the additional controls and budget tracking.
I would rather lose an upgrade than create one by making someone's existing project difficult to retrieve. The product is supposed to help you keep work, so the business model should behave consistently with that purpose.
There is still work between this proposal and a plan you can subscribe to. I am sharing the direction now because the reasons are worth discussing before the checkout changes, while there is still time to get them right.
