Key Takeaway: Operating notes from building a software company -- entropy, data architecture, and the sequencing discipline that encodes founder judgment.
These are private notes made public — lessons from six years running Staircase, a mortgage infrastructure company I co-founded and led as CEO.
These are notes collected over years of building a software company. They contradict each other depending on context, and that's the point -- the right answer changes based on where you are in the lifecycle, who's in the room, and what kind of problem you're facing. But they address the issues worth considering when you're building a software organization, not a company that uses software. That distinction matters more than most people realize, because the operating system for each is fundamentally different.
The Staircase Virtues
Five words, in sequence. Measure. Engineer. Solve. Close. Celebrate.
The order is the point. Not the words. Every failed project I've seen violated the sequence.
Measure -- if you can't define "better" in numbers, you don't understand the problem yet. A lender was sure document prep was the bottleneck. We measured: files sat 36 hours in a compliance queue batched once daily. Trivial fix, once you measure the right thing.
Engineer -- you earn the right to design by measuring first. Reusable systems, not one-offs. Know the cost, design around it.
Solve -- most teams start here. That's why they build the wrong thing. A title company wanted better OCR. The real fix: eliminate data entry entirely by connecting upstream systems that already had the data digitally.
Close -- the graveyard of good companies is full of 80%-done projects. An 80%-done portfolio delivers exactly zero value.
Celebrate -- build things worth being proud of. A hack solves today's problem and creates next month's. An elegant solution solves the class of problems. That's engineering economics.
Skip Measure and you build the wrong thing. Skip Engineer and it can't be maintained. Skip Close and nothing ships. The framework isn't complicated. The discipline is.
New instincts you need
Entropy. Match people with problems they don't actively make worse. Some activity is 10x worse than no activity. For first-principles thinkers, more information reduces the problem space. For everyone else, it increases the problem space non-linearly. Stop adding information as a reflex.
Intractable problems. Most "intractable" problems are just that. Cut them out. Gordian Knot your approach. Don't waste cycles on the unsolvable, especially without an entropy-reducing person to match to it.
Poverty of compromise. Compromise in software architecture creates technical debt that compounds. Pick a direction and commit.
Push vs pull. Push is a management reflex -- full employment for managers. If people aren't willing to pull, they don't want it. Test for pull before investing.
People
The actionable distinction isn't title -- it's what happens when you hand someone a problem with no spec. Engineers ask "what are the constraints?" and build something reusable. Others ask "what should I build?" and wait. Hire for the first instinct. The best engineers I've worked with eliminate their own role -- they automate the repeatable parts until the only work left is the work that requires judgment. That's the signal: do they reduce the problem space or expand it?
Virtues as verbs. The team is here to do something, not to be something. Each virtue should be one word to avoid qualifying language. They should suggest a sequence. The test: you cannot follow the virtues without saying these words in speech and writing. If the words don't naturally appear in how people talk about their work, the virtues aren't real.
Architecture and data
Design for data, not functionality. Data-first means metadata and tracking are inherent. Functionality-first means metadata has to be added retroactively and it never happens properly.
Start at the back of the front and the front of the back. Both constrain the problem space. There are infinite front-end designs and infinite backend possibilities. Adding constraints at the edge where front and back meet is the unlock.
Anything with a UI should be considered pane of glass, not system of record. The database is truth. Start with data, generate PDFs. Not vice versa. Put all logic into code -- any operation can now be performed on tagged and classified data. Normal companies take data, do transformations, create new data that can't be traced to the original. That's why seemingly simple operations "can't" be performed.
Any tool you integrate should be quickly swappable for a competitor. This forces generalized thinking and prevents vendor lock-in. Mandate two integrations for any single function -- it ensures you generalize properly and can switch costlessly. Exception: public clouds. Pick one and commit. And assume every external party will go live with zero testing and zero notice -- they're testing via your customers' errors. Poll them constantly. Their deployment deficiencies become your problem.
Customers: who to avoid
Don't take customers who lack a technical individual you respect. You'll be their savior when you unstick their problems. But then they'll face software problems they don't expect or know how to handle. As their software savior, you're now responsible for solving everything. You'll do more than you're obligated to. It won't be enough. They'll end up firing you and thinking you lied to them. More information makes things worse when the recipient can't process it correctly. See Entropy.