Tech has a handover problem.

Projects get inherited from team to team, year to year, but the operational and implicit knowledge - the edge cases, loose threads, and the why behind the code - often gets lost. When you lose this much information across semesters, projects can wind up “default dead.” Progress slows to a halt while usability and data issues accumulate, because no one understands the existing system well enough to confidently fix them.

I wish this was a hypothetical. Lost and Found recently suffered over seven days of downtime partly because no one close to the project knew how to repair its auth system when the entire database was wiped. Other projects, like CollegeCart, Terrier, and CMU Courses, are effectively black boxes to those outside of their core members, which limits how much these projects can reasonably grow in the future.

We can’t just hope someone smarter down the line will have the time and energy to reverse-engineer what we build today. The real fix is to make our projects “default alive” through careful planning and documentation.

What does being “default alive” look like?

In startup terms, a company that’s “default alive” is on track to profitability without extra funding. In the context of ScottyLabs, a default alive project will continue to operate, deliver value, and be easily extendable, even if the team disappears and all that’s left is their documentation and code.

As a rough barometer, someone unfamiliar with a “default alive” project can still answer the following questions without too much effort:

• What are the key components of the system? (frontend, backend, database, caches, cron jobs, etc.) What is the high-level architecture of each part, and how do they work together?
  • What are the likely failure points in the system, and how do I troubleshoot these areas?
  • How can I get all the components running locally? Where are they hosted in staging and production?
  • Why is the system designed the way it is? What other alternatives and dead ends have already been tried? What is worth exploring?
• Is it dependent on or a dependency of other projects? How does it interface with them?
• How does data flow through the project? Where are the upstream sources, how is it processed, and where is it stored? Are there backups? What should I do when users notice outdated or incorrect information?
• How do I know that the service is working as expected, even after introducing a new feature or fixing a bug?

Answers to these questions can look like comprehensive test coverage, good onboarding documentation, and RFCs, among other things. If new members feel comfortable and confident working in the codebase from day one, projects end up default alive and often thrive as a result. Is it any coincidence that out of all brownfield projects, the two most well-documented ones - CMU Eats and CMU Maps - were also the two most productive this year?

Codebase design considerations

The clarity of our answers above greatly depends on implementation decisions. Thinking with the end in mind (when team members are no longer here to contribute or answer questions) can help us answer many project-specific design decisions:

• Do we go with a mainstream language like Python or TypeScript, or something more niche like Go or Rust? Svelte or React? Node or Erlang?
• Should we integrate our project with ScottyLabs’ identity provider (Authentik) or a third-party IDP (like Google OAuth) for authentication?
• Should we be a monorepo or clearly delineate service boundaries across different repos?
• How much LLM coding should we permit? How much vibe can we reasonably afford when vibe coding?
• Should we do a rewrite or build on already robust functionality?
• Should we host our projects on a one-click cloud platform like Railway, or move to a more customizable CMU VM?

The right answer, of course, depends on context: time constraints, team size, expertise, etc. But it’s worth taking a moment to assess how these decisions can affect project maintainability.

Final Thoughts

Those who contribute the most to ScottyLabs have an obligation to turn their implicit knowledge and the hard-won expertise into explicit, readily accessible, high-quality documentation. The alternative? Legacy code and projects that become a liability, that we can’t build off of without a total rewrite or a lot of reverse engineering.

We aren’t just building things in Tech for ourselves.

We’re building for everyone, today and tomorrow.