Build Philosophy
“ERP must follow the business, not the other way around.”
The Problem We’re Solving
Section titled “The Problem We’re Solving”Most business software is built by engineers, for engineers.
It solves engineering problems: data consistency, scalability, feature completeness.
Business owners don’t care about those things.
They care about one thing: does this help me run my business better?
iZ ERP is built from the opposite direction — starting with the business owner, working backward to the code.
Core Principles
Section titled “Core Principles”1. Simple UX = More Data = More Value
Section titled “1. Simple UX = More Data = More Value”The database is only useful if people actually fill it in.
If a task takes more than 10 seconds, users skip it.
If users skip it, the data is incomplete.
If the data is incomplete, the ERP is useless.
Every feature is evaluated by one test first: Can a non-technical person complete this in under 10 seconds?
2. Ship Over Perfect
Section titled “2. Ship Over Perfect”A working product beats a polished prototype.
We’d rather have something functional in users’ hands today than something perfect in 6 months.
Real feedback from real users is worth more than any internal review.
Rule: If it works and doesn’t break anything else — ship it.
3. Own The Migration Moment
Section titled “3. Own The Migration Moment”The first 10 minutes determine retention.
Our users come from Airtable, Notion, and Google Sheets.
The moment they see their own data — organized, in a real pipeline — is the product moment.
That moment must work perfectly.
Everything else is secondary.
4. AI Is The Interface, Not The Feature
Section titled “4. AI Is The Interface, Not The Feature”AI is not a chatbot you add at the end. It’s how the whole system is designed.
Every entity, every API, every workflow is designed to be readable and usable by AI tools.
The .agent/ directory isn’t documentation — it’s a first-class part of the product.
Users don’t customize via settings panels.
Users describe what they want in plain language, and the system does it.
5. The Core Must Be Indestructible
Section titled “5. The Core Must Be Indestructible”Community trust is built on stability.
The core engine (core/schema/, core/engine/, core/api/v1/) follows strict rules:
- No breaking changes. Ever. Version instead.
- Zod validation on all database output.
- Soft delete only — data is never destroyed.
- Sequential migrations — no schema drift.
Extensions and modules build on top of the core. They never reach inside it.
This is how we build a community without a WordPress-style security nightmare.
6. Vertical Depth Over Horizontal Coverage
Section titled “6. Vertical Depth Over Horizontal Coverage”A tool that does 3 things perfectly is worth more than a tool that does 30 things adequately.
We don’t try to be an ERP for every business.
We go deep on one vertical at a time — starting with agencies and freelancers — until we’re the obvious best choice for that group.
Then we move to the next.
7. Revenue Enables Mission
Section titled “7. Revenue Enables Mission”Free software built by a burned-out solo developer helps nobody.
We monetize from day one — through templates, managed hosting, and eventually support contracts.
Not to get rich. To stay alive long enough to build something that matters.
Rule: Every sprint must have a path to the next dollar.
8. Data Belongs To The User
Section titled “8. Data Belongs To The User”We are stewards, not owners.
MIT license.
PostgreSQL — no proprietary format.
Export anytime, no paywalls.
No analytics, no telemetry, no surveillance.
If you want to leave, we make it easy.
That’s why people trust us enough to stay.
What We Build Toward
Section titled “What We Build Toward”A CRM/ERP where a business owner can:
- Import their data from wherever it lives today
- Have a working pipeline in under 10 minutes
- Ask an AI to customize it for their industry
- Run their business without needing an IT team — ever
Not the most features. Not the biggest ecosystem.
The right tool, for the right person, at the right moment.
This document is a living contract — between the team, the community, and our users.
When we’re unsure what to build next, we come back here.