20260425_First Team Meeting¶

Date: April 25, 2026 Purpose: Team discussion sheet for the first in-person RapidDraft meeting Use: Align on what is already decided, what still needs a team decision, and which founder and ownership questions should stop being implicit Outcome page: See 20260426_First RapidDraft Team Meeting for the transcript-based synthesis of the actual discussion.

Why This Meeting Matters¶

The wiki already contains a strong product thesis, a clearer pilot wedge, and a much more grounded view of the technical and founder risks than it did a few months ago. What it does not yet give us is one single place where the whole team can discuss the hard tradeoffs together: vision versus focus, collaboration narrative versus product reality, long-term ambition versus near-term wedge, and commitment versus ownership.

This page is meant to make that conversation concrete.

What Looks Decided Already¶

These items read as current company direction in the wiki. They can still be revisited, but the team should treat them as "change deliberately, not accidentally."

Area	Current wiki position	Why it matters
North star	TextCAD is building an AI-first engineering workspace where conversation is the control surface, deterministic systems remain the source of truth, and native CAD/CAE tools remain the authoring authorities.	This is the deepest product boundary and trust model.
AI authority boundary	Deterministic checks are authoritative; AI is advisory; human-in-the-loop is non-negotiable.	This protects trust, adoption, and liability posture.
Product narrative	RapidDraft is positioned collaboration-first, not automation-first.	This shifts the product from "plugin utility" toward "engineering workflow platform."
Sequencing	RapidDraft Core comes before Studio.	Revenue, pilots, and product trust should come before the full IDE ambition.
Initial market	Germany and Central Europe first, especially industrial machinery and heavy-equipment-adjacent teams.	This keeps go-to-market founder-accessible and engineering-led.
Workflow wedge	Structured CAD/PDM teams where drawings, reviews, release hygiene, and design-change documentation still create repetitive manual work.	This is the most credible pilot entry point today.

Hard Discussion Topics for Today¶

These are the topics most worth discussing in person because the wiki shows real tension or an explicit gap.

Topic	What the wiki says now	Why discuss it now	Hard question for the room
Default external story	Go-to-market says the product story still spans Core and Studio without one declared default narrative.	External conversations get weaker when the team tells two different stories.	For the next 6-12 months, are we selling RapidDraft Core, or are we still splitting attention between Core and Studio?
Near-term wedge	Claudio's workflow interview points to change summaries, DCR authoring, revision comparison, and release-ready outputs as the clearest first ask.	This is the difference between a believable pilot and a broad platform pitch.	Are we explicitly committing to release-work automation as the first pilot wedge?
Collaboration promise versus shipped product	The strategy pages lead with collaboration, but the Core track says the collaboration surface and issue continuity are still shallow.	A narrative that runs ahead of product can damage trust.	What collaboration claim can we honestly make today without overpromising?
Ambition versus focus	Studio remains the long-term orchestration vision, but several Studio workflow families are still reference-only.	The team needs to know what is active now versus admired from a distance.	Which ambitions stay alive, and which ones are intentionally parked until pilots validate Core?
Pilot-readiness gaps	The code-review triage still flags security, route gating, runtime reliability, event-loop blocking, and append-only activity logging as top pilot blockers.	The next pilot will test trust more than vision.	Which technical gaps are truly blocking the next pilot, and who owns them?
Customer wedge discipline	The ICP is now narrower: structured mechanical teams with design-change documentation and release-review pain.	A sharper wedge improves discovery, demos, and pricing discussions.	Are we disciplined enough to exclude attractive but off-wedge customers for now?
Success metrics	The master narrative says early traction should be judged by decision speed, review quality, manufacturing improvements, and deployment reliability, not vanity metrics.	Teams drift when success is not operationally defined.	What exact outcomes would make the next pilot a clear win?

Vision, Motivation, and Ambition¶

The strongest product motivation in the wiki is not "replace CAD." It is to fix the repeated breakage around engineering handoffs: the CAD model, drawing, review comments, manufacturing feedback, and release logic are split across systems, so every revision recreates coordination overhead.

The long-horizon ambition is much bigger than faster drawing work. Studio describes an AI-first engineering workflow IDE where the orchestration layer is intelligent but native tools remain the human authoring authorities. The question for the team is not whether that ambition is exciting. The real question is whether everyone believes the near-term wedge is a credible path into that future rather than a distraction from it.

Discussion prompts:

Which part of the mission feels most real to us personally: faster releases, stronger review trust, manufacturing readiness, or the larger engineering-IDE future?
Do we still believe conversation-plus-deterministic-tools is the right long-term interaction model for mechanical engineering work?
What should RapidDraft absolutely not become, even if customers ask for it?

Technical Challenges Worth Discussing as a Team¶

The wiki is unusually honest about the hard parts. The product is not blocked by one bug. It is blocked by a cluster of trust and complexity problems that compound.

Challenge family	Current state in the wiki	Team discussion angle
Drawing variability	Templates, layers, notes, and title blocks vary heavily across customers.	How much onboarding/config work are we willing to accept per pilot?
Revision continuity	Stable linking of comments, findings, and dimensions across revisions remains hard.	What level of auto-carry-forward is good enough before pilots?
Teamcenter reality	Every Teamcenter environment is customized.	How much connector flexibility is needed before we call the workflow reusable?
Collaboration usability	If issue handling feels like admin overhead, people will bypass it.	What is the minimum collaboration surface that still feels worth using?
Generated-drawing trust	If the tool generates a drawing, users may assume it is approved.	How do we keep accountability human without making the workflow too heavy?
Pilot runtime hardening	Security, auth, atomic writes, dependency locking, event-loop blocking, and activity logging still need work.	Which reliability tasks are "must finish" versus "can follow after pilot"?
CAD intelligence depth	Injection molding is now materially working, but deep scan is still slow, geometry localization is still weak, and bounded edit loops are missing.	How much deeper do we go now versus after pilot traction?

Founder and Team Issues¶

The founder-facing notes in the wiki are clear that startup risk is not just technical risk. Fundraising, stress response, and team durability are all treated as first-order issues.

Themes already grounded in the wiki:

investors screen team quality before they truly understand product depth
the first investor is the hardest to close
early valuation discipline matters more than ego
team behavior under stress is a major signal
unresolved founder misalignment tends to show up under pressure
founders should avoid identity collapse, where startup setbacks become personal collapse

Discussion prompts:

What are the biggest stress points likely to create team fracture over the next 6 months: speed, money, ownership, role clarity, or product direction?
What does "full commitment" actually mean for this team in practical terms?
If we hit a hard technical setback or a failed pilot, how do we want to make decisions together?
What governance do we want before outside money makes these conversations more expensive?

Equity, Ownership, and Leaving¶

The wiki does not yet define a RapidDraft-specific sweat-equity policy or a good-leaver / bad-leaver policy. It does, however, provide a useful baseline for what should already be explicit.

Topic	What the wiki already says	Gap still open
Vesting baseline	Four-year vesting and a twelve-month cliff are described as standard early-stage terms.	No RapidDraft-specific founder or team vesting agreement is published in the wiki.
Founder compensation	A reasonable founder salary and an early ESOP pool are both recommended.	No current company policy is documented for salary versus pure sweat equity.
Ownership clarity	Shareholders' agreement and founders' agreement should cover real founder-governance logic, contribution expectations, and ownership.	No explicit RapidDraft ownership map is published here.
Leaving risk	The legal playbook warns that if a founder leaves or a dispute arises before structure is clean, the setup becomes fragile quickly.	There is no documented company-specific rule for what happens if someone quits early or reduces commitment.
IP assignment	IP should move into the company at incorporation time, and founder edge cases should not be left implicit.	The team still needs one explicit operational agreement around IP assignment timing and responsibility.
Long-term structure	A holding company can be valuable, but it must be decided early if wanted.	The desired founder structure is still listed as an open question.

What This Suggests for Team Discussion¶

The meeting should probably make these questions explicit:

If someone stays long term and keeps contributing, how should their ownership evolve in practice?
If someone leaves before incorporation, before a cliff, or after partial vesting, what should happen to unvested and vested ownership?
Are we treating current work as founder equity, sweat equity with vesting, employee-style equity, or some staged mix of these?
What contribution standard justifies equity: time, responsibility, IP, customer traction, cash, or a mix?
When do we want a formal shareholders' agreement and founders' agreement in place?

This page is not legal advice. It is a discussion aid to help the team see where the wiki already has guidance and where it is still silent.

Suggested Meeting Flow¶

If the team wants a structured in-person conversation, this agenda should fit in about 90 minutes.

Time	Topic	Goal
15 min	North star and motivation	Confirm what the company is really trying to build and why it matters
20 min	Near-term wedge and default product story	Pick the clearest current external narrative
20 min	Technical trust and pilot blockers	Agree what must be solved before the next pilot
15 min	Market and customer focus	Reconfirm who we are actually targeting first
20 min	Founder alignment, equity, and leaving scenarios	Surface hidden assumptions before they become conflicts

Open Questions¶

Is the default company story for the next year RapidDraft Core, or a Core-to-Studio transition story?
Is the team fully aligned that release-work automation is the sharpest current pilot wedge?
Which technical trust gaps must be closed before the next real pilot conversation?
What exact founder or team ownership model should RapidDraft use before incorporation is complete?
What should happen to ownership if someone leaves early, reduces commitment, or stays long term?