Notes:

• doc was meant to be as a guide for us to use, not to show potential customers or investors
• declarative doesn’t mean specifically code annotations. It means that the developer declares what he wants without needing to necessarily know how it gets in that state.
• the goal is not to enable startups to do more with less people, not to completely remove SDLC personas for the loop
• localstack enables emulating AWS services locally.
• blocks abstraction is more easily understood by palying with the Mock
• There a some sub-pages in the doc that explain better some details
• Always use avaiable tool in the market by default, only build new tools or make PRs to existing tools if there is a very compelling reason.

General:

• explaining via comparisons [1] vs not [2] (2 is the Winner)
  • Bruno: 1 — Much easier for reader to understand value, reader always asks the question “Why not just use tool X instead?”. Majority of devtools websites have a comparison page. making comparisons doesn’t limit us, a lot of big companies started as comparisons.

Freelunch Vision:

• Being an IDE vs not (1 is the Winner)
  • Bruno: 1 — I think this should be the long-term goal because it gives a code-first experience for the lifecycle and avoid conext swithing from IDE to platform, I think this is the future. The best analogy here are Game Engines like Unreal or Unity, they dont decouple the IDE from the platform, it’s one unified thing.
• Blocks abstraction vs not (1 is the Winner)
  • Bruno: 1 — Abstracting things as visual resuable blocks is a comon theme among software platforms that are very user friendly (e.g., n8n, matlab simulink). And this is tied to the IDE vision were you write code inside the blocks, all you see it all on your screen declaratively, what you see is what you get deployed.

Freelunch MVP:

• App-level observability with Open Telemetry + Signoz + Grafana vs just Open Telemetry and the Comapny brings their Observability Solution (2 is the Winner)
  • Bruno: 1 — I think OTel + Signoz + Grafana is essential, but of course configured to store recent data to not be too costly. If you look at similar projects (e.g. Kubefirst or Kubero) you will see that app-level observability is one of the pillars.
• Use of AWS PaaS/SaaS as default choice (e.g., Cost Explorer, AWS API Gateway, AWS Secrets Manager, Lambda, SQS, Dynamo, Database Migration Service) vs use of AWS as just IaaS + Open Source Tools (e.g., OpenCost, K8s Ingress with Traefik, Infisical, Argo Workflows, Kafka, Redis, Airbyte) as default choice (1 is the Winner)
  • Bruno: 2 — I think we should use open source tools instead of AWS PaaS/SaaS to lower cost and to enable easier validation & evolution of the MVP (the vision isnt to be tied to any cloud). PS: the similar tools we will use as baselines/forks do exactly this (Kubefirst, Kubero)
• Deploy via docker-compose vs dockerfile vs buildpacks (2+3 is the Winner)
  • Bruno: 1 — Because its simpler than making buildpacks work, especially for integration testing support; and docker-compose is already super popular in startups.
• Explaining it as a customized Backstage vs not (2 is the Winner)
  • Bruno: 2 — Explaining it as a customized Backstage is not a good epxlanation because backstage is only a frontend that gives unified control and visibility, it is not doing the heavy lifting. Comparisons with Kubefirst, Kubero and Kubevela are way better, because the projects are actually similar. The Backstage comparison is usufull when saying that the platform will have a GUI.
• Making money via Dedicated support vs not (2 is the Winner)
  • Bruno: no opnion yet, havent though much about this
• SSO integration vs not (2 is the Winner)
  • Bruno: 2 — Early-stage startups usually dont have SSO.