At Luminary Lane, we believe that great software comes from great principles. Not rigid rules, but interconnected ideas that help us make better decisions faster. These nine principles form the foundation of how we build, and we apply whichever is most relevant to the decision at hand.

1. Ship is Better Than Done

Meaning: Ship often rather than waiting for perfection.

We ship working features daily—not polished, but functional. Version 1 is never perfect, and that’s what version 2 is for. We’d rather have basic UI that displays results than a beautiful UI that doesn’t exist.

This doesn’t mean shipping broken code or skipping security. It means recognizing that real user feedback is worth more than hypothetical perfection.

What this looks like: Ship AI extraction that works 70% of the time TODAY. Don’t wait for 99% accuracy. Manual fallbacks are OK for edge cases.

2. Test, Test, and Test, Baby!

Meaning: Don’t skimp on testing. Don’t break existing features when adding new ones.

Every PR must pass ALL existing tests—no exceptions. New features mean new tests, written as we code. We test the happy path AND edge cases, and CI/CD blocks on test failures.

Our testing hierarchy:

Unit tests — Core business logic
Integration tests — API endpoints
E2E tests — User workflows
Manual smoke tests — “Does it actually work?”
Performance tests — “Is it fast enough?“

3. Fast is Fine, Accuracy is Final

Origin: Wyatt Earp of OK Corral fame

Meaning: Building features fast is a poor alternative to building the RIGHT things in the first place.

We plan before coding. We understand requirements fully. We ask clarifying questions upfront. The right solution beats the quick solution every time, because rework is waste.

Take 30 minutes to plan, save 3 hours of rework. This balances with “Ship is Better Than Done”—we ship the RIGHT thing incrementally. Quick iterations on the CORRECT path.

4. In Doubt, Ask

Meaning: If you’re not sure the path or decision is right, ask for validation.

There’s no ego in uncertainty—asking shows wisdom, not weakness. A 5-minute question prevents a 5-hour mistake. We validate assumptions early and don’t build on shaky foundations.

When to ask:

Before major architectural decisions
When requirements seem ambiguous
Before significant refactoring
When something “feels wrong” but you can’t articulate why

5. Ego Has Killed More Startups Than Money or Tech

Meaning: Accept that there will be blind spots. It’s better to look out for them and correct when found.

We embrace being wrong—it’s how we learn. We seek contradictory evidence actively and thank people who point out flaws. Focus on solving problems, not being right.

Ego traps to avoid:

“This is definitely the right approach” → “This seems right, what do you think?”
“Users will love this feature” → “Let’s test if users actually want this”
“My code doesn’t have bugs” → “Where might bugs be hiding?“

6. Be the Kepler

Origin: Inspired by Carl Sagan’s description of Johannes Kepler in Cosmos

“He preferred the hard truth to his dearest delusions. That is the heart of science.”

Kepler spent years trying to prove planetary orbits were perfect circles. When data showed they were ellipses, he accepted it and revolutionized astronomy. His willingness to abandon beautiful theories for ugly facts led to truth.

How we apply this: Data over opinions. User feedback over our assumptions. If users aren’t using a feature, accept it failed. If the architecture doesn’t scale, redesign it. If our assumptions were wrong, celebrate discovering the truth.

7. Occam’s Razor — Choose Simplicity

Origin: William of Ockham, 14th century philosopher

Meaning: When choosing between solutions, prefer the one requiring fewer assumptions.

Simple architecture over complex. Fewer dependencies over more. Direct implementation over abstraction—unless you need the abstraction NOW. Built-in solutions over custom.

The test: Count assumptions for each approach. The one with fewer assumptions wins.

Complex Solution (OAuth proxy service):
✗ Need custom OAuth flow
✗ Built-in libraries insufficient
✗ Need to manage tokens ourselves
✗ Need separate service
✗ Team can maintain auth infrastructure
= 5 assumptions

Simple Solution (NextAuth.js):
✓ NextAuth.js handles our use case
= 1 assumption

Winner: Simple

Warning signs: “We might need this later” | “This is more elegant” | “Everyone uses this pattern” | Can’t explain why simpler won’t work

8. The Law of Diminishing Returns

Origin: Economics (marginalism)

Meaning: The last 20% of quality often costs 80% of the effort. That effort has an opportunity cost.

Each additional unit of input yields progressively smaller increases in output. The jump from “good” to “perfect” is exponentially expensive—and that expense could build four other features at 80% quality.

Area	80% (Ship It)	100% (Trap)
Test coverage	90% of critical paths	100% including impossible edge cases
UI polish	Consistent, functional	Pixel-perfect animations everywhere
Error handling	Graceful failures + logging	Custom handling for every possible error
Documentation	README + key concepts	Exhaustive docs for internal code

When diminishing returns DON’T apply: Security, core UX flows, legal/compliance, data integrity.

Red flags: “Just one more thing before we ship” | “It’s almost perfect” | Endless refactoring of working code

9. Design to Falsify (Popper’s Falsification)

Origin: Karl Popper, philosopher of science (The Logic of Scientific Discovery, 1934)

Meaning: A hypothesis that can’t be proven wrong is useless. Design experiments that could fail.

Before building, define what failure looks like. If you can’t articulate what would prove you wrong, you’re not testing a hypothesis—you’re defending a belief.

The framework:

1. HYPOTHESIS: "Enterprise users will pay $500/month for white-label"
2. FALSIFICATION CRITERIA: "If <5% of trials request it, hypothesis is false"
3. EXPERIMENT: "Add to pricing page, measure requests before building"
4. RESULT: "2% requested → Hypothesis falsified → Don't build it"

Unfalsifiable statements (red flags):

“We just need better marketing” — Marketing can always be “better”
“The right users will get it” — Defines failure as “wrong users”
“It’s a long-term play” — Defers judgment indefinitely
“Users don’t understand the value yet” — Blames users, not product

When you hear these, ask: “What evidence would change your mind?”

How They Work Together

These principles form an interconnected system:

Ship is Better Than Done + Diminishing Returns = Ship when marginal effort exceeds marginal value

Be the Kepler + Popper’s Falsification = Design experiments to find truth, then accept it

Occam’s Razor + Diminishing Returns = Don’t add complexity, and don’t perfect complexity

Ego Has Killed More Startups + Popper’s Falsification = Falsification is the method for defeating confirmation bias

All nine together: Build the right thing simply, ship it at the knee of the curve, test to falsify not confirm, ask when uncertain, stay humble, choose simplicity, know when to stop, and follow the truth wherever it leads.

Keeping AI On-Principle: The Honor Code Effect

Here’s something we’ve learned building AI-powered tools: AI agents forget principles just like humans do.

This insight comes from behavioral economics research. In Dan Ariely’s Predictably Irrational and Levitt & Dubner’s Freakonomics, studies show that making people recite or acknowledge principles before acting dramatically improves ethical behavior. Students who signed an honor code before an exam cheated less—not because of enforcement, but because of priming.

We apply this same technique to our AI code generation tools. On every context rollover, we make the AI recite our development principles. Before it writes a single line of code, it acknowledges what we stand for.

Does this cost tokens? Yes, a few. Is it worth it? Absolutely.

Our experience has been remarkably encouraging. The AI stays aligned with our principles throughout long development sessions. It naturally gravitates toward simpler solutions (Occam’s Razor), asks clarifying questions (In Doubt, Ask), and avoids over-engineering (Diminishing Returns).

This mirrors our product philosophy perfectly. Just as Luminary Lane helps businesses keep their marketing on-brand across every channel, we keep our development on-principle across every AI interaction. The technique is the same: consistent reinforcement of core values.

The token cost is negligible compared to the cost of an AI that forgets to test, over-engineers solutions, or builds the wrong thing fast. Principles only work if they’re present when decisions are made.

The Path Forward

Build hypotheses (not certainties)
Test rigorously (seek disconfirming evidence)
Accept results (even when they hurt)
Adapt quickly (pivot based on truth)
Stay humble (there’s always a blind spot)
Be grateful (for every discovered mistake)

“The first principle is that you must not fool yourself — and you are the easiest person to fool.” — Richard Feynman

“He preferred the hard truth to his dearest delusions.” — Carl Sagan on Kepler

“Entities should not be multiplied beyond necessity.” — William of Ockham

“A theory that explains everything, explains nothing.” — Karl Popper

These principles guide every decision and every line of code at Luminary Lane. When in conflict, simplicity and truth win over complexity and ego—always.

Interested in building with us? View our open roles or check out our open source projects.