Geni.com / Yammer / MyHeritage · 2007 – 2013
Geni — one shared family tree for humanity
Building one of the earliest internet-scale social platforms—and the Newsfeed, localization, developer, billing, and messaging systems that enabled it to grow.
Role: Senior Software Engineer
- Internet-scale platforms
- Activity feeds
- Localization
Origin
The story
When I joined Geni, social networking was still in its early days. Facebook had only recently expanded beyond universities. Twitter was beginning to change online conversations. Stripe did not exist, OAuth 2.0 had not become the standard, and Ruby on Rails was still considered an emerging framework.
Geni’s vision was unlike anything else at the time: Everyone is related. The goal was not simply to build another social network. It was to build one shared family tree for humanity—every person, relationship, and generation connected together.
That vision immediately resonated with me. Long before Geni, I had researched my own family history using MediaWiki and custom plugins I built myself. When my longtime friend Andrew Arrow told me that David Sacks had this ambitious idea of connecting the world’s family tree, I submitted my resignation at SOA Software and joined almost immediately.
At Geni, I found myself repeatedly turning difficult product capabilities into reusable platforms: activity feeds, structured localization, developer APIs, authentication, subscriptions, payments, notifications, and transactional email.
Looking back, it became one of the defining experiences of my career and the foundation of how I think about software architecture.
Journey
The platforms behind the family tree
Early Ruby on Rails
Geni was one of the earliest companies to fully embrace Ruby on Rails. We were not simply building applications with Rails—we were helping shape the ecosystem.
The engineering team contributed open-source libraries, presented at conferences, shared practices with the community, and demonstrated that Rails could power a large-scale consumer internet platform.
At a time when many people questioned whether Rails could scale, we were proving it in production every day.
Building platforms, not features
One of the biggest lessons I learned at Geni was that platforms outlive features. Instead of repeatedly building isolated functionality, I found myself designing systems that entire teams and products could build upon.
That pattern has followed me throughout my career. I naturally gravitate toward building platforms that enable other people to ship.
- Subscription and recurring billing infrastructure
- Public developer platform and APIs
- OAuth-based authentication
- High-scale activity feed infrastructure
- Crowdsourced localization platform
- Translation framework and internationalization tooling
- Transactional email platform
- Payment integrations
- Notification infrastructure
Reimagining the Newsfeed
The original Newsfeed concept and architecture had been created by Geni CTO Adam Pisoni. Shortly after I joined, David Sacks and Adam began exploring an internal communication tool that engineers could use to share what they were working on. That experiment eventually became Yammer.
As Adam shifted more attention toward Yammer, I took ownership of Geni’s Newsfeed platform and evolved it into the system that continues to power the product.
At first glance, a newsfeed appears simple. In practice, every action can generate a story, and every story must account for actors, targets, embedded objects, hyperlinks, permissions, formatting, localization, aggregation, caching, and delivery.
The challenge was not displaying activity. The challenge was describing it. The Newsfeed became a storytelling engine rather than a list of events.
Story aggregation was especially important. Instead of flooding people with repetitive updates, the engine grouped related activities into concise narratives while preserving access to the underlying details.
- Permission-aware stories
- Story aggregation and grouping
- Multiple actors and targets
- Embedded objects and hyperlinks
- Flexible rendering rules
- Notifications and delivery rules
- Structured localization
- Distributed caching and performance
The birth of Translation Markup Language
The Newsfeed exposed a problem that traditional localization systems could not solve. Normal translation frameworks assumed software consisted of plain strings. Our stories contained hyperlinks, embedded people and albums, grammatical gender, pluralization, variables, and nested formatting.
After many discussions with Justin Balthrop and the engineering team, I began designing what became Translation Markup Language, or TML.
Instead of translating text, we translated structured stories. The framework understood links, variables, grammatical rules, gender, plural forms, and language-specific word order while allowing translators to produce natural translations.
TML became the foundation of Geni’s localization platform, tr8n. The framework attracted significant attention after David Heinemeier Hansson shared it publicly and ultimately inspired me to spin the technology into Translation Exchange.
- Structured links and variables
- Grammatical gender
- Plural forms
- Language-specific word order
- Nested formatting
- Natural translator control
Crowdsourcing localization
Localization became a living platform rather than a one-time translation project. Instead of relying entirely on professional translators, we enabled the Geni community to translate the product collaboratively.
As Geni evolved, the community continuously improved its translations alongside it. Users translated the product into more than seventy languages.
- In-context editing
- Community translation
- Voting
- Validation workflows
- Translation memory
- Grammar rules
- Language-specific variations
The developer platform
I designed and built Geni’s public developer platform before modern developer portals became commonplace.
It gave external developers a self-service path to safely extend Geni while preserving platform consistency, authentication boundaries, and API versioning.
- Application registration
- API credentials
- OAuth authentication
- Interactive API testing
- Version management
- Developer documentation
- Third-party integrations
Payments before Stripe
Subscription billing presented another foundational challenge. Stripe did not exist, so recurring billing, lifecycle management, free trials, payment recovery, and provider differences had to be engineered directly.
I architected Geni’s subscription platform around Authorize.net, PayPal, and ActiveMerchant. Many capabilities developers now receive from managed billing platforms had to be built and operated from scratch.
- Recurring subscriptions
- Free trials
- Subscription lifecycle management
- Payment recovery
- Multiple payment providers
- Transaction history
Messaging infrastructure
Communication became another reusable platform. I designed Geni’s email infrastructure to support high-volume, personalized communication across product and account lifecycles.
Localization and template management were part of the infrastructure itself, allowing product teams to communicate consistently without rebuilding delivery logic for every feature.
- Transactional email
- Localized templates
- Personalized messaging
- Template management
- Lifecycle communication
- Large-scale delivery
Looking back
Geni fundamentally shaped the way I think about software. It taught me that the most valuable engineering work is often not an individual feature—it is a platform that enables an ecosystem.
Many ideas I continued building through Translation Exchange, developer platforms, healthcare AI infrastructure, workflow automation, multi-agent systems, and AI orchestration can be traced back to lessons learned while building Geni.
It was not simply another startup. It became the foundation of how I think about software architecture.
Context
The problem and my role
Problem
Geni set out to build one shared family tree for humanity at a time when social networking, Ruby on Rails, OAuth, recurring billing, and large-scale activity platforms were all still emerging. The product needed a platform architecture capable of connecting people, relationships, stories, languages, developers, and commerce at internet scale.
Role
Joined Geni because its mission connected directly to my own interest in family history, then took ownership of foundational platforms across Newsfeed, localization, developer APIs, subscriptions, payments, and transactional messaging. The work ultimately shaped Translation Markup Language, tr8n, and the company that became Translation Exchange.
Constraints
- Scale a large consumer social platform on Ruby on Rails while the framework and its ecosystem were still emerging
- Represent collaborative family relationships with permissions that vary by person, object, and viewer
- Generate, aggregate, localize, cache, and distribute millions of personalized activity stories
- Express links, people, objects, gender, pluralization, and language-specific grammar inside translated stories
- Expose public APIs and OAuth authentication without weakening consistency or security
- Build recurring subscriptions, trials, payment recovery, and provider integrations before modern billing platforms existed
- Deliver personalized, localized transactional communication at very large scale
System
Architecture
System map
From social action to localized story
The Newsfeed transformed raw social activity into permission-aware, aggregated, naturally localized stories delivered to the right viewers.
- 01
Social action
A person updates the family graph, creates content, invites a relative, or collaborates on an object.
- 02
Structured event
The system records actors, targets, objects, relationships, context, and rendering metadata.
- 03
Permissions
Viewer, family relationship, object visibility, and access rules determine whether and how a story can appear.
- 04
Aggregation
Related events are grouped into concise narratives instead of flooding the feed with repetitive updates.
- 05
TML rendering
Links, variables, gender, plurals, grammar, and language-specific word order become a natural localized story.
- 06
Distributed delivery
Queues, workers, map/reduce, notifications, and caches distribute customized stories at scale.
System map
The platform architecture
The family-tree product depended on a set of reusable platforms spanning social collaboration, activity, globalization, extensibility, commerce, and communication.
- 01
Social platform
Collaborative family graph, profiles, relationships, permissions, and tree collaboration.
- 02
Activity platform
Newsfeed, story generation, aggregation, notifications, event processing, and distributed delivery.
- 03
Localization
TML, tr8n, crowdsourced translation, grammar rules, and support for more than seventy languages.
- 04
Developer platform
OAuth authentication, REST APIs, a self-service portal, versioning, documentation, and testing tools.
- 05
Commerce
Subscriptions, trials, recurring payments, payment recovery, ActiveMerchant, PayPal, and Authorize.net.
- 06
Messaging
Transactional email, localization, personalization, lifecycle communication, and template management.
Execution
What I built
- Evolved Newsfeed from an activity stream into a structured storytelling engine with actors, targets, objects, permissions, aggregation, rendering rules, and localization.
- Distributed millions of customized stories through message queues, map/reduce processing, workers, caching, and viewer-specific delivery.
- Designed TML to represent links, variables, gender, pluralization, grammar, nested formatting, and language-specific word order as structured translation data.
- Built tr8n as a crowdsourced localization platform with in-context editing, voting, validation, translation memory, and community workflows across more than seventy languages.
- Created a self-service developer platform with application registration, OAuth authentication, REST APIs, version management, documentation, and interactive testing.
- Architected recurring subscriptions, free trials, lifecycle management, payment recovery, and provider abstraction through ActiveMerchant, PayPal, and Authorize.net.
- Built reusable transactional email and notification infrastructure around localized templates, personalization, lifecycle messaging, and large-scale delivery.
- Contributed tools and practices back to the early Ruby on Rails ecosystem through open source, conference presentations, and community knowledge sharing.
Tradeoffs
Technical decisions
Model stories as structured data
- Decision
- Represent each Newsfeed story as actors, targets, objects, relationships, links, permissions, and rendering metadata instead of a prebuilt string.
- Why
- The same event needed to support different viewers, aggregation patterns, links, formats, languages, and grammatical structures.
- Tradeoff
- Structured stories require a richer schema and more sophisticated renderers than appending text to an activity log.
Aggregate related activity
- Decision
- Group compatible events into concise stories while preserving access to their underlying details.
- Why
- A useful feed should explain what changed without overwhelming people with repetitive updates.
- Tradeoff
- Aggregation rules become a product language of their own and must balance compression with clarity.
Treat localization as rendering
- Decision
- Create TML so translators work with structured stories rather than interpolated plain strings.
- Why
- Links, embedded objects, grammatical gender, plurals, and word order cannot be translated naturally by replacing variables inside English-shaped sentences.
- Tradeoff
- The translation system becomes more capable but also more complex for framework authors, tooling, and runtime evaluation.
Make localization collaborative
- Decision
- Build tr8n around in-context community translation, voting, validation, grammar rules, and translation memory.
- Why
- A global social product changes continuously; a living community can improve language coverage alongside the software.
- Tradeoff
- Crowdsourcing requires reputation, review, quality controls, moderation, and clear fallbacks.
Platformize repeated capabilities
- Decision
- Build billing, messaging, notifications, authentication, and developer access as reusable infrastructure rather than feature-specific implementations.
- Why
- Shared platforms reduce duplication, establish consistent behavior, and let future product work move faster.
- Tradeoff
- Platform work demands broader interfaces and longer-term stewardship before every future use case is known.
Abstract payment providers
- Decision
- Use ActiveMerchant around PayPal and Authorize.net instead of coupling subscription logic to one processor.
- Why
- Recurring billing needed consistent lifecycle behavior even though providers exposed different APIs and capabilities.
- Tradeoff
- A common abstraction simplifies the product layer but must still expose provider-specific failures and operational edge cases.
Create a self-service developer surface
- Decision
- Pair OAuth and REST APIs with application registration, credentials, versions, documentation, and interactive testing.
- Why
- An API becomes a platform only when external developers can discover, adopt, test, and manage integrations safely.
- Tradeoff
- A public platform creates compatibility, support, security, and versioning obligations beyond the internal product.
Value
Product impact
User impact
Helped families collaborate through expressive activity stories and use Geni naturally across more than seventy languages while giving outside developers a safe way to extend the family-tree platform.
Business impact
Created reusable activity, localization, developer, billing, payment, and messaging foundations that supported internet-scale growth, global reach, monetization, and an external ecosystem.
Results
Outcomes
- A Newsfeed storytelling platform that continues to power Geni with expressive, permission-aware, aggregated activity stories.
- Activity infrastructure capable of distributing millions of customized stories through queues, workers, map/reduce, and distributed caching.
- A community localization ecosystem that enabled Geni users to translate the product into more than seventy languages.
- Translation Markup Language and tr8n, which grew from a Newsfeed localization problem into the foundation for Translation Exchange.
- A public OAuth and REST API platform that allowed external developers to extend Geni safely.
- Reusable billing, payment, messaging, and notification platforms that supported product growth and monetization.
Reflection
Lessons learned
- “Platforms outlive features: the highest-leverage systems give entire teams and ecosystems something reliable to build upon.”
- “Complex product language should be modeled structurally; rendering and localization become more powerful when meaning is preserved as data.”
- “Internationalization is an architectural concern, not a final translation step.”
- “Community and open-source participation can extend a platform’s reach far beyond the original product.”
- “The platform pattern that began at Geni became a through-line across the rest of my career.”
Tools
Stack
Next case study
Conversational BI bot for Slack →