In every project, there’s a common phenomenon called the Project Paradox. We often start with the smallest amount of information, yet we feel compelled to make the largest, most foundational decisions right out of the gate.
The Paradox Explained
At the very start of a project you know very little. Yet I’ve seen time and time again myself and others being tempted to lock in major decisions that will shape the project. These early choices can have long-lasting implications, and often, they prove to be hard—or even impossible—to reverse.
Abstract Example
Imagine planning a huge, epic project:
- Planning Phase: You spend a ton of effort meticulously specing out both the product and the technical details.
- Team Assembly: A large team is brought on board to execute this grand vision.
- Reality Hits: Shortly after you begin development, it becomes apparent that the design has critical flaws, forcing you to make costly, retroactive patches.
Concrete Example
At our company’s inception, we faced this exact challenge. We made an early decision to build our backend on Python, Django, and Postgres, with a React frontend using REST mostly due to our product’s focus on ML/AI. This tech stack was a solid choice. But over time I began to realize:
- Missed Opportunities: Perhaps a JavaScript-based backend (Vercel, Supabase) would have allowed us to iterate and prototype more rapidly.
- Rigidity: Our initial tech stack is hard to migrate away from, and we’re not incentivized to do so.
Even now, with every new product request that’s not related to ML/AI I’m painfully reminded of my early decisions and how we might have iterated more quickly if we chose a different architecture.
An Iterative Approach to Decision-Making
The key takeaway from Project Paradox is simple: make as few decisions as you need to, and optimize for learning. Instead of over-planning and locking in every detail from the start, focus on building a vertical slice of your product—an end-to-end, fully functional release that you can test with real users.
Build a complete, usable feature set, release it, gather feedback, and then iterate.
Releasing a full product increment early provides invaluable insights that can inform the next set of decisions.
Navigating Decision Types
When you’re forced to make decisions, it helps to understand how difficult they are to change.
1. Easy-to-Reverse Decisions
- Approach: Optimize for speed. Build with the mindset that these will be swapped out multiple times as your product evolves.
- Example: The design of UI components. Often-times these undergo several iterations and are cheap to iterate on or even fully replace
2. Hard-to-Reverse Decisions
- Approach: Design your system so that even these decisions can be revisited if needed.
- Example: Our initial tech stack. We’ve intentionally chosen a Ports and Adapter architecture which allows us the possibility of migrating to service architecture in the future. On the other hand, we won’t be making the decision to migrate to service architecture until we’re absolutely certain that it’s the right call
3. Irreversible Decisions
- Approach: Avoid these early on unless absolutely necessary. If you can create environments where you can test radical ideas—even if it means throwing away the project—to ensure they’re the right call.
- Example: Switching to a micro-service architecture can be irreversible. Such a transition should be made with caution, ensuring that your company is ready for the operational and developmental consequences.
When to Make a Decision
Embracing an iterative approach means delaying major decisions until you’ve gathered enough insights to make an informed choice. A key signal that it's time to decide is when technical debt has accumulated to the point that your current architecture is clearly slowing your team down.
Recognizing the Right Moment
At this stage, you should be able to:
- Identify Affected Use Cases:
- Distill Core Challenges:
Clearly articulate which specific use cases are being hampered by the current architecture and why they’re problematic.
Boil down these issues into one or two primary challenges. If you’re facing too many major problems, it might indicate that you need to break the decisions into smaller, manageable parts rather than tackling them all at once.
Meaningful Tradeoffs
Every major decision inherently involves tradeoffs. A good decision should:
- Clearly Define Tradeoffs:
- Prioritize Based on Constraints:
Understand that making one aspect of your system easier may complicate another. If a decision doesn’t involve any meaningful tradeoffs, it’s likely not a meaningful decision
Evaluate which constraints—such as development speed, scalability, or maintainability—are most critical to your team’s success. Optimize for the most pressing ones to maximize impact.
Learn to Live with Past Mistakes
While it might be uncomfortable to live with past mistakes, resist the urge to preemptively fix them pre-emptively. As my chess coach used to say, “Games are lost on your second mistake, not your first.”
Final Thoughts
Project Paradox teaches us the value of incremental progress and learning from real-world feedback. By resisting the urge to over-commit to early decisions, you can keep your project agile and responsive to change. Prioritize building vertical slices of your product, make reversible decisions when possible, and tread carefully with those choices that could lock you in permanently.
Embrace the journey of iterative decision-making—it might be messy at times, but it’s the most reliable path to a product that truly meets the needs of your users.
Happy building!