Job Title

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 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. #J-18808-Ljbffr