Founding Engineer, Generalizable Data Platform for 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 toolsaccounting banking payments payroll POS e-commerce CRM project management and moreeach holding a fragment of the truth with its own schema reporting and blind spots. Integrations arent new but they mostly shuttle data between silos instead of creating a single coherent view of the business that nontechnical people can actually use. Theyre 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 enterprisesonly 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 youll design and implement this model and the systems around it: the eventcentric 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.

What Youll Own

1. A common event model across many types of businesses

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

• Treat business activity as streams 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 pervertical 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 warehousegrade storage and querying surface

• Build the infrastructure that makes this model usable like a warehouse: partitioning indexing multitenant 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

  • NLSQL for nonexperts and adhoc questions over tabular views

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

4. A graph and knowledgedriven 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 firstclass 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 AIaware architecture

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

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

6. Guardrails and evolution for a longlived schema

• Set principles for how schemas and ontologies change over time: versioning migrations compatibility and observability when something drifts.

• Build tooling and patterns so that adding a new concept integration or vertical does not require starting over.

Leadership and Leverage

From the beginning this role is about more than your own code:

• Technical leadership

  You will be a primary voice on architecture tradeoffs and standards for the platform. Others will build on the primitives you define.

• Team building

  As we grow you will help hire onboard and develop other engineers shaping the culture and practices of the team around this data platform.

• Multiplying impact

  You will create leverage through clear abstractions documentation and tooling so that new engineers and product teams can move quickly without breaking core invariants.

• Crossfunctional leadership

  You will work closely with product design and domain experts (accountants operators) to align the model and platform with realworld needs and to translate messy requirements into crisp technical decisions.

Who You Are

• Typically 7 years of experience in systems where data modeling correctness and evolution really mattered (analytics/infra platforms financial data systems multitenant SaaS backends etc.).

• You think naturally in terms of events entities and relationships and like to design models and APIs that can support many use cases over time.

• You are excited by the idea of a shared semantic layer that works across many different kinds of businesses and the constraints that imposes.

• You blend:

  • Strong backend / dataplatform engineering

  • Careful opinionated schema and interface design

  • A practical sense for where to stop modeling and start shipping

• You care about clarity correctness and debuggability as much as raw performance. When the system says something about a business you want it to be inspectable and explainable.

• You have demonstrated leadership: mentoring others driving architectural decisions and leading projects or small teams to completion.

• You are motivated by building foundations that others can stand on and you think in terms of leverage: How do we design this so 10 more engineers can build on it without slowing down

Signals You Might Be a Strong Fit

You do not need all of these but several should resonate:

• Youve designed schemas or data models intended to support multiple products or teams not just a single feature.

• Youve worked on warehouses lakehouses or similar platforms and have opinions on partitioning multitenancy governance and query patterns.

• Youve done modeling work where the same abstraction had to fit multiple verticals or use cases without collapsing into lowestcommondenominator.

• Youve combined structured computation and ML/AI in a way that preserved guarantees about correctness and auditability.

• Youve built and led small highimpact engineering teams or been the informal tech lead others gathered around.

• You can point to specific examples where you created systems tooling or abstractions that made other engineers meaningfully more productive.

Why This Might Be the Right Problem for You

• You want to design the model not just work inside one.

  The core challenge here is deciding how the world is represented: what the primitives are what relationships exist and how that scales.

• You like hard generalization problems.

  Building a data model that works for thousands of different businesses yet remains coherent and queryable is a genuinely difficult design problem.

• You care about leverage.

  Your work will be multiplied through other engineers product teams and use cases that build on the platform you define.

• Youre early enough to shape both the system and the team.

  The abstractions schemas and infrastructure you design now will be the backbone of Entries as it grows and you will help choose and develop the people building on top of them.