@Joyal Kenus my original company (near shore Oracle services based in Croatia but selling to the UK) initially did a lot of project work. The 'issue' with project work is it is feast or famine as you are always juggling a bench of resources ... you need the next project to land exactly as you have available resource. From a business perspective we did well but you can have periods where 1 project is finishing and you are unsure what the project team are working on next. The flip side is you have too much work and need to resource (easier problem to fix as we could get termporary resource). Over time we started to get long term support contracts. They were great for two reasons - easy to budget (2 - 3 year deals) but also over time they become more profitable (you get less and less support work if you do a good job). When you get support work it is likely there will be small change work that is outside of support ... I would say an addition 20% on top of support. So, instead of having to get commerical cover for each change we would sell a pot of credits that could be called off (so it was called a call off pot) to use for that change. The benefit is that you did the commercials once each year and then the day-to-day was just about delivering and tracking 'credits'. So, we may do a contract that said we will give you support for £120K per year + you can buy 120 credits for £12,000 (so that is 120 hours). If the customer needed a bug fix then it was part of support ... if the customer needed change we would agree it take 5 hours and then just deduct it from the call off pot. When talking about 5 hours we did not say £500 ... we said 5 hours / units / credits. So, money was not front of mind ... that was just an annual converation. NB: above numbers made up so I got round figures. So, would this model work for a AI Agency. -- 'Large Projects' - quote a price, payment terms, etc. If it is a lengthy project then ensure there are milestone payments e.g. 20% to get started, 30% for POC, 20% once UAT completed, 15% on deployment and 15% post go live warranty payment (we normally provided a 30 - 90 day warranty period where you would fix any bugs ... as opposed to scope change .... post go live).

@Joyal Kenus I have yet to start the business as I have focused on my own companies to start. My first customer is an Italian Group of companies and I am going over there in a few weeks time to do the first project (I could do it remotely but it is a good excuse to spend some time in Italy). I have both cloud (it was quick to get started) and local (both on PC and on a VM in Azure … as we have a lot of Azure infrastructure). Over time we are likely to go fully self hosted internally as we will also move to local LLM as opposed to API calls to AI companies). What will I do with customers? Really up to them. If they don’t want to be tied to me I would suggest cloud or their own hosting. If they don’t have IT skills that would mean cloud. If they are happy to be tied to me then we will provide the infrastructure for their self hosting. If they later want to move we can always give them an image for their VM.

@Joseph Pham I think the idea of the platform is a clever way to monetise AI / Agents. But I agree that you need to consider the IP implications. In saying that if you intend to give away the agent / open source it when you post it to a public repository then I think you are no worse off.

@Joseph Pham I did not say that open sourcing gives unrestricted commercial rights. I was indiciating that if you read the T&Cs of the competion then it is not that dissimilar to some of the open source licences. Competion: "non-exclusive, royalty-free, worldwide, irrevocable, sublicensable license ..." MIT Licence: " ... including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software ..." In practical terms these are broadly the same with the main difference is the MIT licence says you need to give attribution to the code.

@Luca Sacchi Ricciardi the logic you are trying is incorrect. At the moment you are saying does this 1 title (left hand side) not equal this collection of multiple titles (right hand side). So, to try to make it work N8N takes the h th rat item in the collection. Two fixes #1 - add a loop that goes through the multiple titles and in that loop check if the 1 item = new title. If it does set a variable to false. At the end of the loop you can have a output that you can now read as true or false. #2 Use a function node as write a little bit of code to compare the new title to the collection and output true or false. If you don’t know how to write it the ask Claude AI to write it. I would go with #2 as it is tidier (one node). Let me know if you are still unsure how to implement that.

Hello @Simon Coton Thanks for sharing the video. I know security is important but I don’t fully agree with this video. In the video you talk about it being intercepted … yet it is an HTTPS call so it uses SSL. That is, the traffic from the server to the API end point is encrypted. If that was an HTTP call I would agree that it could be intercepted. If you think about how a web app works - you give your username and password, it is passed as clear text using an HTTPS auth call and then you normally get some type of Auth token back. If that is a JWT token you can decode it but not alter it. It is passed in the header in each API call … but not considered unsecured as you use HTTPS / SSL. If someone hacked your browser and stole it from your local cache they could use it … but that is an entirely different problem. As an aside lots of dodgy chrome extensions store the token on their servers … so that is a security issue (e.g. lots of social automation tools have kept token that may be valid for days or weeks). I think the true risk is in sharing the workflow. If you use N8N credentials the they are not exported and are not contained in the JSON file. In contrast, if you embed them as parameters then they are likely to be exported. So, you could inadvertently give away your API key as it is a hard coded clear text parameter that would be in the JSON file. So, I agree with the advice of using the credentials section to store credentials as opposed to parameters but I disagree with the risk you are highlighting.

Any modern SaaS CRM will have an API and most will have a free tier. I am using Hubspot - there are some basic N8N nodes … and anything beyond that I just use an HTTP request node. The API response is a bit verbose as it uses an entity API pattern but once you understand it you can use lists of functionality - customer, contact, deals, tasks, quotes, invoice, notes, etc.