Notes On Work - by Caleb Porzio - Flux pricing brainstorm session #1

Flux pricing brainstorm session #1

Aug 31, 2024 - 30m 47s

Sit down with me and let's figure out a pricing strategy that makes everyone happy

Discover more and add this to your library.

Sit down with me and let's figure out a pricing strategy that makes everyone happy

AI-Generated

Pricing Strategy Development

The host discusses the complexities of creating a pricing strategy for their product, weighing the potential benefits of both public and private packages. They grapple with the implications of each approach, considering factors like user access, ease of licensing, and the impact on honest users. Public packages would allow for easier access for users to try out the product before committing, while private packages might ensure more secure revenue but could complicate user experience.

Licensing Models and Concerns

The conversation delves into various licensing models, particularly the option to charge only when a project goes to production. While this could attract more users initially, the host worries it may lead to individuals forgetting to pay later on. They brainstorm ideas like incorporating watermarks for unpaid projects, but consider the ethical implications and potential backlash from users.

Streaming Documentation and Access

The host contemplates how to structure documentation access and whether to implement a paywall for certain parts. They consider allowing users to view a portion of the documentation for free to entice interest, while still monetizing the full resource. The overall goal is to balance accessibility with revenue generation.

Annual vs. One-time Pricing

The discussion includes a strong opposition to one-time pricing models, suggesting that annual subscriptions would provide a more stable revenue stream and promote ongoing user investment in the product. The host believes recurring payments are key to sustaining the business long-term.

Challenges of Redistribution and Community Ethics

Redistribution of code remains a significant concern; the host emphasizes the need to cultivate a community of ethical users who respect licensing agreements. They discuss the nuances of defining redistribution and communicate a desire for fairness in the developer ecosystem.

- Finding a pricing strategy involves deep consideration of the implications for both the business and the users.
- Choosing between public and private packages is crucial in shaping user engagement and revenue security.
- Licensing strategies must account for potential non-compliance among users, requiring a balance of encouragement and enforcement.
- A subscription-based model is favored for continual support and revenue, as opposed to one-time fees.
- Fostering an ethical developer community is essential to maintaining trust and sustainability in the software industry.

Transcription

Enough wishy-washy feelings now.

Let's talk strategy.

What are we gonna price this freaking thing?

Okay, the biggest decision I think I have to make is right now I have it's my picture of being a private package of situations.

I'm using any stack that Filo made.

It's really awesome if you wanna charge for a composer packages or I think it supports like a ton of different languages and frameworks and stuff.

But that's what I was going to use.

I have the integration all set up and just make the repo private or whatever and it's like if you pay, you type like Artisan Flux colon activate or Artisan Flux colon install or something and you put in a license key and then it does all the rest.

It reaches out to my server, it validates the license key, it adds an auth.json to your project and then you're good.

And that's how Nova works, not any stack with the same idea.

like a private package repository that your license, you know, like, and if you need updates, it like goes and it authenticates and it makes sure that you can receive updates.

So that is a bulletproof scenario.

It's not bulletproof in the sense that it's hard to police license sharing.

But if somebody is on an island, they don't have any friends with a license and they and they want to use the thing, they have to pay you to use the thing.

Right?

And there's a pro con here.

The pro is you get that actual checkout mechanism where people are compelled to pay you money.

They have to pay you money to use the thing.

Otherwise, they're like actually doing something.

They're actually doing actively bootlegging it, which I think weeds out most honest paying people.

And then the people who aren't, it's like they're to get it anyway somehow.

But the problem with that is that it's a lot of extra plumbing and it makes it less flexible if I want to change things down the road.

It's harder to do things like offer eight components for free or whatever.

It just feels like it also adds friction to the experience because it just makes it feel like you're not just going to be playing around with it everywhere and using it and everything because it's, you know, so, um, Statomic just has their project on an open source repository.

So it's just, um, you know, get up.com slash Statomic slash CMS, I think.

And then the whole project is on there.

And there is no license validation for like private packages or anything.

It's a public open source project.

But if you look at the license, it's not MIT or anything.

it's a proprietary license.

It's like you have to pay and hold a license to use this open source tool.

So you type, compose, or require a live or slash or whatever, a static slash CMS, then you get it in your project.

You get static in your project and you can just use it until you want to put it to production and or whatever.

As you use it, the admin panel, when you're in the admin panel of the CMS, not the front end of your app when you're in the admin panel there's a splash at the top that says this is an unpaid thing you need to pay for a license so it's bugging you you know and that's the whole thing and that's good enough for people to go oh I need to get rid of that banner and you know this is a client project I can't embarrassingly have a watermark or whatever and I'm going to pay for the license for the project and now it's in production we're good and that works for Statomic.

The thing I love about that is that it's an open-source project that's on GitHub, people can contribute fixes, and you can just compose or require it.

It's super low-barry to entry to just try it out and tinker with it.

And I love that.

And it just seems so flexible.

But you know, my concerns obviously are many.

The biggest one is that I don't have an admin panel to remind people they need to buy it, you know, because flux is just like an app UI kit.

There's no admin panel that people are regularly visiting.

So if I were to have something prompting them and telling them that this is an unpaid thing, it would be on your app itself, which feels invasive.

Maybe that's okay.

I don't need to be afraid.

That feeling comes out of fear for me is that you can't do something like that.

It's too invasive, or it's dirty or something.

But why do I think that?

What's wrong with that?

If it's something you need to pay for it and you didn't pay for it, and there's a watermark on your app, that's on you.

It's not on me, right?

Like, you can't be mad about that because it's your supposed to pay for it.

So, that's one of the only things I can think.

It's like, I could do other things.

like you can just compose and require it.

But yeah, I guess there's there's so many decisions to make.

So let me just kind of get some clarity here.

There's private-verse public packages.

Okay, that's one thing.

Private-verse public packages, which yeah, is basically like, is this thing gonna be on any stack or status or status or something, whatever that other project is called, or is it going to be public on composer and then I'm going to authenticate a different way.

And then let's say if it's public, then what are you policing?

You know, the next question is, is the license production only?

So license or statumics whole business model is like, you pay us when you get to production.

Because otherwise you don't need to, you can just play with it, you know.

You could, if you want, pay us beforehand and get rid of that banner, but you don't really need to until you're actually doing this thing for real and it's in the wild, you know?

So it's like, do I want to mess with a license like that?

Ideally, it's just you pay me and then you get access to it.

That way, it's like, I know that you paid me.

It's not what it is, is I think Jack was telling me this.

It's not just you're trying to keep honest people honest.

It's you're trying to make it easy for honest people to be honest.

So if I consider myself an honest person, and an honest person who makes a wage on these things, I have no problem paying for something.

But if you're gonna give it to me for free, like sublime, I used to sublime forever and never paid for it, and it bugged me like once a month they would throw up that pop-up and I would just go ahead later.

Because it's friction, it's like I have to go and dig out a card and find out where to pay and then activate this license and then I'm gonna switch laptops, it's not gonna be activated, I'm gonna have to dig out an email and blah, blah, blah.

It's like this isn't that inconvenient and it's not telling me I'm doing something illegal.

So I'm just gonna keep doing what I'm doing.

I don't want that scenario because I think that scenario results in, I think that's not good for business, you know?

I don't want that.

So my fear with the only charging people when it goes to production is that I don't make a lot of money because when people end up going to production, they go, eh, eh, whatever, you know, I'm not gonna go hunt him down to pay for it.

They forget to pay for it, whatever.

So it's like, if I'm going to do that, I mean, a watermark is something that is very, to me, it might be a good solution, honestly.

If I inject the watermark into the page, if you didn't validate your project, and then there's the whole other thing, it's like, well, how do you validate the project, you know?

What are you doing?

If it's an open source, composer install, live where slash flux.

So let's run this scenario.

Composer require live where slash flux.

You get it.

You can just use it.

No sweat.

But there's a watermark.

So now you want to get rid of that watermark, type composer, artisan, flux, activate.

It says put in a license key.

You go to the website, you get a license key.

Now what do we do with that license key?

I when you hit enter it could send a message to the server whatever I could log that I could you know I can't store your app here something like what am I putting in your project to make it greenlit?

So let's just say I put a dot mid says stand put an activated dot TXT file in your project root, okay?

Now that watermark is just gonna disappear forever.

I never in environment.

It's gone But you might just go, oh, so this activated.txt file is just an activated.txt file.

I'm starting a new project, I'll just copy and paste that file.

And then, okay, this project works, and then word spreads that, hey, if you want to get rid of the flux watermark, you just put in an activated.txt file.

Okay, so let's say that I go deeper and I like hash some stuff and your license key and store it in that file and whatever.

Okay, well, it's kind of the same.

It's like, hey, here's my activated.txt file if you want my copy.

But if you think about it, you can do that with no value.

You could probably do it with Statomic.

There's ways.

It's like if it's just an auth.json that works for multiple environments, how does the system know that it's that you sharing with your friend is not just a different environment of the same app.

You know, there's no unique fingerprint for an application.

Not even an app key.

Your app key is different locally than in Disney production.

You know, the fingerprint of your app is a hash of all the files contents in your project.

And probably not even so, because that changes between environments.

You know, it would be nice if there was an app ID, but you could just set your app ID to your friends app ID and then like authorize that way.

But I could do something like that.

I could in a config file, like flux.config or config slash flux.php.

I could set a project ID as an item, line item, and then that's version controlled, you know, so it'll work across environments.

But that's okay.

So it's getting away from here.

The first decision making is like, is it public or private packages?

Everything in me wants me to do public, but private is so straightforward.

It keeps honest.

It keeps it easy for honest people to be honest.

It's good for business.

It's predictable, but there are infrastructure concerns.

you have to have the infrastructure to host that package for a composer forever and that seems like a lot to be on the hook for and it adds friction to users and I don't love that and it feels like it locks me in a little bit to change my mind in the future if I want to make some things public or some things private.

You know, I don't know.

Okay, so there's private first public packages decision that I'm not sure on.

But let's just say for now to make progress, we're going to say public.

Let's just entertain that.

Public is the way.

Then is the license or maybe the next, what is the next question?

Is it per?

Really is it per project versus per developer?

That's what it is.

Yes, this is why it's tough because there's different users.

There's a solo developer who goes, I would love to pay you $250 a year, a freelancer, because let me pay you $250 a year and just get access to this thing.

I can activate any licenses I want.

I can activate as many projects as I want and share it with the world and share it with my clients and we're all good.

They never have to worry about keeping a project activated or anything.

You know, you know, that's great to just have, you know, one price.

If it's $250 a year, I'm good with that, you know, instead of like, well, maybe you would have made 500 a year if they did five client projects in a year.

It's like, no, I think $250 is good.

It's reasonable.

And the freelancer is making good profits.

I'm making good profits.

We're good.

And it's not one time.

So people are pushing me to do one time like 10 when do I?

I don't think one time pricing is a good idea for me because it is like you could pay me one time and I never get any more money from you.

So it just I've experienced the woes of it.

It's you have to keep if people are giving you money annually and you have like a sustainable healthy business that just like people are happy with the project and they keep paying for it and then you have that income over time, it's just like so much better to me.

I've experienced how one time can drop off when you're not, you know, when you're not a rising star, you know.

So if this project is a rising star, one time is great, you know, if people are flooding into the community and the ecosystem, but it requires that, that people are flooding into the ecosystem community.

And I don't think we can always guarantee that, you know, it is that way right now.

But when PHP is saturated or when the Laravel or live wire, whatever, that market is more saturated, I know that they're always, this is probably a myth.

But I want to be aware of it.

And I do actually think that the golden age will not last forever because the reality is they're not teaching you Laravel at boot camps.

I was getting into Laravel when I was, you know, when I got started because that was what you did.

it.

It is not what you do anymore.

Nobody's telling you from the outside to start using Laravel.

If you want to get into web development, unless it's a Laravel head, it's like get into a .net bootcamp, get into a Java bootcamp, learn, react, and next, that's what that's where people, that's where the newbies are going, you know, and I don't want that to catch up.

And because I had chosen lifetime pricing, now my business is deflating.

And then people who, you know, like I want it to be annual so that the people using it support the business on an ongoing basis, you know, whatever.

I don't have to justify it.

That's just, I'm going to make that decision right now.

I'm going to say no, okay, I'm going to make some hard decisions.

I want it to be public on composer and GitHub.

I don't want to do one time pricing.

the next one is is there a free tier hard to police but let's explore free tiers for a second free tier strategies okay there's hobby I'll say full access hobby tier is like you can use this thing in full when you're not making money on it.

If this is a commercial project, then you have to pay for it.

I don't love this because the line's blurry and it feels like the kind of thing where a lot of people are going to just start every project in the hobby state of mind like I would.

You just kind of, let's just see where this goes.

And then it slowly morphs into a live project that makes money and then I never get paid, you know, and I don't like that.

the other idea is a limited number of free components.

So there's like eight components that you just get for free always.

Forever.

Profit or not or commercial or not.

You just get them and you can use them.

And I like that.

But how do you split up what's free access and non-free access?

Then you're back to the hard parts with Composer is like, well, the paid stuff, what is it?

Is it a separate repository that's under a private package?

It's called like Flux Pro, live or slash Flux Pro, or something?

I don't love that.

I don't love splitting the repo.

I want to keep things simple, you know?

Is it, then we're kind of all back to that.

How do you authenticate this stuff?

I mean, what if it was just as simple as it's a yearly fee?

All right.

Wanna use flux?

Hmm.

Wanna use flux?

It's...

And I feel like it kind of has to be per developer, maybe.

Hmm.

Okay, here's an idea that I had from the beginning that I'd like to do, but it feels a little dangerous.

I'd love to pay wall the documentation, or at least all the code examples, because then it becomes per developer, and I can make it cheaper, and I think developers actually want it to be per developer instead of per project.

you know.

So let's entertain that for a second is, sorry, I'm just like, you know, writing notes here while you're hanging out with me.

I got to keep my list of core tenants separate here, which is I want to make the repo public.

I want it to be public packages and I don't want to do lifetime pricing, one time pricing.

So let's explore per developer pricing.

This is good for the solo developer freelancer.

Let's say, let's just say 99 a year for now.

Let's say 99 a year and you get access to the docs and you can generate unlimited license keys maybe or you get your own authentication code, and you get your own authentication code maybe.

Maybe that's how it works.

I don't know.

Maybe it's just paywall docs.

And then it's like, Hey, if you want access to this stuff, you pay 99 bucks a year, and you're in, you can use it on anything you want.

And you're totally good.

The rules are you can't share the code.

And this goes without saying for everything right now, you can't put, you can't redistribute the code.

And what do I find redistribution?

What do I define that as?

It's you can't put this code in an open source in another open source public project.

You can't put this code in a paid project where the thing is our thing.

You know, I guess redistribution is sort of self-hopefully itself defining.

It's like, you know what it is to redistribute, like telling you why.

You know, I can't use telling you why in my courses because I would be redistributing telling you why.

You know, you could just buy my course instead of buying tailwind UI, right?

That's redistribution.

You cannot redistribute blocks period.

The source code, even though I wanted to be public and on GitHub, I don't want you taking my JavaScript web components and putting it in your your own UI component library.

It's a hard thing to police.

It relies on ethics and I hope that the people in the community and if you're listening to this and you're a person in the community who wants to make or is making UI kits, please just stay away from that code and build your own code.

Please write your own JavaScript.

Normally, I'm not so protective of code like that.

Obviously, I put most of it, pretty much all code I've ever written out for free on GitHub.

But with this, I just am.

I just don't want to be scooped in that way by direct competition.

So thank you, respectfully.

I won't look at your projects and take your code and your APIs, please don't look at my projects and take my code and my APIs. So, those are the core tendents again to remind you is make the repo public, make composer public, not one time pricing, let's say annual pricing.

I just like annual pricing, so I'm just gonna say that right here.

And we're going with my gut here.

Things that I want, annual pricing is what I want.

Obviously, anti like non redistribution license of some sort like on the repo.

Okay.

Now per developer pricing, if it was $99 a year on limited projects, okay?

That's how you get an account to view the documentation and use the dang thing, you know?

And all right, so let's toy with that for a second.

What I current, my current thought before was, my thought before was I am going to make it so that you have to log in to view the code snippets and demos.

And you can then see those and view those for free.

And then you have to pay to get Flux, okay?

So now you're like in a little bit you can still like look at stuff and see if you'd like it and Then I know that you're interested um And I can email you and say like hey, you know, it looks like you're peeking at flux like what do you think you want to buy it, you know?

so That was my plan But if we make it so that it's per developer 99 dollars a year and paywall the code base or paywall of the docs or that those parts of the docs.

I have to pay while something, you know, and it's interesting.

I think the more I pay while the docs, the less I have to pay while the code, you know, like I can be less Gestapo on the code if I just put the, if I make it so that you literally can't like view all the examples and, and such, um, without, yeah.

So what is that like?

is 99 good for that?

Does it feel, and then if I'm paywalling the docs at 99 a year, it feels more similar to the live wire screencasts and then are people who like pay for that going to be weird.

Like, wait, why do I have two live wire annual fees going on here?

I got this flux annual fee and then I got the screencast annual fee.

We're oddly enough if it's just like, if they're priced differently enough, I feel like people don't think that.

It's like, Well, yeah, you know, I pay for this for the screencast and education, but then I pay for Flux per project as I need it, you know, where if they're both just kind of like paywalls to the sites, then it feels a little weird.

I could unify them.

I could go for like a live wire pro type vibe that's like just get people on the live wire pro situation and then you get access to Flux.

you could access to the screencasts, you just get in the world, you know?

And it's 99 bucks a year per developer.

Like I feel like that's a decent situation and it's much less ambiguous, you know?

But then it's like, then that like eats in a flood, like I want flux to make good initial launch profit.

But if I'm launching and saying, hey, all the people that I'm launching to, I know like you just get it for free because you already pay for the screencast, you know, and it's like I guess that's fine, but I don't know.

I don't adore it It's hard to deal with decisions you've made in the past, you know It'd be nice like if you just didn't if I didn't have to worry about that stuff But I'm always oversensitive about that.

I should really just like try to figure out what's best in the moment right now and then figure the rest of that stuff out So we're at like 25 minutes, I don't know, let's keep going, we'll get to like a half hour and maybe we'll all come away with some stuff.

So yeah, $99 a year seems super fair to me per developer if it's unlimited projects.

And of course, I can have like project parity pricing stuff, whatever.

Because flux is the kind of thing that can be really sticky, you know.

know, if I keep improving it over time and adding more components and adding more examples and things like that, this can be a project that you want to keep paying for because you don't want to lose access to those, that documentation, you know?

But I was excited to try a new model and see what it's like because I like trying new things and seeing how it works, but whatever.

Okay, so let's say per developer, unlimited, is it just paywalling the documentation or is there also, I think I would like to put some amount of protection.

Yeah, I want there to be an artisan, flux, activate that does some sort of setup in your project.

At least put something in your way so that you have to reach out to my server.

So I know how many projects a user has.

So I have some information about usage and then if somebody is sharing a login or something like that, then I can know to disable it or something like that.

I want to put something in the way.

Yeah.

So I want Artisan Flux to activate, and then it's like when they run that, again, now we're back to like, well what gets stored in the project, how are we authenticating?

Yeah, it'd be nice if it was just like a flux.key file, and then in there it's just like a hashed version of a license gear or something.

But again, I want to make it so you can't just share that file around so I could tie it to your app key, but then that's going to change your production and I don't want to break production, but I don't have to worry that much.

I don't have to worry that much because if you can't access the documentation, okay, you share it with your friends so they can get it for free, but they can't access the documentation.

So what's up with that?

You know?

But it would be nice to have all the documentation public because you want people to see what they're getting and to know what it's all about, you know?

A lot of it is also trust, you know?

But yeah, I want people to be able to scroll and see what they're getting and go, yeah, this is all good, you know?

But do they need to see the APIs to know?

I could show you the first code snippet on every page and then pay all the rest of the examples.

I think that's pretty fair.

So you can get a taste of the API.

I'll have some sort of intro video that's saying, here's what you're getting with Flux.

Like, check it out.

Yeah.

That seems pretty good.

Like, okay, Artisan Flux activate.

And this will put some kind of key in your code base that you get, like, maybe there's still an admin panel where you have to generate license keys per project, you know.

Maybe there's something like that.

Yeah.

All right, so I'm, I'm getting tired.

We're going to have to revisit this.

Thanks for signing up for this session here.

But there's, I think I come away with a few things.

I'll say alphabet one thing is paywall parts of documentation.

Okay, so make the repo public, make, so I'm just gonna, like, I know I keep, I'm gonna say, make, I'm just gonna say public on GitHub and Composer, okay.

It's annual pricing per developer.

It's, so none, I guess, all right.

So then it gets weird with companies companies are different, you know, I can just have a separate thing for companies It's like reach out to me for company pricing.

I should focus on the single developer for now because that's the largest market Because in a company you're gonna go wait So I have to like it's $9 a year for 20 employees, you know Because they all need to view the docs.

Well, they can just yeah, I don't know Then we'll have to have some sort of team thing all right public on GitHub and composer annual pricing per developer However, obviously you can't redistribute, I'll put that license on GitHub, and you run Artisan Flux Activate to activate a project, which adds a Flux.he file to the project that gets version controlled.

Yeah, and then the project's activated forever, forever and ever.

updates are unlimited.

Yep.

And then paywall parts of the documentation.

I feel like that's pretty good, you know?

I feel like that's pretty good, right?

It's pretty immune.

So of course people can just nab stuff from GitHub, but they're are always going to be able to do that.

Well, that's not true if I make it private, but I don't know, what am I going here for, you know?

What am I going for here, I should say?

How locked down do I want to be?

I want this to be a widely used thing.

I just don't want to be broke.

All right, to be continued, that's what we came up with for this one session.

So, I feel like that's pretty useful.

I'll see you later.

How I stop this thing.","created_at":"2024-09-10T23:08:29.000000Z","updated_at":"2025-07-15T06:13:18.000000Z","requested_by":[2],"status":"completed","delay_time":null,"worker_id":null,"job_id":null,"execution_time":null,"runpod_job_id":null,"error_message":null,"completed_at":null,"word_level_timestamps":null,"claimed_at":null,"embedding_claimed_at":"2025-07-15 06:13:18","embedding_worker_id":"macbook-air-worker-1"}

Login Required

Please log in to start a conversation about this episode.