Zora

Founder's Journal - 9/1/25

Happy Labor Day Everyone, I hope everyone is getting some time to disconnect and enjoy the day that is a celebration of your labor! One note before we get started - you become acutely aware of how much money you’re burning on holidays when you start a company. I’m by no means in favor of abolishing holidays (though you won’t hear me clamoring for a call to match Europe here in the US). It’s just one of those things you go from never thinking about to being hyper sensitive to. With that being said one of the benefits of hiring high agency individuals with real skin in the game is they are also hyper sensitive to time being our most valuable resource. Even though we cancelled our sole meeting today (we keep it lean, only standups to keep everyone aligned) I’m still seeing the slack littered with progress updates. I’m trying to lead from the front and let them know it’s okay to take the day by not responding but I can’t say I’m mad they are taking it upon themselves to keep shipping. So anyways we’re officially 1 month old as a company! And with another week in the books we finally had a major disagreement among the co-founders. I found our process for conflict resolution to be really impactful so I'm sharing it this week! It started with a classic founder dilemma: my co-founder and I looking at the same experiment and reaching completely opposite conclusions about what to do next. The Contrarian Bet When we founded the company, we made a deliberate choice: maintain maximum flexibility to experiment. The conventional wisdom is startups should go all-in on a single bet. Traditionally you have 12-18 months of runway from an early round investment. Meaning there's no time to spread your chips like incumbents can. It's boom or bust. But when something becomes common knowledge there's often value in the contrarian position. So we developed a model for small experimental bets. Ones where 80% or more of the work benefits our core product anyway. The thinking: if the majority of effort advances our main build, the incremental work is justified by getting more shots on goal while potentially driving revenue sooner. It also lets us launch things without compromising the core build. Given our collective backgrounds in crypto there are plenty of examples of types of products we could build to target a speculative customer that is not our ideal persona for the core product. This model is also made possible by the speed to market AI peer and vibe coding allow for. In our first month I've seen our team consistently beat dev forecasts, build prototypes in hours instead of days, and ultimately create the work product of a much larger team. Within two weeks of founding, we identified our first experiment. An MVP we could ship in a month, meaning a full product live within 6-8 weeks of incorporation. Pretty insane. When Tailwinds Meet Reality As we built, macro tailwinds made the revenue opportunity look like it could be a multiple of our original forecast. The temptation to double down was real. My co-founder saw the upside. I saw the core product delay. My gut said the opportunity, while good, wasn't worth continuing to push back our main build. But I needed more than gut instinct. That's when we built the decision matrix. Not to resolve a heated debate, but to make our intuitions explicit and quantifiable. The Startup Advantage Paradox Here's what became clear: our biggest advantage as a startup, speed and flexibility, was also our biggest threat. Zero bureaucracy. No legacy tech debt. All stakeholders on a single call making decisions in real-time. This is our superpower. But time is our scarcest resource. With limited runway, every month spent on the wrong thing compounds the risk of missing our window entirely. If we can't show enough traction to justify a follow on round or generate enough revenue we could be dead in the water. So to make the decision on what to do next I do what I do best - I wrote down everything. The Decision Matrix in Action We started by quantifying our range of outcomes: Expected value if we were successful (i.e. rev forecast * probability of success) Total cost of resources (burn and opportunity cost) We then honed in on key constraints for our core product and business: How much time would we need to get our core product to market? How much time would we need to evaluate if the core product was on the path to product-market fit (PMF) How much time would we need to raise after #1 and #2? We knew we needed X amount of time to have the product in market and build towards PMF before going back to raise. What we couldn't know was how any "unknown unknown" may bloat our dev estimates. To be safe we added a multi month buffer to our estimates. After quantifying the outcomes and evaluating our constraints the decision become clear. The Outcome (And the Safety Net) Decision: Stay with the MVP. Don't expand the experiment. But here's the key - we didn't just walk away. We set performance thresholds. If the MVP hits certain metrics, we'll reevaluate. By then, we'll be in a different cash position with more data, making the risk/reward equation completely different. We were able to maintain our ethos of experimentation without losing the plot because we forced ourselves to quantify the decision. The Framework That Actually Works Here's what I learned: the magic isn't in the math - it's in making your gut feelings explicit and quantifiable. The process we used: Make assumptions explicit - What are we really betting on? Assign probabilities (even rough ones) - Force yourself to put numbers on intuition Calculate expected value - Let the math inform, not decide Define constraints - What are the real limiting factors? 5. Set performance thresholds - When would we revisit this decision? The goal isn't to be right every time. It's to be intentional every time. Your Weekly Questions As you think about what you're building this week: What decisions are you making based on gut feeling that could benefit from explicit assumptions and probability assignments? How might your biggest constraints (time, money, team capacity) be influencing decisions in ways you haven't fully considered? Where are you letting perfect opportunity cost cloud practical resource allocation? That's it for this week. The contrarian bet on maintaining optionality while staying focused is working so far - but ask me again in a year when we have more data points. If you found this useful, let me know what you think and share it with other founders wrestling with similar decisions. See ya next week, Austin