Building for 41 Views, Not 41 Products: Graph-First Architecture | AI PM Portfolio

Building for 41 Views, Not 41 Products: Graph-First Architecture

March 20, 2026 · 18 min read · Architecture / Product Strategy

The most consequential architectural decision in my career was not choosing a model, a framework, or a database. It was realizing that one knowledge graph with 12 interconnected nodes can power 41 user-facing views -- without building 41 separate products. The graph-first pattern means every piece of data added to any node enriches every view that touches it. It creates a compounding moat that grows with every user interaction. This is how Rippling, Palantir, and the next generation of AI platforms are built.

What is the problem with building products one at a time?

The default approach to building a multi-product company is straightforward: build Product 1, then Product 2, then Product 3. Each product has its own data model, its own backend, its own user experience. This is how most SaaS companies scale. It works. And it creates a compounding problem that becomes visible only at product number 5 or 6.

The problem: data silos. Product 1 knows your tax situation. Product 2 knows your visa status. Product 3 knows your salary history. But no product knows all three -- and the most valuable insights sit at the intersection. Your visa status affects your tax obligations. Your salary history affects your home affordability. Your tax situation affects your investment strategy. According to a 2024 analysis by Bain & Company, companies with integrated data architectures generate 2.6x more cross-sell revenue than companies with siloed product data.

I learned this lesson the hard way. At a YC-backed tax-tech startup, we built a tax filing product, then a document analysis product, then a client intelligence product. Each was valuable independently. But when a user asked "How does my visa change affect my taxes and my home purchase timeline?" -- a question that spanned three products -- no single product could answer it. The data existed across three separate models. Joining them required custom queries that broke every time any model changed. [LINK:post-24]

That experience catalyzed the architectural insight: do not build 41 products. Build 1 graph. Expose 41 views.

What does graph-first architecture actually look like?

Graph-first architecture starts with a single data model that represents the full domain as interconnected nodes and edges. In our case -- building an AI platform for immigrants -- the graph has 12 node types that capture the full complexity of an immigrant's life in the United States.

The key insight: no node exists in isolation. Every node connects to at least 3 others. When a user updates their visa status (Visa node), that change ripples through Career (visa-dependent employment authorization), Tax (residency implications), Travel (re-entry considerations), and Documents (new documents needed). One user action triggers enrichment across 4-5 nodes automatically.

How is graph-first different from a traditional monolith or microservices?

The most important row is "Time to 10th product." In a siloed architecture, building your 10th product takes roughly the same effort as building your 2nd. In graph-first, your 10th view is dramatically cheaper than your 2nd because 80% of the data infrastructure already exists. According to our internal estimates, our first 6 views required 70% of the total graph infrastructure investment. Views 7 through 41 share the remaining 30%. The marginal cost of a new view approaches zero as the graph matures.

What makes the graph a defensible moat?

Three properties of graph-first architecture create compounding defensibility:

Property 1: Shared enrichment

When a user uploads a W-2 (Documents node), the extraction enriches not just the Documents node but also Career (employer, salary), Tax (withholdings, deductions), and Money (income history). One document, four nodes enriched. A competitor who builds tax filing as a standalone product would only enrich the Tax node. They would need the user to manually enter the information that our graph extracts automatically. [LINK:post-35]

According to a 2025 analysis by Sequoia Capital, companies with shared data enrichment (where one user action enriches multiple product surfaces) achieve 3.1x higher per-user engagement compared to companies with siloed enrichment. The graph makes shared enrichment automatic rather than engineered.

Property 2: Confidence scoring and temporal versioning

Every field in our graph carries metadata: source (where the data came from), confidence (how reliable it is), valid_at and invalid_at timestamps (when it was true), and decay rate (how quickly its reliability diminishes). A salary figure from a W-2 uploaded yesterday has high confidence. A salary figure mentioned in a chat conversation 6 months ago has lower confidence. The graph knows the difference.

This per-field confidence model means the AI can reason about data quality, not just data values. When a user asks "Can I afford a $800K house?", the AI knows that their salary data is high-confidence (from a recent W-2) but their savings data is medium-confidence (mentioned in a chat 3 months ago, decayed). It can ask for updated savings information before giving an answer. No siloed product has this capability because no siloed product tracks cross-domain data confidence.

Property 3: The ripple engine

When data changes in one node, the ripple engine propagates that change through connected nodes using a directed acyclic graph (DAG) traversal with topological sort. When a user's visa status changes from H-1B to green card, the ripple engine automatically updates: Tax node (residency status changes tax obligations), Career node (employment authorization changes), Travel node (re-entry requirements change), and Insurance node (eligibility for certain programs changes). All of this happens in a single database transaction.

Ripple: Visa status change → [Tax: residency] + [Career: authorization] + [Travel: re-entry] + [Insurance: eligibility] One event → 4 nodes updated → 11 views refreshed → 0 user actions required

The ripple engine creates the feeling of an AI that "understands your whole situation." Users do not see the graph. They see a tax view that automatically reflects their visa change, or a home affordability calculator that updates when they report a salary increase. The graph is invisible. The intelligence it enables is not.

What does the 41 views taxonomy look like?

The 41 views fall into 11 modules plus a platform layer. Each view is a specific user-facing experience powered by a subset of graph nodes. The views range from simple (single-node lookups like Salary Lookup) to complex (multi-node reasoning like Tax Filing, which touches Person, Career, Tax, Family, Documents, Home, Business, and Money).

The taxonomy follows a deliberate priority structure. According to our user research across 1,885 interactions, 6 views (the A-tier) account for 60% of user engagement and revenue. 8 views (B-tier) account for 30%. The remaining 27 views (C-tier) account for 10%. The A-tier views are fully polished. The C-tier views are functional but minimal -- they exist because the graph makes them nearly free to build, not because they justify standalone investment. [LINK:post-47]

The 41-view insight: Most of the 41 views would not justify standalone products. A "Residency Day Calculator" that tracks days inside and outside the United States is not a product anyone would build independently. But as a view on the graph -- pulling from Person, Travel, and Visa nodes -- it costs effectively nothing to create and provides real value for users navigating immigration rules. The graph turns marginal features into free features.

How do you build a graph-first architecture without over-engineering?

The biggest risk of graph-first architecture is premature abstraction. If you design the full 12-node graph before shipping anything, you will spend 6 months on architecture and ship nothing. Here is the pragmatic approach:

Phase 1: Build the core triangle. Every domain has 3-4 nodes that participate in 80% of queries. For us: Person, Tax, Documents. Build those first with full confidence scoring and temporal versioning. Ship the first 3-4 views on this foundation.

Phase 2: Expand by user demand. When users ask questions that require nodes you have not built, that is the signal to expand. We added Career after users asked "How does my job change affect my taxes?" We added Visa after users asked "Does my visa status change my filing requirements?" Demand-driven expansion prevents over-engineering.

Phase 3: Enable the ripple engine. Only after 6+ nodes are in production should you build cross-node propagation. The ripple engine's value scales with graph density. With 3 nodes, ripples are trivial. With 8+ nodes, they become magical.

According to our build timeline, Phase 1 took 8 weeks. Phase 2 took 12 weeks (adding 5 nodes). Phase 3 took 4 weeks. Total: 24 weeks from first line of code to a functioning 8-node graph with ripple propagation. Not fast, but not the multi-year enterprise project that "knowledge graph" often implies. [LINK:post-37]

Why does graph-first architecture matter for AI specifically?

The graph is not just a data architecture. It is an AI context architecture. When an AI agent needs to answer a user question, the quality of its answer depends entirely on the context it can access. In a siloed architecture, the AI for Product 1 only knows Product 1's data. In graph-first, the AI has access to the full graph -- every node, every edge, every confidence score, every temporal version.

This matters because the most valuable AI responses require cross-domain reasoning. "Should I file my taxes as married filing jointly or separately?" requires Tax, Career (both spouses), Family, and Money nodes. "When should I buy a house?" requires Home, Career, Visa, Tax, and Money nodes. The graph gives the AI the context to answer these questions. Siloed products cannot. [LINK:post-48]

According to a 2025 study by researchers at UC Berkeley, AI agents with access to structured, cross-domain context completed complex multi-step tasks 47% more often than agents with equivalent capabilities but domain-siloed context. The graph is the structured, cross-domain context.

Frequently Asked Questions

Do you need a graph database like Neo4j for graph-first architecture?

No. We use PostgreSQL (via Supabase) -- a relational database. Our graph has 12 known node types with known relationships. That is a relational schema, not a graph database use case. Graph databases like Neo4j excel when you have unknown or dynamic relationship types, or when you need recursive traversal of arbitrary depth. If your domain has a fixed schema with well-defined node types, a relational database with proper foreign keys and indexes is simpler, faster, and cheaper. We evaluated Neo4j and Convex. PostgreSQL won because the graph structure was known and the query patterns were predictable.

How do you prevent the graph from becoming an unmanageable monolith?

Three boundaries: (1) Each node has a clear owner -- one team or one developer responsible for its schema, enrichment, and data quality. (2) Views only read from the graph through a query layer, never write directly. Writes go through node-specific APIs with validation. (3) The ripple engine has circuit breakers -- if a ripple would update more than 5 nodes in a single transaction, it pauses for human review. These boundaries keep the graph maintainable as it grows.

What is the minimum viable graph?

Three nodes connected by at least two edges, with confidence scoring on every field. That is enough to demonstrate the core pattern: shared enrichment, cross-node AI context, and the beginning of ripple propagation. Do not build 12 nodes before shipping. Build 3, ship, learn, expand. The minimum viable graph should power your first 2-3 views and take 6-8 weeks to build.

How does graph-first architecture affect hiring?

It changes the profile you hire for. In siloed architecture, you hire product engineers who own end-to-end features. In graph-first, you hire graph engineers who own nodes and data quality, plus view engineers who build user-facing experiences on top of the graph. The distinction is important because the skills are different: graph engineers care about schema design, data confidence, and enrichment pipelines. View engineers care about UI, user experience, and presentation logic. Mixing the two roles leads to either an under-designed graph or an over-engineered UI.

Published March 20, 2026. Based on the author's experience designing a 12-node knowledge graph architecture that powers 41 user-facing views for an AI-first consumer platform, informed by production patterns at YC-backed startups and enterprise-scale AI systems.