Is it possible to bill per team created?

I had the same question.

Do I think it will be better to bite the bullet? If I'm to recite the propaganda, Spark will save you about 3 months worth of coding. if (3 months of coding > $99){ 'Oh, my goodness, yes' }

Also, why not have a team subscription option with a team max of 1?

    Spark::teamPlan('Lone Wolf', 'Lone1')
        ->price(39)
        ->maxTeamMembers(1)
        ->features([
            'Just one user',
           'can join other teams when invited',
    'can create additional teams or expand this team'
        ]);

I see your post was submitted 3 days ago, have you made any more progress or changed anything since then?

@SteamDiesel Thanks for the reply.

It took me a minute to click, but Spark does actually bill the way i want it to. If an agency signs up, they'll be billed per team they create (that goes on a paying plan).

For example, If i'm an agency, i might create a team and call it 'client1' and subscribe them to the pro plan. But what if i want to use the system myself, well i can create another team called 'agency1' and subscribe this plan to say the enterprise plan. In doing so, i'll be billed once for the pro plan for the client1 account, and once for the agency1 enterprise account (IE billed for each team created).

From a single end user's point of view, we're going to allow them to create teams (i mean, lets face it why not?). We're just going to use different terminology on the front end.

Regarding the code you've pasted above, that would be handy if we wanted to limit the teams members to 1 member per team. We're going to be doing this, but allowing single users to have 2 members (the owner and the client).

Out of curiosity though, do you know if it's possible to use both Spark::teamPlan and Spark::plan at the same time?

Kind regards, Nate C.

Forgive my laziness for not double checking this, but I thought I could only have either team or individual billing when I was tinkering with it. I decided to simplify my billing method to team billing only (which has shaded my bias, so take this advice with salt)

For my user base, there would be very few situations where a user wouldn't be a part of a team, and the data they generate would need to remain accessible only to members of those teams. Even if they were using the system as an individual, doing the same work, they'd still want to have additional user accounts (for customers and referrers), and making those people sign up on a billing plan would be difficult.

And then there is the matter of data access and sharing.

So if a staff member leaves one shop and goes to work in another shop. those 2 shops would have teams, and the user account remains in the system, but essentially dormant (and free) until it is invited to a new shop. If the user account is orphaned because the email account for the user is no longer monitored (employer provided email) then the account could be changed to a new email. but it wouldn't make a difference because data access is restricted via team checking middleware.

If the user leaves the shop and goes to work for themselves, they may want to add co-workers in future, so having the billing based on team size fit for my system needs (my pricing is aligned directly to the team size). And if an individual builds a business that outgrows them, they can just transfer the team (with users and data) to a new owner.