# Building Philosophy > Engineering principles that guide architectural decisions and technology choices - HTML version: https://robbiepalmer.me/building-philosophy # Building Philosophy ## Short Feedback Loops No matter how many times this is proven, it is surprisingly unintuitive and easily forgotten. Spending more time planning and debating makes you more likely to fail. Internal feedback is navel gazing. External engagement is reality. Real users are the best test you'll ever have. Ship first. Early adopters are forgiving if they see you're responsive and have momentum. People add processes constantly - release managers, approval gates, "safety" mechanisms. Decades of evidence says this kills velocity, increases the rate of incidents and leads to building the wrong thing. Shorten the path from idea to production. ## Build Flywheels Build self-reinforcing systems - make small investments that compound. Linear effort, exponential payoff. Don't make flashy, one-off wins. If the work doesn't compound, don't do it. Flywheels should spin fast and stay light. ## Leverage Tech Debt Some technical debt is useful. Treat it as a deliberate tool instead of a moral failure. Strategic debt doesn't just make you faster - it makes things possible at all. Friction is a resource allocation problem. Where friction sits should reflect current priorities. Not hiring? Optimizing onboarding is a waste. Pre-product-market fit? Incomplete test coverage is fine - ship and learn. ## Avoid Negative Compounding Debt with low interest, invested well, is powerful leverage. Debt with high interest, invested badly, will make you bankrupt. Some tech leaders miss the impact of having tech debt in the wrong place. When shipping is hard, people stop trying. Slow deployments don't just delay new features going to customers. They cause lost productivity through context-switching. Incidents take longer because no one remembers what changed, so deploys get more cautious and less frequent. People fill time with what's available, bikeshedding, process tweaks, planning in isolation from the work. The impact compounds until value delivery grinds to a halt. ## Stack Rank, Don't Sprint Planning should clarify priority, not predict the future. Don't tie yourself to arbitrary timelines. Always be ready to address real customer feedback, or respond to new innovation and discovery. Project management is the act of [balancing resources, time and scope](https://asana.com/resources/project-management-triangle). Scope should *always* be relentlessly decreased to get to MVP and discover PMF. Balance your resources per project to get the velocity you want. What works: a stack-ranked list at multiple levels of abstraction - tasks, epics, initiatives. Always know what's most important right now. Reprioritize constantly as you learn. ## The Goldilocks Zone Pick technologies old enough to be reliable and well-documented, but not so old they're unsupported or talent-scarce. Early adopters pay the cost of missing documentation, unpatched bugs, and shifting APIs. Late adopters pay the cost of shrinking community and looming deprecation. The window in between is where you want to be. **Selection criteria:** * **High floor, high ceiling**. Pick tools that make it hard to write bad code, but that scale to complex needs * **Shallow ramp**. Easy onboarding for yourself and collaborators, enabling balanced focus on customer problems, not fighting technology * **Rising tides**. Build on platforms that are themselves growing and improving. Their momentum becomes yours When adopting new tech, do it deliberately and one at a time. People often don't respect learning rate - the capacity of a team to absorb new domain knowledge, tooling, and process at once. Don't compound risk by going bleeding-edge on multiple fronts simultaneously. ## Split By Constraint, Not Dogma Don't split services because "microservices are best practice." Split when you hit a real constraint - * GPU workloads need different infrastructure than CPU * Mobile phones vs servers need different artifacts * Different scaling characteristics need different resources Start as a monolith. Let actual constraints drive the architecture, not org charts or resume-driven development. ## Less Is More Every additional line of code you write is an additional maintenance burden. Build only what makes you unique. Rent the rest. If it's not your core business, buying is almost always cheaper than building and maintaining. Consolidate where possible. Prefer tools that solve multiple problems over specialized single-purpose services. ## LLM-Optimized Every architectural decision needs to account for AI collaboration. AI feeds on context. If it isn't in the repo, it doesn't exist. Everything as code - content, infrastructure, database. This has the extra benefit of encouraging general good practice for collaboration with team-mates; having clear naming conventions and predictable patterns. But now with stronger justification when trade-offs arise. Boring tech is AI-readable tech. The model has seen `React` a billion times; it's hallucinating your bespoke framework. ## Documentation Rots Writing documentation has immense value at the time. It forces clarity of thinking, captures nuance that gets lost verbally, and synchronizes teams. That value has a short shelf life. Documentation is not connected to self-reinforcing feedback loops the way code is. Code gets run by users, consumed by tests, validated constantly. It gets continually rewritten and replaced as understanding of the product evolves. Documentation grows and gets abandoned. Minimize it where possible. Trust the code, not the comment. Write for the moment. Don't expect it to last. ## Build in Public Building in private has costs people rarely account for. Security, access control, tooling to manage it all - energy not going into the product. Public repositories are also directly cheaper. Many products/services provide free tiers for open-source code, e.g. GitHub Actions and CodeRabbit. Showing mistakes matters as much as showing wins. Fast feedback and incremental shipping mean things will be imperfect in public. That's fine - visibility forces focus on what is truly important. ## Generalists Over Specialists Specialists become bottlenecks. They create queues, handoffs, and artificial boundaries. T-shaped engineers - broad knowledge, deep in one or two areas - move faster and see the whole picture. They can unblock themselves. They don't wait for "the frontend person", "the tester", "the data scientist". ## Respect Goodhart's and Conway's Laws [Goodhart's Law](/ideas/goodharts-law): when a measure becomes a target, it ceases to be a good measure. Do not hold people to account for proxies. [Conway's Law](/ideas/conways-law): systems mirror the communication structures of the organizations that build them. Structure your teams to get the architecture you want. --- Markdown index of this site: https://robbiepalmer.me/llms.txt