Quite frankly, I have plenty of personal projects that have been left unfinished — it’s all too easy to get caught in the details of every single problem and lost interest and discipline to move the project forward. I ran across this timely video from Joey from BPS who argues for optimizing against some “Great Filter”: another label for describing your project’s #1 priority or its most devastating failure mode. For projects you work on within the context of a job, this filter is usually optimized against some engineering metric, deadline, or cost. In the worst case, your project runs over Service-level Agreements (SLAs) or you don’t meet a deadline leading to features getting de-scoped.
But, for personal projects, your greatest “Great Filter” is finishing your project. While Joey directly thinks of Great Filters through the lens of Personal Projects, its perspective aligns well with the context of building a startup and bringing a new product to market.
Joey focuses on Personal Projects; now working on a product I’m building as a business from scratch, and the same existence filter applies.
In a startup, no one cares you’re not using the most scalable framework or that you can’t handle 10x the scale. You just need to build something of value and be able to distribute it to people who can pay before you run out of money.
“Street Fighting Mathematics” is a lecture that walks through ways to progress your Computer Science theory research ‘the dirty way’.
Before watching this video, I thought CS Theory research was an exercise of memorizing and learning as much CS Theory and math so you can magically peer through patterns to expertly navigate your proof. There’s some of that for sure. But, for a lot of theory problems, you don’t need to memorize everything. You can brute force subproblems with online tools and just pretend like you knew that obscure piece of math knowledge the whole time when you write your research paper.
Building software for a new product is similar. You don’t need to hand-build a component framework or directly write every SQL query. There are libraries and tools that exist that speed up this process.
There really should be a “Street Fighting Software Engineering” video: a tutorial on all the different APIs, libraries, or other strategies to just quickly fake and prototype ideas without fully committing to building a full, robust technical solution. Coming out of a larger tech company where your impulse might be to just recreate the same familiar tooling and infrastructure you once had, it’s an active skill to learn how to be scrappy. But if your Great Filter is having your project just existing at all, you need to fight dirty and just get your prototype working.
You can use Google Spreadsheet as your primary datastore. Just be a GPT wrapper before training your own models. You can Wizard of Oz” your AI and you yourself are pretending to be the AI before actually building it. You just don’t have time to have the perfect environment, the perfect tooling, the perfect architecture, the perfect CI/CD pipeline, or even the most reliable, 99.9% available product. It just needs to work to demonstrate value.
With all this said, I don’t think the answer is just to AI vomit a whole product out. There are places where these solutions are truly good enough. I’ll eventually write about this, but there’s strategic nuance in figuring out what’s worth street fighting vs what’s worth over-engineering once you uncover and define more unknowns.