berk.ai
← Work

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. My longtime friend Andrew Arrow—whom I had met in 1999 at Digital Evolution while he was building Warner Bros. games—convinced me to leave SOA Software and join Geni.

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.

Collaboration

People I built this with

The people behind this chapter—and the part each of them played in shaping the work.

Adam Pisoni

Co-Founder & former CTO, Yammer · Founder, Abl and Let’s Gooo

Adam designed the original Newsfeed architecture and built its Ruby map/reduce core, which he called Skynet and later presented at RailsConf. When he transitioned to Yammer, I inherited the platform and evolved it into a highly flexible story-generation, aggregation, and localization engine.

Justin Balthrop

CTO & Co-Founder, Triangle Health · Former CTO, Bird and Geni

Justin and I built tr8n together at Geni. He was also the brains behind Geni's Tree Positioning System, or TPS, creating custom graph algorithms that could perform lightning-fast searches across the global family tree. Toward the end, we explored combining TPS and tr8n so a path between any two people could become a naturally translated relationship in any language. I am not sure the experiment ever launched after we left, but it connected two of Geni's most sophisticated systems in a fascinating way.

David Sacks

Founder, Geni and Yammer · Craft Ventures Partner · All-In co-host

David's vision for Geni was simple and enormous at the same time: everyone is related. That idea shaped the product and the engineering challenges behind building a global collaborative family graph. We later worked together at Yammer as another ambitious idea grew into a company of its own.

Andrew Arrow

Principal Engineer, Andrew Arrow Dev · Early Geni, Yammer, and Bird engineer

Andrew convinced me to leave SOA Software and join Geni. When Yammer began inside Geni, he wrote some of the first implementations of the product across both web and mobile. He even built in a sound effect so every new Yammer message played his voice saying “Yum”—a detail I am sure disappeared later, but an unforgettable part of the earliest product.

Ian McDaniel

Co-Founder & Product Lead, Translation Exchange · Former Director of Product Development, Geni

Ian designed Geni's interface, and we worked closely across features including its Facebook integration and tr8n. As a founding product engineer at Yammer, he also helped design and build much of its early front-end experience. Our collaboration connected product design, user experience, and the underlying platform.

Amos Elliston

Former CTO, Geni and Flexport · Technology executive

Amos figured out the extraordinarily complex layout mechanism that allowed Geni to render a global genealogy graph containing millions of people, one family at a time. When I later needed the same capability for a mobile application, reproducing the algorithm proved so difficult that I used his API instead. His work turned a nearly intractable graph-visualization problem into reliable platform infrastructure.

Journey

The platforms behind the family tree

01

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.

02

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
03

Reimagining the Newsfeed

The original Newsfeed architecture had been created by early Geni engineer Adam Pisoni. He built its Ruby map/reduce core, called it Skynet, and later presented the system at RailsConf.

When David Sacks came up with the idea that became Yammer, Adam transitioned to the new product and eventually became its CTO. 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
04

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.

I began designing what became Translation Markup Language, or TML, and Justin Balthrop and I built the tr8n localization platform around it.

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.

Justin was also the brains behind Geni’s Tree Positioning System, or TPS. He created custom graph algorithms capable of lightning-fast searches across the global family tree—an unusually difficult problem at that scale.

Toward the end of our time there, we explored combining TPS and tr8n into a relationship translation system. Given the path coordinates between any two people, it could describe their relationship naturally in any supported language. I am not sure the experiment ever launched after we left, but it connected two of Geni’s most sophisticated systems in a fascinating way.

TML and tr8n attracted significant attention after David Heinemeier Hansson shared the framework 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
05

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
06

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
07

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
08

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
09

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.

  1. 01

    Social action

    A person updates the family graph, creates content, invites a relative, or collaborates on an object.

  2. 02

    Structured event

    The system records actors, targets, objects, relationships, context, and rendering metadata.

  3. 03

    Permissions

    Viewer, family relationship, object visibility, and access rules determine whether and how a story can appear.

  4. 04

    Aggregation

    Related events are grouped into concise narratives instead of flooding the feed with repetitive updates.

  5. 05

    TML rendering

    Links, variables, gender, plurals, grammar, and language-specific word order become a natural localized story.

  6. 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.

  1. 01

    Social platform

    Collaborative family graph, profiles, relationships, permissions, and tree collaboration.

  2. 02

    Activity platform

    Newsfeed, story generation, aggregation, notifications, event processing, and distributed delivery.

  3. 03

    Localization

    TML, tr8n, crowdsourced translation, grammar rules, and support for more than seventy languages.

  4. 04

    Developer platform

    OAuth authentication, REST APIs, a self-service portal, versioning, documentation, and testing tools.

  5. 05

    Commerce

    Subscriptions, trials, recurring payments, payment recovery, ActiveMerchant, PayPal, and Authorize.net.

  6. 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

Ruby on RailsRubyMySQLMemcachedDistributed WorkersMessage QueuesMapReduceOAuthREST APIsActiveMerchantPayPalAuthorize.netTranslation Markup Languagetr8nHigh-Scale Activity FeedsCrowdsourced LocalizationDistributed CachingEvent ProcessingTransactional Email Infrastructure