Spend six months on the data schema before you ship features

The Framework

Most founders treat the data model as an implementation detail. They ship features, then patch the schema when something breaks. It feels agile. It is also why so many SaaS products hit a wall around year three: the data cannot answer the questions the founder now wants to ask.

Mark Abbott did the opposite at Ninety. Before writing the first user-facing feature, he spent six months on the data schema. Not the UI. Not the onboarding. The schema. "I spent the first, literally six months just developing the data schema."

The framework: if you have a long-term vision for the product, the data model is the load-bearing wall. Build that first. Features come after.

The 3 Steps

1. Write the long-term vision before the first sprint. Mark had been thinking about the product since 2005 and about AI inside it since 2012. By the time he wrote code in 2017, he knew where the platform was going across a five plus year horizon. Common mistake: starting to ship without a five year view, then realizing the schema cannot hold the features you want by year three.

2. Design the schema for the future, not the MVP. Mark picked MongoDB on advice, and later added a relational database alongside it. The point was not the choice of database. The point was that the data had to be able to flow across modules. "Our feedback system pulls the core values from the vision. Traction Organizer pulls your roles and accountabilities from the accountability chart. It pulls your rocks from the rock system." That integration was designed into the schema, not bolted on later.

3. Ship the foundational tools that prove the schema works. Ninety launched with the five foundational EOS tools: vision, meetings, rocks, scorecard, issues. Each one wrote to the shared schema. The product looked simple. The data underneath was already structured for everything Mark wanted to build later, including AI.

Real Numbers

Schema work: 6 months before features. Pure investment, zero customers shipped during that window.

Vision horizon: 12 years. From the original 2005 idea to the first line of code in 2017, Mark had been refining what the platform should be.

AI on the roadmap from 2012. Mark started thinking about AI five years before he wrote the first feature, and the schema was built to feed it later.

Result today: 18,500 companies, nearly $44M ARR. The AI features Mark recently shipped (the Maz companion bot that answers "what is working, what is not working" across the org) only work because the schema was designed to integrate the data from day one.

When It Fails

This framework fails when you do not actually have a long-term vision. Spending six months on schema without conviction about where the product is going just gives you an over-engineered MVP. Mark could afford the six months because his vision was already 12 years old. If you are still searching for the product, ship faster and rebuild later.

Your First Move

Block four hours this week. Write a one-page document that answers two questions. First: what is this product in five years (not six months)? Second: what data does it need to capture from day one to support that future? If you cannot answer the second question, your schema is a bet, not a foundation. Get to the answer before you ship the next feature.