Rules for raptorthree

We are trying to build Raptor Three without turning the process into its own project. These are the rules we come back to when the work starts getting complicated.

1. Put a date on it

Set a deadline for the work. Make it soon enough to keep us moving, but realistic enough that we can hit it.

A deadline helps us decide what matters now and what can wait. It also tells us when to stop polishing. The point is to create momentum, not pressure that makes the work worse.

2. Start with a test and keep it small

We use TDD, KISS, and YAGNI. Write the test first. Make the simplest thing that passes it. Leave the rest alone until there is a reason to build it.

The small solution is usually easier to understand and change. We would rather have that than a bigger solution built around features we do not need yet.

3. Show the first working thing

Do not wait until the product is finished before showing it to a coworker. Show the first button. Show the first buggy feature that works.

That is when feedback is most useful. Changing direction is still cheap, and we can spend our time on what the product actually needs instead of what we imagine it needs.

4. Take tiny steps

Keep each step small enough to run, test, or show. That makes problems easier to find and feedback easier to use. It also makes progress easier to see, which helps us keep going.