Can We Build It Yes We Can

The Feasibility Framework That Actually Saved My Last Three Projects

I spent years watching good ideas die in spreadsheets. Not because the idea was bad, but because nobody bothered to verify whether the stack of requirements on paper could actually be assembled into something functional within the constraints we were working with. That gap between "looks good in the doc" and "actually works when the lights stay on" is where most projects go to die. Can We Build It Yes We Can is a lightweight feasibility assessment methodology that forces you to answer a very specific question before you commit any engineering hours: not whether the idea is cool, but whether your current resource stack, technical debt, and timeline can support it. It originated from a small group of independent dev shops around 2019 who were tired of seeing proposals approved that collapsed within two weeks of implementation. The framework itself is brutally simple, which is probably why it spread the way it did.

What Can We Build It Yes We Can Actually Is

At its core, the method asks you to score a proposed project across four axes: component availability, integration risk, timeline realism, and resource adequacy. Each axis gets a number from one to five. If the total comes back below a certain threshold, the project either needs to be scoped down significantly or it gets put on hold. The threshold itself isn't sacred—different teams use different cutoffs depending on how risky they're willing to be. Here is where people typically mess this up. They treat the four axes as independent when they are not. Component availability directly affects integration risk. If you are sourcing three custom sensors and one of them has an eight-week lead time, your integration window collapses regardless of how skilled your team is. I learned this the hard way on a climate monitoring rig I scoped for a research station in Iceland. We passed the feasibility check with flying colors on paper. In practice, one of the humidity sensors went end-of-life three weeks into procurement and there was no drop-in replacement. The whole schedule shifted by eleven days because we did not model that dependency during the assessment phase.

How to Run the Assessment Properly

Grab a piece of paper or open a blank document. List every distinct subsystem your project requires. These should be granular, not abstract. "Data storage" is too vague. "PostgreSQL instance with full-text search and 50GB retention policy" is the kind of specificity you need. Score each subsystem on the four axes separately. Component availability means checking whether the libraries, hardware, APIs, or services you need are actively maintained and accessible. Integration risk measures how many handoff points exist between subsystems and how brittle those connections are. Timeline realism compares your estimated completion window against known delivery times for each component. Resource adequacy looks at whether your team has the actual skill coverage, not just the headline titles. Some teams add a fifth axis now and then. Supply chain fragility matters if you are dealing with physical hardware. Regulatory compliance matters if you are touching healthcare or financial data. These are contextual and should not be applied universally.

I keep a running spreadsheet of past assessments so I can compare how my estimates hold up over time. It is embarrassingly humbling to look back at a project where I scored timeline realism a four and the actual delivery took twice as long. Those discrepancies are where the learning happens.

Can We Build It Yes We Can in Practice

The methodology only works if you run it honestly. There is a strong temptation to inflate scores when you are attached to the idea. I have seen engineers give a five on component availability for a library they personally depend on, without checking whether the maintainer has posted any issues in the last six months. The framework catches that lie eventually, but usually after the project has already started bleeding time. One counter-intuitive thing I have noticed is that projects with fewer components often score worse than you expect. A simple dashboard with one API integration might look easy, but if that API changes its authentication flow mid-project, your entire timeline gets nuked. High complexity does not always mean low feasibility. Sometimes a complex system is just a set of well-understood parts interacting in predictable ways. Another thing beginners miss is that the assessment is not a one-time event. You should re-score at major milestones. The integration risk for a hardware project changes once you have the first prototype in hand and discover the firmware library has a known bug with your specific microcontroller variant. I caught that on a drone telemetry build by rescoreing after week three. The original assessment said we were green across the board. After re-evaluating with real firmware behavior in front of us, integration risk jumped from two to four and we pivoted the communication protocol before it became a crisis.

When the Methodology Fails You

This approach is not universal. It breaks down in environments where requirements are fundamentally unknowable at the start. Research-heavy projects, early-stage product discovery, and anything involving novel scientific instrumentation do not fit neatly into a four-axis scoring system. You cannot score component availability for technology that does not exist yet. In those cases, the framework gives you a false sense of precision and you end up making decisions based on numbers that are essentially guesses dressed up as data. For those scenarios, a lean canvas or a structured discovery sprint works better. The Can We Build It Yes We Can framework is designed for projects where you already have a reasonably clear picture of what needs to be built and you need to determine whether your current situation allows it. It is a gatekeeping tool, not a generative one. I have also seen teams use it as a weapon. Engineering leads will deliberately suppress feasible projects by inflating integration risk scores to protect their own bandwidth. This is a management problem, not a methodology problem, but it is worth knowing the pattern exists so you can spot it. If your feasibility assessments consistently produce red lights for projects that later succeed under a different team, check your scoring bias.

The actual resource it lives at is pretty scattered across various community wikis and old GitHub Gists since nobody maintains a single canonical source. Search for the feasibility framework name along with "assessment template" and you will find a few usable sheets. I use a modified version with the scoring criteria written out in plain English so that two different engineers scoring the same subsystem tend to land on the same number. Without explicit criteria, the subjective drift between scorers becomes a real problem.