What works in my experience:

1. Code review with "explain this to me" questions. Not gotchas, genuine "walk me through why this works." If they can't explain it, it doesn't merge.

2. On-call rotation for what you ship. Nothing motivates understanding like being woken up at 3am by your own code.

3. Pair programming on complex features. Not watching - actually driving together.

The real question is: are they shipping code they don't understand because they're lazy, or because the codebase is so complex that nobody fully understands it? If it's the latter, the problem isn't the engineers - it's the architecture.

Every tattoo artist needs a signed liability waiver. Every personal trainer needs a health screening form. These are still overwhelmingly paper PDFs that get stuffed in a filing cabinet.

The value isn't in the format itself - it's in the legal protection the signed document provides. The format is actually a hindrance (hard to search, easy to lose, impossible to analyze at scale).

The real opportunity is replacing these static PDFs with digital equivalents that maintain the legal value but add searchability, automatic storage, and analytics.

The insight: these people don't need "websites" in the traditional sense. They need specific functional pages - a digital waiver, a booking page, an intake form, a bio link. But every existing tool (Wix, Squarespace, even Linktree) assumes you want to "design" something.

So I'm building something where you describe your business in plain text and get back a functional page in seconds. No templates to browse, no drag-and-drop, no color picker decisions.

The most interesting technical challenge has been making the AI output actually look professional without giving users any design controls. Turns out constraining the design space makes the average output much better than giving people unlimited freedom.

A focused tool that does one thing well starts getting PRs and issues for tangential features. The maintainer, wanting to be responsive, merges them. Six months later the project is a Swiss army knife that's hard to maintain, hard to onboard new contributors to, and the original use case is buried under complexity.

The antidote is a clear CONTRIBUTING.md that says "here's what this project IS and ISN'T" and being comfortable closing issues with "out of scope, but would make a great separate project."

Easier said than done when you're a solo maintainer and every closed issue feels like you're letting someone down.

I went the part-time route. What I learned:

1. Constraints breed creativity. Having only 10-15 hours/week forces you to ruthlessly prioritize what actually moves the needle vs. what feels productive.

2. Revenue validation before quitting is underrated. If you can get even $500/mo while working full-time, you've proven something real. Most people who quit to "go all in" spend months building before discovering nobody wants what they're making.

3. The emotional rollercoaster is easier to handle when your rent isn't tied to your MRR. Bad months don't become existential crises.

The one caveat: if your startup requires intense sales cycles, enterprise deals, or you're in a winner-take-all market with funded competitors, then speed matters more than sustainability. But for most B2B SaaS or tools businesses, the tortoise approach works fine.