# BuilderLab: from solo learning to a shared engineering workflow Canonical HTML: https://dsti.school/techblog/builderlab-shared-engineering-workflow This Markdown copy is generated from the same DSTI static-site build as the canonical HTML page. It is intended for machine readability and concise retrieval. [DSTI TechBlog](https://dsti.school/techblog) / Students Students Software engineering in practice Live beta I am building BuilderLab to examine a practical learning problem: how can learners move from isolated exercises to the social, technical and operational constraints of delivering software with other people? RM By Richie Mouhouadi MSc Data Science & AI student at DSTI at the time of publication June 2026 · 12 min read · BuilderLab v0.5.0 ![BuilderLab interface showing a collaborative project workflow](https://dsti.school/assets/dsti-techblog-builderlab.7de28cb47f.png) ## A platform organised around the project lifecycle The current beta connects discovery, team formation, project coordination and a public record of progress. Some review functions remain planned rather than implemented. Core Find collaborators HiveOS Organise delivery HiveCheck Review the work ## In this article 01 — A testable problem02 — Product lifecycle03 — Application architecture04 — Domain and state model05 — Trust boundaries06 — Learning through maintenance07 — Evidence and next experiments08 — Open evidence BuilderLab began with a simple observation: the current way of learning does not reflect the actual dynamics once hired. Solo projects or tutorials rarely reproduce the conditions of team delivery. BuilderLab is therefore an attempt to close the gap between learning and working stages. BuilderLab treats this missing team experience as a product problem rather than another isolated exercise. It lets learners propose projects, find collaborators, coordinate work, maintain a Build Log and expose enough of the process for another person to understand how the result was reached — not only what the final interface looks like. The method behind it is deliberately iterative: state a problem , implement a constrained solution , observe its weaknesses , and decide what to test next. BuilderLab is useful to me precisely because it is not finished. ## 01 The collaboration gap is a testable engineering problem Students can practise SQL, Git, Linux, cloud deployment or a programming language alone. The difficult parts of professional engineering are often elsewhere: negotiating scope, dividing responsibility, handling disagreement, documenting decisions, recovering from blockers and maintaining a shared system after its first release. Learning gap ### Knowing a tool is not the same as working in a team A solo tutorial can teach syntax and APIs. It cannot fully reproduce ownership, handovers, access control or the consequences of another person's change. Evidence gap ### The final screenshot hides most of the work A project page can preserve milestones, updates, blockers, decisions, contributors and feedback so that the path to the result remains inspectable. Once we are employed as engineers, we work with other people every day. BuilderLab turns that ordinary fact into the organising constraint of the product. Step 1 Observe Identify a recurring learning or collaboration problem. Step 2 Model Translate the problem into roles, states and transitions. Step 3 Implement Build the smallest coherent flow and expose it to real use. Step 4 Revise Record failures, tighten boundaries and define the next experiment. ## 02 Three product layers follow one project from idea to review The product is divided into three connected layers. I use the separation to keep distinct problems visible rather than hiding them behind one broad idea of “collaboration”. Layer 01 BuilderLab Core Profiles, project ideas, discovery, join requests, team membership, following and public project pages. Live Layer 02 HiveOS Tasks, milestones, team chat and Build Log updates inside the project workspace. Live / evolving Layer 03 HiveCheck A completed-project index is live; structured peer reviews and their scoring method remain planned. Partly live / planned The intended lifecycle is more than project matching. A request can become membership; membership opens a workspace; selected task transitions can create public Build Log entries; project completion can lead to collaborator ratings; and a completed project can remain available as evidence. Each step requires an explicit state transition rather than only a new screen. ## 03 The application separates public discovery from authenticated work The current repository uses Next.js App Router with TypeScript. Route groups separate the public surface from the application workspace without changing the public URLs. Server Components obtain initial page data; Client Components handle forms, filters, modals, chat, task changes and optimistic interface updates. Public route group Landing page, vision, documentation and contact. Application route group Feed, profiles, projects, connections, notifications and HiveCheck. Route handlers Authentication callback, contact submission and selected notifications. Next.js server boundary Server Components fetch data and render initial HTML. React client boundary Interactive state remains in focused client components. Supabase PostgreSQL Projects, profiles, membership, tasks and project records. Supabase Auth + RLS Cookie-based sessions and database-level access policies. Resend + Vercel Transactional email and deployment of the Next.js application. The typical page flow is a Server Component reading rows and identity context before handing the result to a Client Component for interaction. This is visible in the feed and project-detail flows. Server page app/(app)/feed/page.tsx fetch projects + current user Client state components/Feed.tsx search, filters, ownership context Interaction ProjectCard + InterestModal join requests and follow actions ## 04 The data model follows the social and technical life of a project The most important modelling decision was to avoid treating a project as only a title and description. BuilderLab represents identity, discovery, team formation, execution, completion and feedback as related but different concerns. Identity and capability profiles user_skills builder_type institution program Discovery and team formation projects project_skills connections project_members project_followers Execution record milestones tasks project_updates project_messages Completion and feedback ratings project_comments notifications contact_messages A connection is a request, not membership. A follower can inspect restricted project sections but cannot act as a member. A member can leave without disappearing from the historical record. A task can be assigned, blocked or linked to a milestone. A public update is different from a team message. These distinctions make the product idea visible in the schema and give access policies something precise to enforce. Database-owned transition. When a connection changes from `pending` to `accepted`, a PostgreSQL trigger inserts the sender into `project_members`. The transition is atomic and does not depend on a client successfully performing a second request. ## 05 Trust boundaries should survive a direct API call Authentication is not the same as authorisation. Hiding a button can guide a user, but it cannot protect a database. For the flows below, the interface and PostgreSQL Row Level Security share responsibility: the interface presents the valid actions, while database policies reject operations outside the authenticated user's role. ### Q1 Who may change a task? The project owner can create, modify or delete any task. The owner may delegate the HiveOS Manager role to one active member at a time, giving that person the same task-management rights. A regular member may update the status of a task assigned to them. The policy checks the owner, manager and assignee identities at database level. Current limitation: the database controls who may update an assigned task, but the detailed set of allowed status transitions is still largely guided by the interface. A stricter transition policy would reduce that remaining trust in client behaviour. ### Q2 How does an accepted request become membership? A request begins as a row in `connections`. After the owner accepts it, a PostgreSQL trigger creates the active `project_members` row with conflict protection. This keeps acceptance and membership consistent even if a caller bypasses the interface. ### Q3 What happens when a member leaves? Leaving voluntarily and removal by the owner both require a reason of 10–300 characters. The membership row changes to `left` instead of being deleted, the rating requirement is cleared, access to team-only functions is removed, and remaining assigned tasks become unassigned. The reason is not shown to the wider team. The current specification also exposes a cleanup case: if the departing member was HiveOS Manager, the manager flag can remain stored even though the member no longer has access. Automating that cleanup is a reasonable next database change. ### Q4 Which project sections are public? Milestones, Build Log, Team Chat and Team members each have an independent owner-controlled toggle and are public by default. When restricted, they remain visible to the owner, active members and followers. Followers therefore form an intermediate trust tier: they can inspect more context but cannot post updates, chat or use HiveOS. This means “private” currently means restricted to a defined project audience, not visible only to the active team. The wording and interface need to keep that distinction clear. ### Q5 How are notifications sent without exposing email addresses? Email and in-app notifications are created through server-side route handlers using the Supabase service-role key, which is never sent to the browser. The route reads the recipient's email on the server, sends the email through Resend and creates an in-app notification. Notification rows are readable only by their intended recipient through RLS. Keeping the key server-side is necessary, but not sufficient. These routes should continue to gain explicit caller and workflow verification, input validation, rate limiting and operational logging. ### Q6 How does documentation remain aligned with the database? At present, alignment depends on discipline rather than an automated proof. I apply each migration to a development Supabase project, update the database documentation immediately, record the product change in the changelog, and commit migration, documentation and application code together. This is the weakest boundary in the current process because nothing automatically demonstrates that the documentation matches the live schema. Schema introspection and a documentation diff are natural next experiments. ## 06 A live product turns lessons into changes in method The codebase has grown while I have been learning. That is visible in useful features, but also in files that have become too large, migration history that does not yet provide a complete reproducible path, five-second polling in team chat, and an earlier quickstart that refers to SQL setup files no longer present in the supplied archive. Testing is the clearest example of a changed method. I did not begin BuilderLab with an automated testing strategy. That was an oversight. During an MLOps class, the advice to introduce tests early rather than retrofit them after the system becomes difficult to change made the cost of that decision clearer. I have since written a testing strategy on the development branch. It is a start, not yet a complete automated suite or a continuous-integration gate. I am taking a similar approach to infrastructure. I could patch the old SQL quickstart immediately, but the intended direction is a declarative environment built with Terraform. I would rather establish that process after covering the relevant concepts and then replace the obsolete setup path once, instead of refreshing instructions that I already expect to supersede. Build in public should include process changes. The useful evidence is not only a list of completed features. It also includes an acknowledged oversight, the lesson that changed my approach, the partial correction now under development, and a testable plan for the next version. ## 07 What the beta demonstrates—and what I would test next ### Current evidence - Public and authenticated routes are separated without changing the external URL structure. - Server, browser and service-role Supabase clients represent different trust boundaries. - The domain model distinguishes requests, followers, members, owners, managers, tasks, milestones, updates, chat and ratings. - HiveOS turns selected task events into Build Log evidence without publishing every internal action. - Database triggers protect important transitions such as profile creation and accepted-request membership. - The product is deployed as a live beta with public documentation and source code. ### Known constraints - The migration history should become the reproducible source of truth for the current schema. - Several interactive components need decomposition before they become harder to test and maintain. - Team chat polling should be replaced or made incremental as usage grows. - The testing strategy must become executable tests and an automated gate. - The quickstart should be replaced by a declarative provisioning path rather than patched indefinitely. - Documentation-to-schema alignment still needs an automated check. Policy tests Exercise owner, manager, assignee, follower and unauthorised API calls against RLS policies. Transition tests Verify accepted requests, departures, task unassignment and manager cleanup as database-level state transitions. Notification route tests Check caller identity, expected workflow state, recipient isolation and failure behaviour before sending email. Schema drift check Introspect the development schema and compare it with migrations and generated documentation. Declarative environment Use Terraform to make the development setup repeatable and retire the obsolete SQL quickstart. Measured chat delivery Compare Realtime or incremental polling with the current five-second polling approach under realistic activity. None of these steps is valuable merely because it uses another tool. Each should answer a specific question: does the policy reject the wrong actor, can the environment be reproduced, does the documentation detect drift, or does a new messaging mechanism reduce reads without weakening delivery? BuilderLab’s educational value is not that every architectural decision is complete. It is that the project gives me a place to practise team formation , state modelling , access control , testing , delivery and maintenance as one connected system. ## 08 Open evidence BuilderLab remains a live beta. The links below expose the product, its user-facing documentation and the source repository so that the claims in this article can be inspected rather than accepted on description alone. [Live beta Current product surface and access to the application.](https://builderlab-tau.vercel.app/)[User documentation Project formation, roles, HiveOS and the intended workflow.](https://builderlab-tau.vercel.app/docs)[Source repository Application structure, architecture notes, database documentation and changelog.](https://github.com/rdmouhouadi/BuilderLab)[Richie Mouhouadi MSc Data Science & AI student at DSTI and BuilderLab author.](https://www.linkedin.com/in/richie-mouhouadi/)