One of the most useful things I ever did on a software project looked boring from the outside.
I wrote down the rules.
Not inspirational principles.
Not a pitch-deck mission statement.
Actual working laws.
When I was helping build a startup iOS app, I managed two junior iOS developers under me. The project had enough moving parts to become messy quickly: reusable views, Firebase data, model structs, branches, pull requests, feature ownership, demos, communication habits, and all the little decisions that quietly turn into daily interruptions if nobody writes them down.
So I built a project constitution in Notion.
That sounds more dramatic than it felt at the time. It was not me standing on a desk with a powdered wig yelling about liberty and database schemas.
It was a living set of operating rules for how we were going to build.
And the surprising lesson was this:
Written rules can create autonomy.
Most beginners think rules slow a project down. Sometimes they do. Bad rules absolutely can become bureaucracy with better formatting.
But good rules do something different. They reduce the number of moments where everyone has to stop and ask, "What should I do here?"
That matters for a small software team.
It also matters when you are building with AI.
If you open Codex, Cursor, Claude, ChatGPT, or any AI coding tool and ask it to build before the project has operating laws, you are basically hiring a very fast teammate with no handbook. It may produce code. It may even produce a lot of code. But it will also make tiny local decisions that slowly reshape the project.
The point of a project constitution is not to predict every possible task.
The point is to define the shared laws so people, and AI tools, can make local decisions without constantly crashing into each other.
If you are still turning a rough app idea into something buildable, I made AI App Builder Starter Prompts, a free prompt pack for beginners who want to scope a first website or mobile app with AI before code starts changing:
https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts
This article is about one layer I would add before serious building starts: the constitution.
A Constitution Is Not A Plan
This is where I want to separate today's lesson from normal planning.
A build plan says:
"Here are the phases."
"Here are the features."
"Here is the MVP."
"Here are the user stories."
That is useful. I believe in that.
But a constitution answers a different question:
"How do we behave while building?"
That question is easy to ignore because it does not feel like progress. It does not create a screen. It does not ship a feature. It does not make the app look more real.
But it controls the quality of every decision after it.
In the startup iOS project, the constitution covered things like:
- when a view should become reusable
- when a schema change was allowed
- how to notify the team before changing shared data structures
- when to create a new model or struct
- what a pull request needed to explain
- how branches should be named
- what commit messages were supposed to communicate
- how much mess the linter was allowed to tolerate
- when we should use WhatsApp versus Notion
- how biweekly demos and retrospectives worked
- who owned a feature
- what "done" meant for a story
None of those are glamorous.
All of them prevent future confusion.
The most expensive project problems are often not the ones with obvious explosions. They are the little repeated ambiguities.
Should I make a new model for this?
Can I change this field name?
Should this view be reusable?
Where should I ask this question?
What does the PR need to say?
Is this feature done because the screen exists, or because the user can complete the workflow?
If nobody writes the answers down, every developer has to guess. If you are working alone with AI, the AI guesses. If you are working with a team, the team guesses in different directions.
That is how a codebase gets weird.
Not all at once.
One reasonable little exception at a time.
The Traffic Law Analogy
The best way I can explain this is traffic laws.
Traffic laws do not tell you where to go.
They do not pick your destination. They do not decide whether you are going to the grocery store, the beach, a client meeting, or the DMV because apparently society still needs a place where time goes to get processed by fluorescent lights.
Traffic laws define how everyone moves while pursuing their own destination.
Stay in your lane.
Stop at red lights.
Signal before turning.
Do not drive straight through someone else's car because you had a strong personal vision.
Those rules create freedom because everyone can make local decisions inside a shared system.
That was the point of the startup constitution.
Each developer had a destination: a feature, a user story, a definition of done.
They did not need me to micromanage every turn. They needed shared laws that kept their route compatible with everyone else's route.
That is the same reason a beginner building with AI needs project rules.
You do not want to prompt every tiny decision from scratch.
You want the AI to know:
- what version one is allowed to become
- what it should not add without asking
- how it should treat data changes
- when it should create abstractions
- when it should avoid abstractions
- what counts as done
- how it should report uncertainty
- what it must verify before claiming success
The constitution turns repeated judgment into reusable context.
That is the whole game.
The Mission Command Version
There is another useful analogy: Mission Command.
The simple version is this: leadership defines the what and the why, while the people closest to the work own the how within shared tactics and constraints.
I like that because it avoids two bad extremes.
One bad extreme is micromanagement.
Every decision has to go through the leader. Every question becomes an interruption. Every developer waits for permission. The project moves only as fast as the bottleneck person can answer messages.
The other bad extreme is chaos wearing a startup hoodie.
Everyone has "autonomy," but nobody shares the same rules. One person changes the schema casually. Another creates a new model for every small use case. Another builds a beautiful reusable component that nobody else understands. Another opens a pull request that explains nothing except "updates."
That is not autonomy.
That is distributed confusion.
The useful middle is:
Here is what we are trying to accomplish.
Here is why it matters.
Here are the laws we follow while doing it.
Now own your feature.
That is what I want from AI tools too.
I do not want to supervise every keystroke. That defeats the point of using a capable tool. But I also do not want the tool making silent architectural decisions because I forgot to define the rules.
AI is at its best when it has enough freedom to execute and enough constraint to stay inside the project.
That balance does not happen by accident.
You write it down.
The Sections I Would Put In A Beginner Project Constitution
If I were starting a new AI-assisted app today, I would write a short constitution before serious coding.
Not a 40-page document.
Not a corporate wiki that makes everyone wish software had stayed a hobby.
Something small enough to read and real enough to enforce.
Here are the sections I would include.
1. The Project Boundary
Start with what the project is and what it is not.
This is not the full roadmap. This is the legal fence around version one.
For example:
Version one helps one musician record a rough song idea, tag it, find it later, play it back, edit the name, and delete it.
Version one does not include collaboration, public profiles, AI mastering, subscriptions, teams, comments, social feeds, or cloud sharing unless I explicitly approve a scope change.
That kind of boundary matters because AI tools are helpful in the most dangerous way possible.
They are happy to add things.
If you do not tell the tool what the app is not, it may treat every plausible future feature like a current requirement.
Your constitution should make expansion a decision, not a default.
2. The Data Law
Data changes deserve special respect.
In the startup project, schema discipline mattered because shared data structures affected everyone. If someone changed a field, renamed a property, or altered an expected shape, the effects could ripple through multiple features.
That is why the constitution made schema changes visible.
For a team, that might mean:
Do not change the schema without notifying the team and getting buy-in.
For a solo AI-assisted build, that might mean:
Do not add, remove, or rename database tables, fields, model properties, storage paths, or API response shapes without first explaining why the change is necessary, what code it affects, and how we will migrate or test it.
That one rule can save you from a lot of mysterious breakage.
AI tools can be casual about data if you let them. They may add a field to solve one local problem without realizing they just changed the contract the rest of the app depends on.
The data law says:
Shared structure is not a scratchpad.
Treat it like infrastructure.
3. The Reuse Law
Beginners often swing between two mistakes.
One mistake is copy-pasting everything.
Every screen gets its own slightly different button, card, form, spacing pattern, and data formatter until the app becomes a museum of small inconsistencies.
The other mistake is abstracting too early.
Suddenly a simple screen has generic factories, clever helpers, and reusable components that look like they are preparing for a future product line nobody asked for.
So write the reuse law.
Something like:
Create reusable views and helpers when the same pattern appears at least twice and the shared behavior is stable. Do not create a new abstraction just because it feels professional. Do not copy a component three times without asking whether it should be shared.
That rule gives AI a better target.
It does not say "reuse everything."
It says "reuse when reuse reduces real duplication."
That distinction matters.
Good software is not code that looks clever.
Good software is code that stays understandable while the product changes.
4. The Model And Struct Law
In iOS work, model and struct discipline matters because these objects become the nouns of the system.
The same idea applies everywhere.
If AI creates a new type for every little situation, the project vocabulary bloats. If it refuses to create real models, the app becomes a pile of loose dictionaries, anonymous objects, and fragile assumptions.
A constitution can define the rule:
Create a new model, type, struct, interface, or schema object only when it represents a real concept in the app or protects a contract used in more than one place. Before adding one, explain what concept it represents and where it will be used.
This forces the tool to connect code structure to product meaning.
That is what beginners need.
Not more files.
More understandable files.
5. The Pull Request Law
Even if you are working alone, a pull request template is useful.
Why?
Because a PR template makes the work explain itself.
In the startup constitution, PRs needed to communicate the point of the change. Branch names and commit messages also had expectations. Not because naming branches correctly is a spiritual discipline, but because unclear version control becomes painful when people have to review, debug, or reconstruct what happened.
For a beginner using AI, the PR law can become a "change summary law."
Before calling a task done, the AI should answer:
- what changed
- why it changed
- which files changed
- what user behavior is now possible
- what risk remains
- what was tested
- what was not tested
That is not busywork.
That is how you stop a fast tool from leaving you behind inside your own project.
It is also why a free prompt pack is useful at the beginning. The free AI App Builder Starter Prompts are meant to give you practical ways to make AI explain scope, rules, build steps, debugging, QA, and launch instead of just producing files:
https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts
The tool should not just change the code.
It should help you understand the change.
6. The Communication Law
On the startup project, communication rules mattered because interruptions have a cost.
If every uncertainty becomes a WhatsApp message, the lead becomes the team's notification center.
That does not scale, even on a tiny team.
So a constitution should define where different kinds of communication belong.
For example:
Use the project-management tool for feature status, blockers, decision records, and retrospective notes. Use direct chat only for urgent coordination, time-sensitive unblockers, or issues that cannot wait until the next check-in.
For AI-assisted solo work, the communication law looks different, but the principle is the same.
You can tell the AI:
Keep a running project log. When you make an important decision, record it. When you discover a blocker, summarize it. When you finish a task, update the next-action list. Do not assume future sessions will remember unstated context.
That is how you avoid restarting the whole project mentally every time you come back.
Your brain should not be the only database for project truth.
That database is unreliable and occasionally wants snacks.
7. The Demo Law
The startup team ran biweekly demos.
That cadence mattered because it forced work to become visible.
A feature is not done because the code exists.
A feature is not done because the screen loads.
A feature is not done because the AI says, "The implementation is complete."
A feature is done when the intended user behavior works.
The demo law can be simple:
Every work cycle should produce one visible user improvement or one clearly explained technical improvement that protects the user's workflow.
For a team, that might mean a demo every two weeks.
For a solo beginner, it might mean:
At the end of every build session, show the exact user path that now works, record what still fails, and write the next test.
This keeps you from drifting into fake progress.
You are not collecting files.
You are building user behavior.
8. The Retrospective Law
The constitution should be amendable.
This is important.
A constitution is not a sacred tablet. It is a living operating system.
In the startup project, retrospectives gave us a place to ask:
What slowed us down?
What caused confusion?
Which rule helped?
Which rule needs to change?
What should we stop doing?
What should become part of the constitution?
That is how the document stays useful instead of becoming a stale shrine to decisions made when everyone knew less.
For an AI-assisted beginner project, I would run a tiny retrospective every few sessions:
- Where did AI drift?
- Which instruction did I repeat too many times?
- Which bug came from an unclear rule?
- Which project fact should be written down?
- Which new law would prevent this next time?
That last question is the whole mechanism.
If you keep correcting the same behavior, you do not need more patience.
You need a rule.
What This Looks Like As An AI Prompt
Here is a practical starter prompt:
I am building [app idea] with AI assistance.
Before we write code, help me create a short project constitution.
The constitution should define:
1. the version-one project boundary
2. data and schema-change rules
3. reusable component rules
4. model/type creation rules
5. change summary or pull request rules
6. communication and project-log rules
7. demo or verification rules
8. retrospective rules for improving the constitution
For each rule, explain:
- why it exists
- what mistake it prevents
- what the AI coding tool must ask before violating it
Keep the constitution practical enough to paste into a Notion page, AGENTS.md file, or project rules document.
Then paste the result somewhere the project can actually use it.
Not just in a chat that disappears.
Put it in Notion.
Put it in AGENTS.md.
Put it in your repo docs.
Put it wherever you and the AI will see it before work starts.
The location matters less than the behavior:
The rules must be visible while decisions are being made.
Autonomy Needs Boundaries
This is the part beginners often misunderstand.
Autonomy does not mean no rules.
Autonomy means the rules are clear enough that people can move without asking permission for everything.
That is why the constitution helped on the startup project. It reduced ad hoc feedback. It reduced random interruptions. It made feature ownership easier because the developers had shared tactics instead of a blank field of possible decisions.
The same thing applies to AI tools.
If you have to correct the AI every five minutes, the tool is not the whole problem.
Your project may not have enough written law.
Write the law once.
Then make the tool operate inside it.
That is a much stronger habit than trying to remember every preference, every rule, every constraint, every warning, and every decision yourself.
A project constitution is not a replacement for judgment.
It is a way to preserve judgment so you do not have to regenerate it from scratch every session.
The practical takeaway:
Before you ask AI or a small team to build faster, write the operating laws that make faster safe.
Not a giant plan.
Not a rigid bureaucracy.
A living constitution.
The what and why stay clear.
The how has room to breathe.
And the project stops relying on constant correction as its main management system.
I made a free AI App Builder Starter Prompts pack for beginners who want to turn a rough app idea into a scoped first build with AI:
https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts
If you want the full build-along field manual behind the free prompts, AI App Builder From Zero walks through idea, scope, stack, prompting, QA, deployment, and launch:
https://marcusykim.gumroad.com/l/ai-app-builder-from-zero
You can also find me here:
Medium: https://medium.com/@marcusykim
DEV.to: https://dev.to/marcusykim
Website: https://marcusykim.com/blog/
X: https://x.com/marcusykim
LinkedIn: https://www.linkedin.com/in/marcusykim/
Top comments (0)