Sara Du founded Ando, a team messaging platform designed for human-agent collaboration, after spending 5.5 years building Alloy (an API integration platform) starting at age 19; she raised $20M across two rounds as a solo founder before fully nailing down the product direction, and the company is now a year in with an early alpha of 100+ users across 14-15 countries.
Motivations shifted from chasing milestones to finding a problem worth a decade
At 19, she started Alloy because “everyone who’s ambitious starts a venture-backed company” without understanding her own why; she chased incremental milestones (raising amounts, closing contracts) rather than a core purpose.
After Alloy, she took ~a year off and realized she needs “problems to chew on” like a dog with a bone; she now frames motivation as finding something worth 10+ years where good work begets more work.
She learned she had picked a market (enterprise sales-led) that didn’t fit her personality: she disliked flying to meet strangers who didn’t want to talk, while she naturally attracted people through writing and Twitter — she’s a marketer, not a salesperson.
The initial escape velocity of a company must come from work the founder genuinely enjoys; she now filters markets by “market-personality fit” (patience for sales vs. preference for content, unique advantages in addiction to certain problem types).
MCP and agent tool use revealed the Ando opportunity
In late 2024, MCP (Model Context Protocol) launched; her Alloy background in API integrations made her immediately see its significance for agent tool use.
While consulting and building early MCP servers, every client wanted agents inside Slack — but Slack’s architecture treats agents as apps installed on top of a human-centric platform, not as first-class coworkers.
She concluded no one else would build this “the right way” because team messaging platforms require immense patience to build; most founders chase quick AI money instead of the long platform play.
Incumbents (Slack, Teams) aren’t moving fast enough for an agent-dominated workforce; the opportunity doesn’t look obvious now because “Slack works great” is the surface perception, but the underlying architecture fails agents.
Ando’s core belief: agents are coworkers, not tools
Most platforms treat agents as installable apps; Ando treats them as colleagues you invite and onboard — they join channels like humans, have access to context packaged for them, and can proactively contribute.
The team studies philosophy (consciousness, language evolution, human-machine boundaries) to inform product decisions; they host monthly reading sessions on early 1900s texts that are newly relevant.
Example UX detail: agents can “squish” verbose output for human readability while retaining full context themselves — a translator layer for agent-to-human communication.
Etiquette system: workspaces have overarching style, channels have specific norms, agents adapt tone per interlocutor (e.g., formal with managers, casual with peers) — agents develop their own slang and style over time.
Why agents fail in Slack: the “locked office building” analogy
Slack was built 15 years ago for humans; agents live on the app platform as a tacked-on layer — first encounter is “install a coworker,” which is the wrong mental model.
Data model inequality: agents can’t join channels, create group DMs, sidebar, or access context locked in “file cabinets” — they’re dropped into a building without the right limbs or keys.
Humans give agents little context then berate them for poor results; Ando packages context (etiquette, channel purpose, permissions) so agents understand what’s happening from day one.
Agent onboarding: first 90 days compressed to hours/days
Agents face high pressure to be maximally helpful fast or humans lose patience; Ando removes “thinking traces” UI (spinners, step-by-step logs) that make humans impatient — puts agents on even footing with human colleagues.
Humans must have calibrated expectations: agents need a few hours/days to “boot up” with context, then become extremely helpful; visual/interface design bridges the trust gap.
Human-to-human trust is slow to build but resilient once established; human-to-agent trust is fast to lose and fragile — interfaces must actively bridge this gap.
Specialist vs. generalist agents: a human trust issue, not technical
Ando is unopinionated as a platform — teams bring their own agents; they host a cloud agent harness but optimize for coordination via messaging.
Personally, she believes one high-IQ/EQ agent could technically do everything (permissions, context separation), but humans need identity separation for trust: “I don’t want to talk to the same agent about Rippling salaries and Linear tickets.”
This is a sociological holdover; trust speed hasn’t changed, and humans are bad at conveying precise parameters (who sees what) — org gossip/leaks are features, not bugs, making single-agent trust unlikely soon.
Humans are intolerant of agent mistakes vs. human mistakes: human trust is slow to gain but resilient; agent trust is fast to lose and brittle — visual design helps bridge this.
Bearish on interfaces except where humans coordinate (messaging)
Many apps (Jira, Linear) will become agent harnesses where interface matters less — past/present-facing tools (GitHub, Linear) don’t need human UI if agents execute.
Messaging is future-facing (where we “talk things into existence” — planning, coordination); it’s one of the last human-facing software categories where interface matters deeply.
Mobile will be voice-first but distinct from desktop; she prefers text input for reasoning (writing clarifies thought), voice for capture — voice-to-text should be a starting point, not endpoint.
Writing culture is an advantage: Ando requires human-written RFCs (intent) before building; agents write PRDs but humans must articulate intent first — reasoning over tokens remains valuable.
Agents also benefit from diagramming then “looking at” the diagram — it improves their reasoning, similar to humans.
Building Ando: more like a game than B2B SaaS
Surprise 1: endless idiosyncratic feature requests (e.g., “swipe between messages”) — must build lowest common denominator for team use, not custom skins per user.
Surprise 2: human feeling matters enormously — messaging platforms are built by gaming founders (Discord, Slack origins) because it’s about how humans feel moving through screens, not standard B2B logic.
LLMs struggle to simulate human emotional response to UI sequences; this is where human designers/builders retain edge.
Background: Georgia, self-taught code at 15, SF at 17
Grew up rural Georgia (2 hrs north of Atlanta), bored, read heavily, played three sports (golf, basketball, swim) — learned patience/precision from golf, team execution from basketball, solitude/endurance from swim.
Brother went to coding camp; jealousy drove her to teach herself from his books at 15; found online challenge sites with bounties, made money, built Twitter following at 16, discovered VC/startup world.
Came to SF at 17 (Thiel Fellowship adjacent), left for NYC, returned — loves the “build and chase dopamine of doing something productive” lifestyle.
Hiring as solo founder: attract, don’t chase; contract-to-hire
Solo founders distribute time across teammates vs. locking up with a co-founder; values alignment is critical — she markets the problem/product visibly so right people find her (inbound > outbound).
Over half the team were known: one worked 4+ years at Alloy, one was a founder neighbor she stayed in touch with, one she DM’d after following on Twitter.
Contract-to-hire is preferred: mutual vetting, more signal, “nerd snipes” people who can’t step away once they start — if they’re not nerd-sniped, they weren’t a fit.
Standard hiring is transactional (dating apps for jobs); contracting lets people dip in, care organically, then convert — requires good infra for provisioning/deprovisioning so departures aren’t dramatic.
Extreme minimalism in hiring; pre-PMF focus on rate of learning
Post-Alloy, she became an “extreme minimalist” on hiring: raising money creates itch to deploy capital into headcount, but pre-PMF, more people = more cooks, slower learning.
Pre-PMF, only rate of learning matters; small teams iterate faster on core activation metrics.
Culture emerges from founder + early teammates: she frontloads values alignment (intellectual dinners, philosophy discussions), selects people who amplify desired traits.
Example: teammates are athletic, got her on Whoop, snuck electrolytes into her water — HRV improved; culture carries forward when new people pick up traditions (hosting dinners, health rituals).
Intentional about rituals before hiring: what do you do together regularly? Hard to introduce later.
Building long-term through hype cycles: urgency toward value, not vanity
Must love the daily act of working on the problem; time passes quickly when obsessed — hockey stick growth is an abstract chase, loving the work is a different feeling.
Family background in academia (multi-decade problem focus) shaped her time horizon; selects for teammates who see beyond short-term Twitter hype, are truth-seeking about tech reality.
Urgency exists but directed at getting the right thing to customers, not proving growth to investors — “we want this to exist for people pushing technology forward.”
Analogous to aging wine: some markets (human trust, deep infrastructure) require time to build properly; shipping sloppy loses the best customers permanently (cites Docmost founder Philip: 8-12 months heads down, now used by Airbus/governments).
Bear case for solo founding: no one to bounce sensitive ideas off
Solo founders overthink; even smart outsiders lack full context for sensitive/strategic decisions — no true thought partner for high-stakes calls.
Loneliness isn’t the main issue (most solo founders tolerate it); it’s the absence of a context-rich sounding board.
She hired first employee several months in; pre-hire, personal time management and avoiding unproductive rabbit holes is a critical art.
Bull case for solo founding: companies have souls; you can listen and adapt
Companies are entities with souls; solo founders can listen to what the company needs as it grows and adapt themselves — or choose a co-founder later who fits the evolving puzzle piece.
With two first-time co-founders, ego/personality friction dominates (65% of failures are people issues, often just between co-founders); solo avoids this at the start.
Truest to building a company: adapt yourself to what the company needs as leader, rather than forcing a static co-founder dynamic.
Culture building as solo founder: emergent but intentional
Culture emanates from founder; early teammates amplify chosen traits — select for people who carry the rituals you want (intellectual salons, health habits, writing culture).
Worth defining recurring structures before first hire: what do you do together weekly/monthly? Hard to start traditions after multiple people join.
Emergent culture from teammates becomes the real culture — founder sets initial vector, team carries and evolves it.
