Knowledge

The meeting was a short daily/intro call for a small team that is still in an early setup phase. Lukas was experimenting with multiple recording bots to test transcription performance. Isaac, the newest member, was introduced; he works on reverse engineering and front-end/back-end development and built much of the infrastructure for recording VODs. Other members introduced themselves: David (mobile developer using Flutter), Michael Mensah (product design/UX-UI, based in Ghana), with Marco and Sebastian already known to the group. Sebastian outlined the overall strategy: building the product bottom-up, beginning with clipping as the first layer since it is closest to current Tikfinity user needs and serves as a bridge to onboard users into the broader 'recorder' world. Subsequent layers include low-level Tikfinity integration, mobile and web apps, content moderation/live recording use cases, and finally an AI marketplace, for which Lukas is building an MVP proof of concept. Roles were defined: Marco leads clipping and the web app, Michael handles corporate identity and screen design (currently blocked partly due to an unfinished agency design), David handles mobile, and Sebastian coordinates releases with Tom from Tikfinity and Lukas, plus securing legal documents. The team noted an Asana board exists as loose orientation rather than strict top-down tasking. A technical discussion covered API endpoints referenced in a shared document. Isaac noted a mini consent layer is already built in; he and Marco partly disagreed on whether it should be collection-only, but agreed to keep it for now since the recorder API is not fully built. Discussion also covered storage management and content/compliance placement (favoring Isaac's layer). Isaac raised that storage will be the dominant future cost and suggested renting low-powered servers with attached storage running S3 to cut costs significantly at scale. Marco and Lukas discussed access patterns (hot vs. infrequent storage), and Sebastian described a triage-based retention model and possible monetization where viewers/data brokers help bear storage costs. The call concluded with agreement to coordinate further in smaller groups.

The team decided to build the product bottom-up, starting with clipping as the first layer because it is closest to current Tikfinity user needs, then adding low-level Tikfinity integration, mobile and web apps of the recorder, content moderation/live recorder use cases, and finally an AI marketplace.

It was decided to keep the existing mini consent/compliance management layer within the recorder/collection layer for now, rather than moving it to the backend API, since the AI labs use case benefits from having concern information available without bubbling down to the API. This may be revisited in the future.

Storage management was identified as a later requirement, not needed for the first iteration.

Marco, Isaac, and Lukas will hold a separate smaller call to coordinate which API endpoints are needed and which Marco needs for the clipping infrastructure.

Coordinate with Tom from Tikfinity and Lukas to create the first release structures and define a possible compact feature set with Marco and the team.

Ensure the correct documents are received from the lawyers; a draft exists but is not finalized.

Isaac to coordinate with Marco, Lukas, and eventually David on which APIs and architecture are needed.

Hold a smaller follow-up call between Isaac, Marco, and Lukas to finalize comments on the shared API endpoints document.

Isaac to have a short follow-up talk with Lukas about TikTok and connection topics; Lukas will message Isaac to arrange a later time.

Lukas to build a proof-of-concept for the AI marketplace MVP that can be tested.

Storage is expected to become the main cost driver, potentially reaching ~$30,000/month. Migrating storage later (e.g., to self-hosted S3-compatible servers) becomes increasingly difficult at scale, so cost structure should be considered early.

An agency was hired but design work is blocked because the corporate design has not been fully settled internally, delaying the product designer's work.

The business model and per-user storage requirements are not yet clear, creating uncertainty around storage strategy and monetization.

The team is in a preparatory phase with a loose structure and is somewhat stuck in setup, which could slow progress.

Whether content/compliance management and storage controlling layers should reside in the recorder layer or in the backend API layer.

How to handle hot vs infrequent access storage, retention periods, and whether to use providers like Cloudflare or self-hosted S3 servers.

Whether to adopt a model like Stream Recorder where viewers pay for recordings/storage; uncertain if feasible or desirable from day one.

Unclear how large storage will be per user.

Uncertainty about whether partner data brokers can store the full data volume given its potential petabyte scale.

The meeting was intended as a ~15-minute daily and intro/getting-to-know call, including an introduction of new team member Isaac.

Marco leads clipping and the web app; Michael Mensah is UX/UI/product designer; David is responsible for mobile (Flutter); Isaac works on reverse engineering, front-end and back-end, and built recording/VOD infrastructure; Lukas builds the AI marketplace MVP POC.

Lukas created Asana tickets as loose orientation pillars, not as a top-down task structure.

Clipping is positioned to quickly increase revenue and bring in new Tikfinity users, serving as a bridge to the recorder product; day-one monetization will be creator-focused clipping only.

Most needed API endpoints are described as small (about five minutes each) since they are existing views of already-stored data.

Platform where clipping features will be pushed; users serve as bridge into recorder product

Core product for recording, storing, and clipping content

Later-stage use case; Lukas building MVP POC

AI tool David is being provisioned with tokens for

Task/ticket coordination board

Coordination channel

Storage standard discussed for self-hosted storage servers

Storage provider with lower pricing for infrequent access

Reference competitor whose viewers pay for recordings/storage

Framework used for mobile development

Coordinates releases, legal docs, strategy

Builds AI marketplace POC, created Asana tickets, API document owner

Reverse engineering, front/back-end, built recording infrastructure

Lead for clipping and web app

UX/UI product designer

Mobile developer (Flutter)

From Tikfinity, involved in release coordination

Sebastian opened the daily call, intended to be short (about 15 minutes), while waiting for the new team member Isaac. The team experimented with meeting bots and noted that one participant, Marco, did not give consent and left. Sebastian outlined his own focus: coordinating release structures with Tom from Tikfinity and Lukas, defining a compact feature set with Marco and the team, and obtaining the necessary legal documents. He explained the loose, non-dogmatic coordination structure using an Asana board. Isaac introduced himself as someone who works on reverse engineering and front/back end development and built the infrastructure for recording VODs. David introduced himself as a Flutter mobile developer, and Michael Mensah as part of the product team handling product/UX-UI design. Sebastian recapped the overall strategy for Isaac: start with clipping (closest to current Tikfinity user needs and a way to grow revenue and onboard users to the recorder), then add low-level TD integration, web and mobile apps, content moderation/live recording, and eventually an AI marketplace (currently a POC Lukas is building). He described role distribution, noting Michael is currently blocked partly because the corporate design with a hired agency is not finalized. The technical discussion centered on API endpoints Lukas documented, with comments from Isaac and Marco. Topics included whether the content/compliance (consent) layer should sit in Isaac's layer or the backend API, with Isaac noting a mini consent layer already exists and is needed short-term. They discussed storage management, the need for APIs to mark streamers for recording and fetch past VODs, and significant uncertainty about storage size per user and the business model. Isaac raised that storage will be the main cost driver and proposed self-hosted S3-compatible storage servers to cut costs at scale. Marco and Sebastian discussed hot vs. infrequent-access storage and a possible triage retention system, plus monetization models (e.g., viewers paying for recordings, like Stream Recorder, or data brokers storing data). The meeting concluded as an intro/getting-to-know call, with detailed coordination deferred to smaller follow-ups.

The team decided to build the product layer by layer, beginning with clipping as the first layer since it is closest to current Tikfinity user needs, to increase revenue and bring in new users to consent to the recorder.

After clipping, plan to add low-level TikTok integration, mobile and web apps for the recorder, content moderation/live recorder use cases, and finally an AI marketplace use case (MVP POC built by Lukas).

A mini consent layer already exists in the recording infrastructure. The team agreed to keep it for now rather than making it collection-only, since the API is not yet built and both recording and AI labs needs must be served simultaneously.

Coordination will use a loose structure with Asana tickets serving as orientation pillars rather than top-down task assignments.

Coordinate with Tom from Tickfinity and Lukas to create the first release structures and define a compact feature set with Marco and the team.

Ensure the team receives the right documents from the lawyers; a draft already exists.

Hold a smaller follow-up call between Marco, Isaac, and Lukas to finalize which API endpoints are needed and who owns the consent/storage layers.

Provide APIs to mark a streamer to be recorded, fetch information about past VODs, and retrieve recording information for use in the app and other stream situations.

Have a short follow-up talk about TikTok and connection-related topics.

Settle on the corporate design so the contracted agency can finish, unblocking UX/UI work.

Storage is expected to become the main cost. Estimates mention bills potentially reaching ~$30,000/month, which could be reduced (e.g., to ~$10,000/month) by switching storage providers or self-hosting S3-compatible servers, but switching becomes harder at large scale.

The business model and per-user storage requirements are not yet finalized, making it unclear how much data must be stored hot versus cold and how costs should be structured.

The product/UX work is blocked because the corporate design is not finalized and a contracted agency has not completed its work.

The whole effort depends on the existing recording/reverse-engineering infrastructure, creating a single point of dependency until the broader API and production setup are built.

It is unresolved whether content and compliance/consent management should live in the recorder layer or the backend API layer, which has data-extraction and compliance implications.

Should the content and compliance management (consent) layer be in the recorder layer or in the backend API layer?

Should the team set up its own rented storage servers with S3 to reduce future storage costs?

How long to retain different content types, including a possible triage system keeping some content longer and deleting other content after days/weeks.

Whether to adopt a model where viewers pay for recording/storage, as competitors do; uncertain especially for day one which is creator-focused only.

Whether partner data brokers can take on storing data given uncertainty about data set size.

The team is small and just getting started, with responsibilities and structure still in flux.

Sebastian coordinates release and legal; Marco leads clipping and web app; Michael is UX/UI designer (corporate identity, screen design); David is mobile developer (Flutter); Isaac handles reverse engineering, front-end and back-end and the recording/VOD infrastructure; Lukas builds the AI marketplace MVP/POC.

Clipping is positioned as a bridge for existing Tikfinity streamers to start recording, storing and clipping content.

Most needed endpoints are described as small (about five minutes each) as they are existing views of already-stored data.

Isaac has worked with Sebastian and Lukas previously and earlier worked from a security side; focuses on reverse engineering and full-stack development.

Existing platform whose users are the initial target for the clipping feature

Product being built for recording, storing and clipping stream content

Later-stage use case with an MVP/POC being built by Lukas

Used for loose task coordination via tickets

Mentioned as a channel for coordination

Storage standard considered for self-hosted storage servers

Mentioned as offering lower pricing for infrequent-access storage

AI tooling/tokens to be provisioned to David

Competitor referenced for its viewer-pays storage monetization model

Platform integration and connection topic for follow-up

Coordinates release structure and legal documents

Builds AI marketplace MVP and coordinates infrastructure/API

Reverse engineering and recording/VOD infrastructure

Lead for clipping infrastructure and web app

UX/UI and product design

Mobile developer (Flutter)

From Tickfinity, involved in release structure coordination

Mobile developer using Flutter

UX/UI/product designer handling corporate identity

Contact at Tikfinity for release coordination

The team held a short intro and daily coordination call. Lukas mentioned experimenting with multiple recording bots and testing transcription performance; Marco reportedly did not give consent. Isaac, a new team member who works on reverse engineering, front end, and back end development and built the infrastructure for recording VODs, introduced himself. Other members stated their roles: David as a Flutter mobile developer, Michael Mensah as product/UX-UI designer, and Marco as lead for clipping and the web app. Sebastian recapped that the team is small and in flux, using an Asana board as loose orientation rather than a top-down task structure. Sebastian outlined the strategic plan to build the product bottom-up, beginning with clipping as the first layer because it is closest to current Tikfinity user needs and serves as a bridge to onboard users and gain consent for the recorder. Subsequent stages include low-level Tikfinity integration, mobile and web apps, content moderation / stream recording use cases, and finally an AI marketplace, for which Lukas is building an MVP/POC. All components depend on Isaac's infrastructure. The technical discussion focused on Lukas's shared API document, on which Isaac and Marco had left comments. They discussed whether the content and compliance/consent management should live in Isaac's layer or the backend API layer; Isaac noted a mini consent layer is already built and is needed for now. They also discussed storage management and which endpoints are needed (marking streamers to be recorded, fetching past VODs). Isaac raised that storage costs will become the dominant expense and proposed renting low-powered servers with attached storage running S3 to reduce costs at scale. Sebastian described a triage system for retaining content and possible business models, including having viewers pay for storage (as a competitor does) or having data-broker partners store data. The group agreed many endpoints are small and that a smaller follow-up call would resolve details.

The team decided to build the recorder product incrementally, starting with a clipping layer as the first phase because it is closest to current Tikfinity user needs, followed by Tikfinity integration, mobile/web apps, content moderation/stream recording, and finally an AI marketplace use case.

Rather than making the recorder a collection-only layer immediately, the team will keep the existing mini consent/compliance layer within it for now since the API is not yet built out and AI labs use cases require it; purity refactoring may happen later.

Storage management (e.g., handling full storage) is considered a later requirement and not needed for the first iteration.

From day one the product will focus only on creators with a straightforward creator clipping business model, deferring viewer-pays-for-storage models.

Define the first release structures and a possible compact feature set for pushing into Tikfinity, coordinating with Tom from Tikfinity, Lukas, and Marco.

Ensure the team receives the correct documents from the lawyers; a draft exists but final documents are pending.

Arrange a smaller follow-up call between Marco, Isaac, and Lukas to discuss and finalize which API endpoints are needed and who builds them, including clipping infrastructure endpoints.

Provide APIs to start a recording, mark a streamer as 'should be recorded', and fetch information about past VODs so the data can be used in the app and other contexts.

Isaac to have a short follow-up conversation with Lukas about TikTok and connection topics; Lukas to message Isaac later to schedule.

Storage is expected to become the main cost driver as scale grows; estimated bills could reach ~$30,000/month, potentially reducible to ~$10,000/month by switching to self-hosted S3 storage servers, but migration becomes harder once data volume is large.

Running self-managed S3-compatible storage servers trades hosting cost savings for the need to dedicate a DevOps engineer to orchestrate the infrastructure.

The product design role is blocked because the corporate design has not been fully settled, partly due to internal delays rather than the external agency.

The business model and expected storage per user remain unclear, making cost structuring and storage retention decisions difficult.

Whether the content and compliance management should sit in the recorder layer or the backend API layer is still being discussed; preference leans toward the recorder layer to ease data extraction for AI labs.

Uncertainty about whether to adopt a viewer-pays-for-storage model like Stream Recorder, and whether to do so beyond day one.

How long different types of content should be kept under a triage system (always-keep vs delete after days/weeks vs flagged) is not finalized.

Unclear whether data broker partners can store the volume of data the team would generate, depending on data set size.

Small early-stage team: Sebastian coordinates releases/strategy and legal; Marco leads clipping and the web app; Michael Mensah is UX/UI designer handling corporate identity and screen design; David Simeon is mobile developer (Flutter); Isaac Kogan works on reverse engineering and front/back-end and built the VOD recording infrastructure; Lukas builds the AI marketplace MVP/POC.

Lukas created Asana tickets used as loose orientation pillars rather than a strict top-down task system; coordination also happens via Slack and bilaterally.

David is to be provisioned with tokens for Claude Max.

This was intended as a roughly 15-minute daily and intro/getting-to-know call, including an introduction of new member Isaac.

Lukas shared a document describing API endpoints; Isaac and Marco have added comments to it.

Core product for recording, storing, and clipping streamer content

Existing platform/user base used as a bridge to onboard users to the recorder product

Used for task/ticket coordination

AI tool David is being given token access to

Storage standard considered for self-hosted storage servers

Mentioned as having lower pricing for infrequent access storage

Reference competitor that monetizes by having viewers pay for recording storage

Longer-term use case Lukas is building an MVP/POC for

Use case requiring data extraction from recorded content

Coordinates releases, strategy, and legal documents

Builds AI marketplace MVP and backend API; created Asana tickets

Lead for clipping infrastructure and web app

Reverse engineering and front/back-end developer; built VOD recording infrastructure

Participant deciding on payout system

Participant; clarifying SEPA fees with bank

Payment method used for streamer payouts

Lukas opened the meeting by stating the need to discuss the reward payout system for streamers. Marco proposed allowing payouts only from a minimum balance of 50 euros, which Lukas agreed to, noting that small amounts cause excessive transaction fees. Marco raised the concern that new streamers could be demotivated if the threshold is set too high. Despite this, Lukas made the decision to set a minimum payout of 50 euros, paid monthly via SEPA. Marco committed to clarifying the SEPA fees with the bank by Friday. Lukas closed by raising an open question about whether an upper limit per payout is needed for compliance reasons.

Minimum payout for streamers is 50 EUR, paid monthly via SEPA.

Marco will clarify SEPA transaction fees with the bank by Friday.

Setting the minimum payout threshold too high risks demotivating new streamers.

Small payout amounts cause disproportionately high transaction fees.

Whether a per-payout upper limit is required for compliance reasons is unresolved.

Lukas opened the meeting to address the reward payout system for streamers. Marco proposed allowing payouts only above a minimum balance of 50 euros, which Lukas supported, noting that small amounts cause excessively high transaction fees. Marco raised the risk that new streamers could be demotivated if the threshold is set too high. Despite this concern, Lukas confirmed the decision: a minimum payout of 50 euros, processed monthly via SEPA. Marco agreed to clarify the SEPA fees with the bank by Friday. Lukas closed by raising an open question about whether a per-payout upper limit is needed for compliance reasons.

Streamer reward payouts are allowed only from a minimum balance of 50 EUR, paid out monthly via SEPA.

Marco will clarify the SEPA transaction fees with the bank by Friday.

Setting the minimum payout threshold too high risks demotivating new streamers.

Small payout amounts cause disproportionately high transaction fees.

It is unclear whether a maximum payout limit per transaction is required for compliance reasons.

Project concerning the reward payout system for streamers

Payment method used for monthly streamer payouts

Participant defining payout decisions

Participant clarifying SEPA fees with the bank

Lukas and Sarah discussed how to approach Gmail integration for the company memory. Sarah raised concerns that importing everyone's full mailbox would be a privacy issue, and Lukas agreed that full mailbox sync would create too much noise and trust issues with the team. They aligned on starting with explicit capture only, using labels or forwarding, while keeping raw email content restricted. Lukas recorded the decision to use explicit Gmail thread capture instead of full sync for the MVP. Sarah committed to defining the minimum OAuth scopes before implementation begins. Lukas noted an open question about whether per-thread visibility controls would also be needed.

For the MVP, the company memory will use explicit Gmail thread capture (via labels or forwarding) instead of full mailbox sync.

Define the minimum OAuth scopes required before implementing the Gmail integration.

Full mailbox sync was identified as creating excessive noise and raising privacy and team trust concerns; avoided in favor of explicit capture.

Whether per-thread visibility controls are needed for the Gmail integration.

Raw email content is to be treated as restricted within the company memory system.

Integration to capture email content into the company memory system

Internal knowledge system receiving captured Gmail threads

Email source for explicit thread capture

Authorization mechanism; minimum scopes to be defined

Participant leading the integration discussion

Participant; owner of OAuth scope definition