Summary:

Quick KB or Quick Knowledge Base, is a simple knowledge base builder. Almost every SaaS application needs a knowledge base, which can either work as a help guide or support guide among other use cases.

Why are we building it?

1. There are a lot of KB solutions out in the market; some are open-source while some exist as SaaS offerings. Most of them try to do too many things. We want a simple solution with only those features that we need, the bare minimum, and we do not want to make things complicated.
2. Our end users are going to be those users who are solo developers and those who are looking to host a small KB solution on their servers without the need to pay recurring monthly payments to host their KB.
3. Eating your own dog food: We have many products under QuickLabs, and we need to build help guides for almost each one of the projects. We want to build a solution for ourselves first. We are also using Notion to host our product documentation, which is very expensive; we would like to use QuicK KB to replace Notion as well.
4. We want to host it on a simple $5 instance, and the setup should be easy for developers to do.

Philosophy:

1. We just want to make a bare-minimum solution with no fancy features that are not used most of the time.
2. We have an anti-feature list that guides product development rather than a feature list. This is mentioned below in this documentation.
3. We want to build a solution quickly, within 1-2 months, but it should be able to serve us for a decade to come without needing much maintenance.
4. We believe that the development of a software product should have a definitive end point; once this point is reached and development is complete, it should provide us with long-term benefits. Therefore, we would like to make a product that has just the right feature we need and consider this product finished, never to be touched again (except maintenance) for development.

Technical Constraints:

1. We are not going to build a complex system with a lot of third-party integration.
   1. We will use SQLite for the database so that we have no need to set up a database service for the product to function.
   2. There will be no integration with any email service.
   3. Images will be stored on the disc itself, removing the need to integrate with S3 buckets.
2. We would rely on Laravel's built-in features, avoiding the need to install numerous external packages, which would reduce the maintenance requirements.
3. We do not want to use any UI library if possible, but I can make an exception for TailwindCSS or other simple CSS frameworks like https://simplecss.org/ or zero-css https://csszero.lazaronixon.com/lookbook/pages/overview
4. Every technical decision has to be made from this lens: once the product is developed, it should be able to serve us for the next 10 years. We just want to upgrade dependencies from time to time but not more than that.
5. The product has to be Dockerized and should be deployable with one click.
6. The product has to be independent of the vendor where we want to host; it should be deployable to Render/AWS or anywhere we want.
7. We will be using Laravel as a full-stack framework.