Twelve hand-authored Q&A entries on the most-frequent founder questions, principal-context-anchored, 250-350 words per answer. Use as a starting frame for your own decision; not a substitute for live mentorship.
How much equity should I give to a cofounder joining six months in?
Six months in is not standard 50/50 territory; use a dynamic-equity framework with vesting cliffs.
I started solo. I now want to bring on a technical cofounder. They are joining at the six-month mark. Is 50/50 still the rule? It feels wrong because I have been working alone the whole time.
Fifty-fifty is the rule when both founders start day one with comparable risk and contribution. Six months in, you have already taken the cold-start risk that they are not taking — that asymmetry is real and should reflect in equity. The cleanest framework is dynamic equity (Mike Moyer's "Slicing Pie" is the practitioner reference): you assign weights to time, capital, and pre-existing IP contributed, and equity tracks contribution. In practice, a six-month head start usually maps to something between 60/40 and 70/30 in favour of the original founder, with the new cofounder catching up via vesting if they contribute proportionally going forward. Pair the equity decision with a four-year vesting schedule with a one-year cliff for both founders — including yourself, retroactively. The most expensive mistake here is over-corrected generosity: founders who give 50/50 to a cofounder six months in routinely regret it, because if the cofounder leaves at month seven they walk with founder-stake. Vest everyone, including yourself. Consult a registered company-secretary or local equivalent before signing. Also: run the cofounder-fit diagnostic before formalising — most six-month-in cofounder relationships break in months 12-18, and the failure mode is usually visible at formation but suppressed because the original founder was lonely and excited.
Founders at any stage who want clear, principal-anchored answers to the questions other founders are also asking. Particularly relevant for first-time founders, second-generation family-business successors, MSME operators, and solo founders working without a peer-network sounding board. Not a substitute for personal mentorship, but a structured starting point.
what
What does it cover?
Twelve hand-authored Q&A entries on the most-frequent founder questions: when to quit a job, equity for late-joining cofounder, picking a first export country, relocating-for-startup, handling first major churn, raise-vs-bootstrap, first hire timing, pivot-or-persist, distributed-team time zones, when to shut down, modernising family business, first international conference. Each entry runs 250-350 handwritten words.
when
When to use it?
When facing a decision that has the texture of "I have heard advice from many people but it does not feel applied to me". The Q&A entries are not generic — each anchors to a specific principal-context (Indian MSMEs, family businesses, India-headquartered SaaS, multi-time-zone teams). Use as a starting frame, not a final answer.
where
Where does it apply?
Each entry is geographically agnostic on principle but principal-anchored in detail. The first-export entry uses Karur home-textiles as the worked example; the relocate-for-startup entry uses Bangalore-SaaS to US as the worked example; the family-business entry uses Surat-textile-trading as the worked example. The frameworks transfer across geographies; the worked examples ground them.
why
Why these twelve?
Because most early-stage founder questions have answers that are well-known to experienced founders but not yet known to the asker. The asynchronous office-hours format compresses the hours of mentorship-style conversation needed to surface these answers into a paragraph the asker can read in two minutes. Not a replacement for mentorship; a precursor.
which
Which questions are covered?
The twelve entries selected here are the questions most-frequently surfaced in cohort programmes, accelerator office hours, and direct conversations with first-time founders. They cover roughly eighty percent of the recurring questions; the remaining twenty percent are too specific to generalise and require live mentorship.
whose
Whose framework?
Composed by AJG editorial drawing on direct conversations with first-time MSME founders, second-generation family-business operators, India-headquartered SaaS founders, multi-time-zone team leads, plus the practitioner literature on founder decisions (Y Combinator essays, First Round Review, the failure-mode literature). Principal-context applied throughout.
how
How is each entry structured?
Each entry follows the same structure: q-summary in one sentence, full-question for context, answer in 250-350 handwritten words with a clear framework, tags for cross-reference, and links to relevant ATLAS tools. Designed to be readable in two minutes per entry, with the option to drill into linked tools for deeper engagement.
Totality lens · 32 points to ponder · 16 user POV + 16 developer POV · this tool
User POV — for the practitioner using this tool
Eight dimensions
1 · Possibility
A founder seeking advisory input can in principle access the async-office-hours archive of 200+ founder-advisor exchanges across 60+ topic clusters, with searchable transcripts and related-question linking. The full envelope spans early-stage capital, hiring + team-formation, product-market-fit signals, fundraising mechanics, founder-mental-health, exit-conversation timing, and other recurring topics. Most founders use it as one-off reference; few use it as a structured ongoing input.
2 · Plausibility
A founder consulting the archive 1-2 times per month can realistically substitute 30-50 percent of the value of paid-advisor sessions on the topics where the archive has dense coverage. The archive does not substitute for live advisory on company-specific tactics; it substitutes for general-pattern advisory which is where most paid-advisor time gets spent on entry-level questions answerable from pattern alone.
3 · Probability
Of founders who use the archive consistently (1-2 monthly check-ins), perhaps 70-80 percent report material value through year one of operating. The remaining 20-30 percent prefer live conversation and use the archive primarily as preparation for live sessions rather than substitute. Both usage patterns work; the worst outcome is bookmarking the archive and never returning to it after the first session.
4 · What works
What works: searching by specific question-pattern not by topic-cluster (more precise matching); reading 3-5 related entries before committing to one approach; checking the date of each exchange (advisor patterns evolve over time; older entries may apply differently now); cross-referencing with peer-founder conversation; treating archive-content as one input not the verdict.
5 · What doesn't work
What does not work: searching by topic-cluster only (returns too many entries; user-fatigue causes premature decisions); reading one entry and treating it as universal answer (advisor patterns vary by context); using archive in place of all advisory (live conversation has no substitute for company-specific nuance); ignoring entry-dates (some advice ages poorly).
6 · Common pitfall
The most common pitfall is reading one well-articulated entry and treating it as the answer. Async archives by their nature show one perspective per entry; the synthesis across 5-10 entries on the same question reveals the actual pattern. Founders who read the first compelling entry and stop usually misapply the advice to their context because they missed the pattern variation across cases.
7 · Counter-intuitive insight
Counter-intuitively, the highest-value entries are often not the longest detailed ones but the brief sharply-worded ones. A 200-word entry that captures a key principle generalises across more contexts than a 2,000-word entry deeply specific to one case. Length correlates poorly with applicability; conceptual sharpness correlates strongly.
8 · Highest-leverage move
The single highest-leverage move at the async-office-hours stage is to read 5-10 entries on a specific question across the full date-range of the archive (oldest to newest), identify the pattern across them, and apply the synthesised pattern rather than any individual entry. This synthesis-across-cases approach extracts more value from the archive than reading individual entries however carefully.
Eight user intents
9 · Who gains most
Founders seeking general-pattern advisory between live-advisor sessions, founders who lack access to live advisors (geography or stage constraints), portfolio-operating-partners building reference libraries for portfolio companies, MBA-students studying entrepreneurship via case-pattern. Particularly relevant for solo or remote founders without dense peer-advisor networks.
10 · Irreducible essence
The irreducible essence: search by specific question not topic-cluster, read 5-10 related entries across the date-range, synthesise pattern across cases, apply pattern not individual entry, treat as one input alongside peer-conversation and live advisory.
11 · Optimal timing
Best applied at 1-2-monthly cadence for ongoing pattern-input. Acute applicability: pre-major-decision (read 5-10 relevant entries before deciding), post-major-event (read entries on similar post-event scenarios), pre-live-advisor-session (use archive to formulate sharper questions for the live session).
12 · Where it matters most
Geography-agnostic content. Specific entries surface geography-context where relevant (e.g., fundraising mechanics differ between US, UK, India, Singapore); the archive flags geography-context per entry. Founders should weight entries from their geography-context more heavily but read across geographies for pattern-comparison.
13 · Why misunderstood
Async-office-hours is misunderstood because the asynchrony makes the archive feel less interactive than live advisory and therefore less valuable. The actual value-difference is smaller than founders assume; most live-advisor time addresses general-pattern questions that the archive answers reliably. The archive substitutes for the cheap part of live advisory while preserving live time for company-specific nuance.
14 · Highest-leverage sub-paths
Highest-leverage topic-clusters in the archive: early-stage capital + investor-conversation tactics (highest-volume queries), hiring-first-employees + early-team-formation, product-market-fit signals + pivot timing, founder-mental-health + sustainable-pace, cofounder-conflict + cofounder-departure, runway-extension during downturn, board-management. Other clusters covered but less densely.
15 · Whose advice to trust
Trust: established founder-advisors with track-records (advisor-byline visible per entry), pattern-synthesis across multiple entries on same topic, peer-founder feedback on which entries proved actionable. Ignore: single-entry-as-universal-answer impulse, advisor-bylines without verifiable track-record, entries 5+ years old without recency-check.
16 · How to proceed differently
Proceed by formulating your question precisely, searching the archive with that question, reading the top 5-10 entries by relevance and date-range, identifying the pattern across them, drafting your applied-pattern decision, validating with one peer-founder or live-advisor before committing. Treat archive as preparation-tool not decision-tool.
Developer POV — for the architect, maintainer, AI tool, future contributor
Eight dev dimensions
17 · Data architecture
Async-office-hours composes from data/atlas-async-office-hours.php (200+ entries with question + answer + advisor-byline + topic-tags + geography-context + entry-date), data/sub-verticals.php (for vertical-context filtering), and includes/atlas-async-office-hours-engine.php (the search/filter/related-entry engine). Single-file render; deterministic; pure PHP.
18 · Schema markup
CollectionPage on the toolkit page (the page is a collection of Q&A entries); QAPage schema for each individual entry; Question + AcceptedAnswer arrays nested. Per-topic-cluster pages emit ItemList of QAPage. The search functionality emits SearchAction schema via WebSite root.
19 · Internal linking
Forward to /toolkit/founder-readiness/ and other ATLAS toolkit pages. Outward to /library/{topic-slug}/, /entries/{slug}/. Cross-content injector tokens: "advisor", "founder-question", "Q-and-A", "office-hours". Link weaver hyperlinks advisor-bylines + topic-cluster names automatically.
20 · Page-speed posture
Payload ~22 KB for the toolkit landing page (filter + search + featured entries). Render ~250-450 ms. Search functionality is server-side (PHP filter on slug + topic + question-tokens); no client-side JS search to keep payload small. The 200-entry archive is loaded server-side and filtered before rendering.
21 · Mobile UX
Search-input renders prominently at top with native <input type="search">. Filter-clusters render as <details> elements (collapsed by default on mobile; expanded on desktop). Entry-cards as semantic <article> with proper heading hierarchy. Tap-targets ≥48px. Native HTML throughout.
22 · Accessibility
Search uses native <form> + <input type="search"> + <button type="submit"> with proper labels. Filter-cluster <details> elements give keyboard-accessible expand/collapse for free. Entry-cards as <article> with <h3> headings + readable typography. Color contrast AAA body / AA tags. Focus-visible outline.
23 · SEO saturation
URL: /toolkit/async-office-hours/. Per-entry URL: /entries/{slug}/. Per-topic-cluster URL: /entries/topics/{topic-slug}/. Canonical per page. Sitemap inclusion: /sitemap-fragments/atlas-toolkit.xml + /sitemap-fragments/entries.xml. IndexNow on edit. Schema CollectionPage + QAPage per entry.
24 · Extensibility
To add a new entry: append to data/atlas-async-office-hours.php with required fields (slug, question, answer, advisor_byline, topic_tags[], geography_context, date). Search + filter auto-pick up. Total ship: ~15 min per entry. Per-entry detail page auto-generates from the data.
Eight dev intents
25 · Who maintains
Joint maintenance. Entries added as advisor-conversations or written-Q-and-A produce shareable patterns. Roughly 5-10 new entries per month sustainable; peak 20+ per month around fundraising-cycles when advisor-input is densest.
26 · What tech stack
Tech: PHP 8.3 server-side filter; no client-side JS for search (per privacy-design + payload-discipline). Helpers: ajg_atlas_async_office_hours_all(), ajg_atlas_async_office_hours_by_topic(), ajg_atlas_async_office_hours_search(). No external API.
27 · When to refresh
On-demand entry addition. IndexNow on edit. Quarterly review of entry-relevance (some older entries may need recency-flagging). Annual review of topic-cluster taxonomy.
Why server-side search rather than client-side: the 200-entry archive serialises to ~150 KB JSON which would be heavy client payload; server-side PHP filter at request time keeps client payload light and avoids SEO-fingerprint mismatch (server-rendered = crawlable; client-rendered would not be).
Same ownership. Entry-content sourced from advisor-byline-attributed conversations + written Q&A. Each entry carries advisor-byline + verifiable-attribution metadata. No anonymous entries; no aggregator-scraping.
32 · How to extend
To extend with a new topic-cluster: (1) define cluster theme + 5-8 starter entries on the topic; (2) add to topic-tags taxonomy; (3) verify cluster-page renders cleanly with the starter entries; (4) iterate as more entries arrive in the cluster. Total ship: ~3-4 hours for a meaningful new cluster.