A Dev.to discussion surfaces a critical tension in engineering culture: the difference between developers who treat code as a temporary fix versus those who build systems designed to be maintained. The core insight—"do it right or don't do it"—challenges the startup norm of shipping fast at the expense of long-term ownership.
Analysis
The Ownership Problem in Startup Engineering
Most startup founders inherit a familiar pattern: early code works, but it's fragile. Developers ship features under pressure, then move to the next sprint. Six months later, that "temporary" solution is now critical infrastructure, and nobody wants to touch it.
The Dev.to discussion frames this as a cultural choice, not a technical one. The Portuguese phrase "temos um rojão na mão" (we have a firecracker in our hand) captures the sensation: code that works but feels unstable, requiring constant attention. The opposing state—"não precisa mais pensar nisso" (you don't need to think about it anymore)—describes systems that are genuinely owned, tested, and maintainable.
Why This Matters Now
As startups scale from founder-led to team-based engineering, code ownership becomes a hiring and retention problem. Developers don't want to inherit firecrackers. They want to work on systems they can be proud of. This directly affects your ability to attract mid-level engineers—the people who can multiply your output without requiring constant founder oversight.
The "do it right or don't do it" principle also has a hidden cost benefit: it forces early prioritization. If you commit to ownership standards, you ship fewer features but with fewer production incidents. For bootstrapped founders, this trade-off often favors stability over velocity.
What Changes
This isn't a call to perfection. It's a call to intentionality. The distinction is between:
- Temporary code with no plan: Ships fast, creates debt, requires firefighting
- Intentional MVP code: Ships fast, but with a documented refactor plan and ownership assigned
Founders who adopt this mindset early make three concrete shifts:
- Code reviews become non-negotiable, even in a two-person team
- Technical debt gets tracked like product debt—it's a backlog item, not a secret
- New hires inherit systems they can understand and improve, not systems they inherit as liabilities
Watch For
Hiring friction: If mid-level developers are rejecting your offers or leaving after 6 months, ask them about code quality and ownership. You'll often hear the same complaint: "I couldn't tell who owned what, and nothing was documented."
Incident frequency: Track production incidents by root cause. If 40%+ are in code written 12+ months ago, you have an ownership problem, not a monitoring problem.
Refactor resistance: If your team dreads touching old code, that's a signal that ownership standards weren't set early. Fixing this requires explicit permission and time allocation—not just culture talks.
Source Claims
- →Dev.to discussion centers on the tension between quick-ship code and maintainable systems
- →The phrase 'temos um rojão na mão' describes code that works but feels unstable and requires constant attention
- →The opposing principle is 'não precisa mais pensar nisso'—systems that are genuinely owned and maintainable
- →The core principle discussed is 'do it right or don't do it'—a standard developers should respect from the start
- →Code ownership is framed as a cultural choice, not purely a technical one
