Org design and simulator
Reshape the org on screen before you reshape it in the room
Map your product organisation once, then propose a change — centralise AI into one team, split platform from product, move design under research — and get a structured read on what it does to velocity, alignment, cost, quality and retention before anyone gets told.
An example product organisation — 8 teams, 29 people. Headcounts move with the change, so the chart and the assessment describe the same org.
The embedded design model is a deliberate bet on velocity and ownership that matches this squad-based structure; centralizing design trades real shipping speed and quality risk in the Core squad and Platform squad (your retention and integration engines) for hypothetical standardization gains that a 4-person design group can achieve through lightweight critique and pattern libraries instead.
Growth squad, Core squad, and Platform squad currently ship to their own targets with embedded designers who understand their specific constraints and roadmaps; pulling designers into a central team introduces handoff delays, scheduling friction, and designer context-switching that will slow iteration cycles across all three squads.
A central design team could standardize patterns across Growth, Core, and Platform work and reduce local design conflicts, but it risks creating a bottleneck where the single designer in Growth squad and the two in Core squad must now coordinate through a separate organizational layer, potentially creating misalignment between design decisions and squad PM/engineering priorities.
Headcount remains the same (4 designers either way), so there's no direct cost saving; however, you may incur hidden inefficiency costs from designers' time spent in coordination overhead rather than shipping, offsetting any theoretical economies of scale.
Embedded designers in Growth, Core, and Platform squads currently catch misalignments between design intent and engineering implementation in real-time; centralizing design increases the risk that platform-specific constraints (like API design patterns or onboarding conversion mechanics) are missed or designed without full technical context.
Designers in Growth squad and Core squad who have operated as full squad members with shared accountability and autonomy will likely experience a loss of ownership and belonging when pulled into a services-oriented central team; this shift often triggers retention risk among mid-level individual contributors who value being 'part of the team.'
Propose the change on the chart, then read what it costs you. Map your org by hand or describe the shape in plain English. Every simulated change is assessed on the same five dimensions — velocity, alignment, cost and efficiency, quality and risk, culture and retention — each with its own reasoning, an overall call, and the precedent from the gallery behind it.
product signals the simulator grounds its precedent in
product leaders mapped, with role and reporting line
dimensions every simulated change is assessed on
The simulator
Propose the change, then read what it costs you
Org Design & Simulator
Build a custom org from scratch, or browse illustrative examples from well-known companies — then simulate the implications of a structural change.
Example product org · 8 teams · 90 peoplePick a change above to see the structure move and what it would cost you.
The five dimensions
Stress test your org changes against five core dimensions
Every simulated change is assessed on the same five, including the verdicts you would rather not hear.
- Queues behind a shared backlog
- Handoffs added or removed
- Whether one roadmap can still hold the work
Every simulated change is scored on all five, then weighed against each other — a strong velocity gain does not automatically outweigh a serious retention risk.
The same five, every time. A verdict is only comparable across changes if the thing being measured does not move — so each dimension carries a written definition, and the simulator is held to it.
The gallery
Use sample org chart structures as inspiration
Every verdict is grounded against the structures the gallery already holds, so a recommendation carries a precedent you can go and read rather than only an opinion.
Amazon26 teams
Anthropic24 teams
Netflix24 teams
Replit24 teams
Stripe23 teams
ElevenLabs21 teams
Canva20 teams
Figma20 teams
Notion20 teams
Lovable19 teams
Linear14 teamsEach one carries a methodology note naming the sources it was built from — About pages, careers pages, interviews — so you can see how firm the record is before you compare yourself against it.
Compare against how the market is organised. Real structures for companies at very different scales, each built from named public sources, so “how does everyone else arrange this?” is a question you can answer with structures rather than anecdotes.
How the org chart gallery is built
Each structure is assembled the same way, from sources you can go and check yourself.
Every structure closes with a methodology note naming its sources and numbering them against the claims they support — so before you compare yourself against a company, you can see how firm the record on it is.
You can see how each structure was built. A gallery org is only worth comparing yourself against if you know where it came from, so every one is assembled the same way and shows its working.
Lovable19 teams · 213 people| Team | Function | Headcount | Reports to | Members |
|---|---|---|---|---|
| Founder's Office / CEO | Top-level leadership and company vision, led by co-founder and CEO Anton Osika, who has described Lovable's approach as a small, talent-dense team built to move with 'extreme ownership, high velocity, and low-ego collaboration.' | 3 | Top level | Anton Osika — Co-founder and CEO |
| Engineering | Builds and scales Lovable's core AI app-building platform, backend systems, and infrastructure supporting millions of users, led by the CTO. | 45 | Founder's Office / CEO | Fabian Hedin — Co-founder and Chief Technology Officer |
| Head of Engineering | Engineering leadership function reporting into the CTO's organization, overseeing day-to-day technical execution across product engineering teams. | 5 | Engineering | Patrik Torstensson — Head of Engineering |
| Product | Owns product strategy and roadmap for the Lovable platform, including agent mode, visual edits, and enterprise features, working closely with Engineering and Design per the company's own careers listings. | 12 | Engineering | — |
| Design | Product design team responsible for user flows, mockups, and craft quality across the Lovable app-building experience, a named function on Lovable's own careers/jobs listings. | 8 | Engineering | — |
| Data | Builds and maintains data pipelines and analytics infrastructure supporting product and business decisions, a named team on Lovable's job board. | 5 | Engineering | — |
| Trust & Safety / Security | Handles fraud operations, payment risk, penetration testing, and platform trust and safety cases, per Lovable's own open job listings. | 6 | Engineering | — |
| Revenue / GTM Organization | Owns all revenue-generating go-to-market functions (Sales, Marketing, Partnerships, Revenue Operations) as Lovable's GTM organization scales rapidly, led by the Chief Revenue Officer. | 40 | Founder's Office / CEO | Ryan Meadows — Chief Revenue Officer and Head of Revenue |
| Sales | Runs enterprise and SMB sales cycles from outreach to contract closure, including dedicated Enterprise Account Executive and Founding Sales Leader roles listed on Lovable's careers page. | 14 | Revenue / GTM Organization | — |
| Marketing | Covers brand, content, product marketing, website/SEO, and customer marketing, per multiple named roles (Brand Editor & Copywriter, Website & Organic Search Lead, Customer Marketer) on Lovable's job listings. | 12 | Revenue / GTM Organization | — |
| Partnerships | Manages Lovable's partnership ecosystem end-to-end, from sourcing to growing partnerships, collaborating with multiple teams to drive measurable impact, per Lovable's own job description. | 5 | Revenue / GTM Organization | — |
| Revenue Operations | Supports GTM leadership with forecasting, quarterly planning, and operating rhythms across Sales, Marketing, and Partnerships, referenced in Lovable's own CRO-support job listing. | 4 | Revenue / GTM Organization | — |
| Community | Builds and scales Lovable's global community programs across social channels and events, led by a Head of Community per Lovable's own job posting for a Community Program Lead reporting into that role. | 6 | Revenue / GTM Organization | — |
| Customer Experience (CX) / Support | Owns ticketed support, async support, incident response, and onboarding, plus agentic support infrastructure to scale coverage without scaling headcount 1:1, per Lovable's own careers listings. | 10 | Revenue / GTM Organization | — |
| Customer Success / Solutions | Includes Solutions Architects and Customer Education leads who guide enterprise customers through technical solutions and educational programs, per Lovable's careers page. | 8 | Revenue / GTM Organization | — |
| Finance, Business & Operations | Leads finance, business, and operations, defining and defending Lovable's business model while accelerating growth, per CEO Anton Osika's own announcement of this hire. | 15 | Founder's Office / CEO | Andy Toung — Chief Financial Officer (leading finance, business, and operations) |
| Legal | Handles enterprise contracting, compliance, and product counsel, including a Lead Product Counsel role directing regulatory and compliance work, per Lovable's own job listings. | 5 | Finance, Business & Operations | — |
| People / Recruiting | Recruiting operations and talent acquisition supporting Lovable's rapid global hiring, a named function referenced in Lovable's own job listings (e.g. Recruiting Operations roles); no named Head of People was found in public sources. | 6 | Finance, Business & Operations | — |
| Workplace / Facilities Operations | Manages office operations, events, and facilities across Lovable's growing office footprint (Stockholm, London, Boston, SF, NY), per a named Workplace Manager role on Lovable's careers page. | 4 | Finance, Business & Operations | — |
Illustrative approximation drafted from public knowledge — not verified against Lovable’s actual structure. The five members carrying a tick are corroborated against a named public source.
Open one and you get the whole structure. Canvas or table, the same record either way — function names, reporting lines, and which leaders are actually verified against a public source.
Why it is worth mapping
Map your org once and every other answer gets sharper
The org map is not a diagram you draw and file. It becomes part of your company profile, and every module reads it — so advice arrives already knowing how you are set up to act on it.
The same question, answered two different ways. A 40-person company and a 400-person one should not get the same recommendation, and once the structure is on file they do not.
Map the whole company
Founders, CPOs and heads of product with the full picture
Every function, not just yours — engineering, design, sales, support, operations. The simulator can then reason about spans of control, where a function is duplicated across groups, and what a change does to the teams downstream of you rather than only the ones you own.
- Reorgs that cross function boundaries
- Comparing your shape against the gallery structures
- Questions about headcount ratios between functions
See more of the platform