Using N to build and sell a SAS is a massive opportunity for a oneperson business. But there's one giant roadblock that stops almost everyone. That notoriously confusing sustainable use license policy. I see posts every week in my community from builders asking what is and what is not allowed under that sustainable use. And now Jan, the founder of N has finally set the record straight. In a recent forum answer, he clarified these specific rules that have tripped people up for so

long. So, in the next five minutes, we're going to clear up all the confusion. I'll break down exactly what you can sell as a SAS product whilst paying almost nothing for N in the back end and one specific setup that will require a commercial license. So, let's get straight into it. So, can you run n as a back end to your SAS using only your own company credentials on the back end? I.e., you're not passing in user credentials. So you have a user sign in on your front end that you built using

something like Lovable and then we use API requests and web hooks inside N as the back end that receives data, processes it and passes data back. But the key here is we only use our own credentials on the back end and does it have different licensing implications if they're signing in using Google Oorth or Apple on the front end? Can multiple users sign in? The simple answer is actually it doesn't matter how those users sign in. that doesn't make a difference as long as we're using only

your company credentials on the back end. This is permitted under the internal business use cases or sustainable use license for N. So to bring this to life, I've got some clear examples of where you might use this in a SAS product. First, we've got the social media scheduler. So if a user is on your front end and they're requesting a tweet to be generated, n is using an AI agent or LLM chain in the back end using your open router or open AI key and it returns the text back to your app

for that user to copy. That's absolutely allowed. If we have an AI blog writer where a user requests a post on a certain topic, we do a bunch of things in the background to generate that blog post, keyword research, etc. using only our third party API keys and we return that fully written blog post. to the user for them to copy and paste into the app. That is also allowed. And then finally, we have an email assistant where a user posts in an email that they want rewriting and then rewrite writes

it using your open router key and returns that draft in the front end for your user to then take and copy and paste and send that as an email that is also permitted. So how does that work then when you're actually connecting to a user's credentials in nan on the back end and is that permitted? So we still have the same front-end SAS here. We're sending our a API requests back and forth to n. But actually inside n for for this example, we want n to connect to multiple users Google mails. So we're

sending in their Google mail credentials or their tokens so we can connect to their Google mails on the back end and actually manage their Google mails and reply inside their inboxes or or create drafts. And a crucial difference here is like we're actually sending the users third party services accounts into nan. here for example managing user A's Gmail, user B's Gmail, user C's Gmail in there. Now, this use case requires an embed license because we're connecting

to multiple users accounts. And it doesn't matter whether you're doing that via the in-built nodes like Gmail, etc., or you're actually doing that by sending in OOTH tokens from your own external database and passing them into NAN at runtime. It's treated exactly the same. It matters what you use NAN for, not where those tokens are stored. So if instead you're using HTTP requests, passing in OOTH tokens, and not using the inbuilt NAN nodes, it doesn't matter. It's still connecting to a

user's third party service using NAN, which is not allowed and needs an embed license. However, there is a way around this. You can actually still use N as part of your SAS app. If you connect to a user's credentials outside of N. So if we're just taking that step of connecting to the user's Gmail and putting that outside of N somewhere, we can still process the data inside N, that is allowed. So if my SAS connects to the user's Gmail elsewhere, but N process the data internally, is this

permitted? Yes, it's okay. If your SAS does it somewhere else and N is not making that connection to that third party service, it is permitted as internal use. So we might have specific code that connects to a third party service and then we push that data into N that is still allowed. So let's compare those two directly. For the social media scheduler, if the workflow is connecting to the user's Twitter account and posting tweets on their behalf, not allowed. you need an embed

license. However, if the workflow generates the tweet text but sends it to an external service that manages that connection like post is or you're doing that through your own code which sits externally to n then this is actually allowed or for the AI blog writer the workflow connects to users WordPress sites directly via N you need an embed license but but actually if we're just returning the blog to the user and then you and then enabling them to connect to

their WordPress site outside of N then this is allowed. Or for the email assistant, the workflow connects to users Gmail accounts. You already know that we're not allowed to do that. But what about if your custom front end fetches the email and sends the text to n generates the reply and returns the text to your app, which then connects back to your draft email inbox. This is allowed. So the crucial distinction is it matters what you use NM for. If you're using N to connect to users

accounts, you need the embed license. However, if you take that functionality and put that externally or use a third party service, then you are allowed under the sustainable use license. Now, of course, there are exceptions to every rule and Jan has specified a few exceptions here. Do we have to have an embed license to just write something like a quick MVP? And Jan has said it's totally okay for testing. You can for sure create an MVP and test it using an

end. They don't want to block that. But as soon as it's available for public launch or external users, then you'll need that embed license. However, he has explicitly stated that we should however probably consider adding something in the future to allow smaller deployments to do that no matter what. So, it's still open in the future as to what actually and decide around creating smaller deployed apps without having that embed license. But right now, if it's externally accessible, then it

needs an embed license. And that's if it's externally accessible and connecting to users accounts to be clear. So the other exception was all to do with is the enterprise license enough or do I need an actual embed license because a lot of commercial users actually use the enterprise license for N. And Jan has actually explicitly stated that they're working on an update so that the enterprise license will be sufficient to connect to multiple users accounts in the back end of N. But this

will still only apply as long as you're not giving the user NAN itself i.e. white labeling NAN and the N UI is not exposed to the user. So you will be able to do all of the things that we said you'd need an embed license for with the enterprise license in Q1 2026 just waiting on updates now from the N team. So I'm just going to leave these key use cases on the screen now for the social media scheduler the AI blog writer and email assistant so you can run through

and understand exactly the nuances of difference that we've just run through for the license policy. So now that you understand that you actually can use nan as a SAS backend, in this next video I'm going to show you exactly how we build one from scratch.