You will always have to build the piece of software that's specific to your needs. A framework can only make it simpler. Today, we are writing code; tomorrow, you'll need to prompt/draw/imagine in your head (hopefully) to get something built.
> auth - why do I want to use your auth over the many tried and tested auth solutions for Next.js? Where are you hosting the user data? Or are we hosting the auth data ourselves?
To set up auth, you'll need to set up keys, webhooks, and SSO for the providers. Just to mention, the auth is not part of the boilerplate; the auth is applied when your repo is deployed, as we embed your repo on our platform.
We are also using Supabase internally, so that's where the user data is hosted. You can of course build your solution with one of the many solutions out there. But we wanted to keep it simple keeping in mind all the use cases of a regular internal tool. For example, it may change to something else as we offer SAML, etc.
> Components - there is a hundred dashboard component UI libraries. Some of them are very extensive and good. Why do I have to pay for this?
You are right, there are many options, and most of the time, going ahead with any of the maintained ones works out with no issues. We want to be one of those many. Right now, we are using shadcn/ui, but later, we will develop/extend components that are frequently used in internal tools with a reduced number of properties. Our UI library will be open-sourced; it's not something you will have to pay for, and you can use it with any of your projects, as it's an npm package.
> Group permissions - this seems fairly straight forward to implement. Some auth solutions also have this built in.
Yes, it's straightforward, but time-consuming to build. I have yet to see a built-in solution where you can configure things like which team/group should have access to which tools. Most built-in solutions stop at assigning groups/roles, and it's because tools (or some generic entity) may not be relevant to their users (unless it's a solution for internal tools).
> In terms of AI offering, it’s not much different than asking ChatGPT and I already pay them $20/month.
We want to be on top of the game in terms of the AI when it comes to any knowledge that Creo should have, like its components, how to glue them together, error handling, and being fast with feedback loops (not taking a huge prompt and minutes to build the entire app like many other solutions). ChatGPT could be really good, but it will be spitting out unopinionated code, and to get it to produce code in a certain way, you'll need to prompt it heavily. Think of mentioning "Use shadcn's card in light theme" every time you want a card component. The value here is in the context being provided by default.