We have scoped dozens of custom AI projects at Nivorius. The pattern is consistent: companies that spend the first four weeks getting the scope right ship faster, stay under budget, and hit their learning or business outcomes. Companies that rush to code in week one almost always blow up in month three. The problem is not the engineering. It is the scoping.
Week One: Define the Decision, Not the Feature
The first mistake is writing a feature list. The first week should answer one question: what decision does this AI help someone make better? The answer is never 'the model generates content.' It is 'the teacher knows which learner needs help' or 'the parent gets a learning plan.' Start with the decision, work backward to the data, then forward to the interface.
- Identify who makes the decision — teacher, parent, student, administrator
- Define what a good decision looks like — specificity matters. Not 'better learning' but 'the learner masters fraction addition before the unit test'
- Find the signal — what data proves the decision was right? Time to mastery, assessment score, engagement, retention?
This week produces a one-page decision brief. If you cannot fit the decision, the signal, and the user on one page, the project is not ready.
Week Two: Map the Data, Not the Architecture
The second week is for data archaeology. What data exists today, what is missing, and what would need to be collected? Most education companies discover they have far less usable data than they thought. The model is not the hard part — the data pipeline is.
- List every data source that informs the decision — LMS logs, assessment results, interaction data, content metadata, user profiles
- Identify gaps — what signals exist in theory but not in practice?
- Check data quality — consistency, completeness, freshness. Garbage data produces garbage predictions.
This week produces a data inventory document. It is ugly. That is fine. The goal is to see reality, not a polished story.
Week Three: Prototype the Signal, Not the Product
Week three is for rapid prototyping — but not of the full product. Build a narrow prototype that tests the signal, not the interface. Can you actually predict what you said you would predict? Use existing tools, manual processes, or simple scripts. The point is to validate the core hypothesis before building infrastructure.
- Pick the highest-leverage prediction — the one that, if wrong, kills the project
- Test it on a small sample — twenty examples, not ten thousand
- Measure accuracy against the signal you defined in week one
If the signal cannot be predicted with a simple model, a complex model will not save it.
This week produces a prototype report: what worked, what did not, and what needs to change. Most projects pivot at least once.
Week Four: Write the Scope, Not the Contract
The fourth week turns the previous three into a scope document that fits on two pages. It includes the decision, the data inventory, the prototype results, and the out-of-scope list. The out-of-scope list is the most important part — it is where scope creep goes to die.
- In scope: the specific decision, the data feeding it, the interface for the specific user
- Out of scope: everything else. Personalization, multi-language, analytics dashboards, integrations — all out until the core works
- Success metric: the single metric that proves the decision is better with AI than without it
This document is what gets shared with engineering, shared with stakeholders, and referenced when decisions come up. If it cannot survive a meeting, the scope is too broad.
What Goes Wrong
Four-week scoping is not a magic process. The most common failures:
- Starting with features instead of decisions — results in a feature list that grows until the project collapses under its own weight
- Skipping the data inventory — builds on assumptions about data that do not exist or are not accessible
- Building the full product in the prototype — wastes time on infrastructure for a hypothesis that may be wrong
- No out-of-scope list — the project grows by accretion until no one remembers what the original goal was
At Nivorius, we use this four-week scoping process for every custom AI project. The result is not a perfect plan — it is a testable hypothesis with a clear scope boundary. That is what separates projects that ship from projects that linger in development hell.
Part of the Nivorius research and consulting team, focused on practical applications of AI in education and enterprise contexts.
