Founding Engineer, Generalizable Data Platform Small Business

Founding Engineer, Generalizable Data Platform for Small Business

Our client is building a data platform for small businesses that starts in accounting, but is not limited to it. Small businesses now run on dozens of disconnected tools—accounting, banking, payments, payroll, POS, e-commerce, CRM, project management, and more—each holding a fragment of the truth with its own schema, reporting, and blind spots. Integrations aren’t new, but they mostly shuttle data between silos instead of creating a single, coherent view of the business that non‑technical people can actually use.

They’re building a data platform for small businesses, a unified and generalizable model that brings all these sources under one roof. To make them explorable in human terms, aiming to do for small businesses in the age of AI what Snowflake has done for enterprises—only designed from day one for accountants, operators, and owners rather than data engineers.

The core bet is that you can represent any small business — from a coffee shop to a SaaS company to a clinic — on a shared, generalizable data model
. That model has to be rich enough to capture operations, economics, and financials, yet structured enough that you can query it like a warehouse and navigable enough that AI can reason over it as a graph.

Think of it as “Snowflake for small businesses” with an opinionated semantic layer on top: a universal schema and ontology that makes it possible to ask consistent questions across thousands of heterogeneous businesses.

As a founding engineer, you’ll design and implement this model and the systems around it: the event‑centric core
, the semantic abstractions
, and the infrastructure that makes it reliable and evolvable over time. Over time, you will also build and lead the engineering team around this platform
, creating leverage far beyond your individual output.

1. A common event model across many types of businesses

• Design an event‑centric representation that can ingest inputs from banking, payments, payroll, ERPs, CRMs, commerce, and more into a consistent structure.

• Treat business activity of events with clear identities, relationships, and time semantics (including “what happened” vs. “when we learned about it”).

2. A generalizable semantic layer (“physics of small business”)

• Help define a shared set of concepts and relationships that can describe very different businesses without per‑vertical rewrites.

• Encode how operational activity, efficiency, unit economics, and financial outcomes relate, so that the same question — for example, “What is the payback on this channel?” — can be expressed once and answered across many customers.

3. A warehouse‑grade storage and querying surface

• Build the infrastructure that makes this model usable like a warehouse: partitioning, indexing, multi‑tenant isolation, and performance under analytical workloads.

• Design schemas and access patterns that support multiple query surfaces
  , including:

  • Direct SQL for internal analytics and power users

  • NL→SQL for non‑experts and ad‑hoc questions over tabular views

  • Derived graph and API layers that sit on top of the same underlying model

4. A graph‑ and knowledge‑driven platform for AI

• Shape how we represent, store, and query the knowledge graph so that AI systems can walk the graph directly, using structure (nodes, edges, constraints) as a first‑class reasoning surface.

• Define how this graph connects to warehouses, indices, and vector stores so we can support both graph traversal and more traditional analytical workloads from the same semantic core.

5. A pragmatic AI‑aware architecture

• Decide how to expose the semantics of the model to different AI interfaces: graph traversal APIs, retrieval layers, and NL→SQL, without giving up guarantees around correctness and traceability.

• Define boundaries between structured computation (SQL, graph traversal, deterministic transforms) and model‑driven behavior (classification, normalization, suggestion) in a way that is extensible as capabilities improve.

6. Guardrails and evolution for a long‑lived schema

• Set principles for how schemas and ontologies change over time: versioning, migrations, compatibility, and…