Epilogue: Reflections from My Cofounders

To close out this series, I asked the two cofounders from my first startup to read through these reflections and respond to a few questions. I wanted to hear which parts they agreed with, what they thought might be useful to other aspiring founders, and how their mindsets or career paths have evolved since our time working together. Their responses follow below

Polina Vishnevskaya

  1. Based on my reflections, which parts do you most agree with or find yourself rethinking differently?

I’ll be honest, I had a strong reaction to some of these pieces at first. Not because they weren’t thoughtful (they are), but because some points feel overblown or not contextualized enough. I found myself agreeing a lot more with Articles 3 to 5. I felt like they showed a better understanding of how messy, emotional, and situational startup stuff is. The points about psychological safety, imposter syndrome, and how we approached the incubator -- those felt fair and actually captured what we were going through.

But with Articles 1 and 2, I didn’t agree with how the story was framed. A lot of the cognitive errors you mentioned did happen, sure, but I don’t think they were why we didn’t succeed. The bigger issue is that we didn’t fully believe it was going to work out, especially given our age, international-student status, and everything else we were balancing. So we didn’t prioritize it. Between school, internships, and life, we made a lot of choices that weren’t always optimal but that wasn’t because we were falling for specific biases. It was because we didn’t have the time, energy, or belief to treat it like something real. That context really matters.

To be fair, you do bring up imposter syndrome, mental headspace, and the mindset shift later in Articles 3–5, and I really appreciated those reflections. I just think leading with the cognitive biases made it feel like the failure was being pinned on our flawed thinking, when in reality, the more foundational reasons came down to belief, capacity, and exposure. I think if those later pieces had come first, it would have better set the tone for what actually made the experience difficult, and what could’ve made it work.

Also, I had a strong reaction to how some of the technical vs. non-technical stuff was framed. That line about marketing being fuzzy vs. programming being “clear-cut” hit a nerve, not just because I was the one programming, but because it was NOT clear-cut. It was messy and overwhelming, especially given I had started coding barely a year before the program. 

Reading your points about not being confident in yourself because of a lack of technical background, I can see how it might’ve seemed like I was dealing with jigsaw puzzles while you were handling all the ambiguity. And I also want to acknowledge that maybe it was hard for you to engage deeply with the technical stuff because it wasn’t always being explained clearly or accessibly. That’s on all of us, not just you.

But also, I want to be clear: user testing and product validation required us to build something tangible. It’s not just about creating slides, it’s about simulating a real interaction. At the time, I didn’t know about Figma flows (which would have still required learning a different tool) and didn’t believe that fake interactions with dummy data would be good enough. We were trying to build something that users could actually touch and click through. That meant stitching together even basic working components, which took time. Without that, even our user interviews wouldn’t have made sense. Users needed something real enough to respond to. So compromising on programming wasn’t optional if we wanted real feedback (yes, even from the conveniently sampled population).

And honestly, I struggled with how to bring this up, but I think it needs to be said: it didn’t feel like the weight was pulled equally. From my side, I was deep in engineering, figuring out both backend and frontend, debugging, learning a new programming language, and trying to make the product functional and accessible enough for people to actually test. I was also trying to bridge communication between the technical side and the broader team, and it often felt like there just weren’t enough hands.

At the same time, it didn’t feel like the marketing, research, or even the application of scientific literacy (which were closer to your domain) were being driven with the same energy or ownership. I totally get that we were all dealing with time constraints and burnout, and it wasn’t always easy to divide responsibilities cleanly. But from where I stood, a lot of the things you’re pointing out in hindsight, like needing to reflect more, think through strategy, or avoid repeating bias patterns, were actually things that were closer to your role to lead on. That’s not to say we didn’t all have a part to play, but this kind of systems-level thinking, pulling the team up to reflect and restructure: that’s part of what I thought you were bringing.

And maybe that’s on us too. We didn’t define roles clearly, or have those conversations early enough. But it’s hard to hear things framed now as “we all should’ve stepped back more” when the truth is, I couldn’t have stepped back. I was too busy keeping things moving. If we had paused and clarified expectations earlier, or if you had pushed for those conversations while I was buried in code, maybe we would’ve avoided some of the lopsidedness and burnout. That’s not to blame, it’s just something I think is important to say out loud.

That said, I do want to acknowledge that while things sometimes felt uneven in terms of who was doing what, there were also areas where you really stepped up in ways I couldn’t have. I really appreciated how you were consistently reaching out to people, setting up user interviews, and helping us stay connected to the outside world. You were driving us to do more outreach and learn from others, which honestly, wasn’t something I felt super comfortable with at the time. That kind of external momentum did matter, and it pushed us to get feedback and test things earlier than we probably would’ve on our own.

So even if there were moments when the roles felt imbalanced or unclear, I also see now that we were each carrying different parts of what made the thing move. And I think that’s just part of the startup learning curve too: figuring out where we stretch, where we lean on others, and where we could’ve done more.

  1. What lessons do you think hold the most value for other aspiring founders reading these essays, or not from reading these essays?

Honestly, I think Article 5 has the most valuable takeaways, and it should have been the first one so that the rest is framed appropriately. Mindset is everything. If you don’t see yourself as a startup founder, it’s hard to actually make real progress. And a lot of us didn’t, at least not at first. So the parts about committing to being a founder, managing psychological capital, and demystifying networking? I fully agree. I think readers of your content need to hear that early on, before they get pushed into the weeds of analyzing confirmation bias or sample sizes.

Something else I think should be included is I wish we had seen more examples of scrappy, early-stage startups instead of just looking at polished products or late-stage teams. That would’ve helped us see what “figuring it out” actually looks like. In the U.S. startup scene (which I got into after), you see that messiness is the process, not a sign that you’re doing it wrong.

Another great point is about healthy conflict. I think our team actually had the psychological safety to deal with it, we just didn’t create the space for it to happen often. Looking back, I think more conflict would’ve helped us operate better instead of trying to keep things smooth all the time.

What I don’t want people to take away is this idea that “cognitive bias = startup death.” I think that frame is a bit dangerous. You can build something while making mistakes constantly. Plenty of teams do it. The key is keeping at it long enough, prioritizing, and having the structure to catch those mistakes over time. So yeah, bias matters, but not in isolation. Time, effort, and ecosystem exposure matter more.

  1. How have your entrepreneurial mindsets or career paths evolved since these events, and in what ways (if any) did this shared journey shape that evolution?

After the summer startup program, I shifted focus to figuring out internships and my next steps career-wise. The biggest part of it was that I didn’t believe building a company that would help me pay off my loan and stay in the US was realistic for me at that point. If we had seen more early-stage success stories (like learning about startup founders getting O1 visas) or had more exposure to founders at our stage, maybe I would’ve thought differently.

But what this experience did do is build muscles. I got better at coding under pressure and at working through problems even when I was totally overwhelmed. I also became way more comfortable starting something without having all the answers upfront. Now, I don’t assume I need to be an expert before I try something. I know I can pick things up quickly when I need to. That mindset shift has stuck with me. I learned how to build something unpolished on purpose, and then make it better over time, without obsessing over getting it perfect the first time.

Something else that came out of this experience was just learning how to put something in front of people, even if it felt raw. There’s a different kind of learning that happens when you show people a product and watch how they interact with it, where they get stuck, what they ignore, what they love. That process taught me a lot about iteration, about product, and about software development in general.

That said, I know now that what we were doing still wasn’t close to what an early-stage startup actually looks like. Now that I’ve gotten plugged into more mature startup ecosystems, especially in SF, I can clearly see how far off we actually were. The speed, the level of outreach, the way people test and validate ideas, how they think about growth hacking and iteration -- it’s a different game. We weren’t just a few steps behind; we were operating in a totally different environment with very little exposure to what “fast” or “scrappy” actually looked like.

And on top of that, we just weren’t putting in the hours: 10 hours a week during the semester isn’t a startup (the summer program was different). We were doing what we could at the time, and I do think we were genuinely trying, but we didn’t know what we didn’t know. Again, I really think more exposure, to other early-stage teams, to founders navigating the same challenges, would’ve helped so much. 

Saad Bin Ihsan

  1. Based on my reflections, which parts do you most agree with or find yourself rethinking differently?

I definitely agree with Article 1's analysis of the cognitive fallacies that doomed our startup. The G.I. Joe Fallacy was particularly striking - despite being "experts" in these biases, we still fell victim to them. What I'd add, though, is that there was an even more fundamental issue at play: we entered the startup world with academic knowledge but no real understanding of what building a product for actual customers looked like. Our ideas were conceptualized in a bubble, detached from the reality of creating a thriving company.

Another factor that wasn't fully explored in the article was our lack of a clear product leader. With everyone having different perspectives on where the product should go, it became extremely difficult for a coherent direction to emerge. I think either better separation of responsibilities or a more decisive leadership structure might have allowed us to commit more effectively to a singular idea.

With Article 2, I strongly agree with the emphasis on becoming a genuine subject matter expert. The article perfectly captures how anything less than deep expertise makes it nearly impossible to penetrate a market successfully. Making sure your foundation is based on up-to-date, high-quality information is absolutely crucial. I'd also add that thinking solely in terms of "low-hanging fruit" is particularly dangerous - if an idea seems obvious to you as an industry outsider, there's probably a reason why insiders haven't pursued it. The game is entirely about who knows more, and taking the time to truly immerse yourself in an industry is non-negotiable.

Regarding Article 3 on conflict navigation, I absolutely agree with the importance of healthy confrontation in a startup environment. When you're heavily invested in a product's future, you should naturally want to make that company the best it can possibly be. Having the space to be open about potential deficiencies and discuss them honestly is extremely important.

However, I'm less convinced about relying heavily on personality assessments for conflict resolution in early-stage startups. In a lean startup environment where each day has meaningful consequences for your trajectory, learning to become open to feedback and express critiques clearly is more important than tailoring approaches to personality types. The shared goal of making the company successful should drive communication, and hiding well-reasoned critiques is counterproductive regardless of personality types.

For Article 4 on scientific literacy, I strongly agree that applying scientific principles to startup development is invaluable. Maintaining the level of evidence needed, operating with healthy mistrust of your own understanding, and subjecting every idea to genuine scrutiny allows the best concepts to emerge. If you're doing everything possible to find flaws in your idea and still can't, then you've either discovered something special or you're still missing something due to bias - either way, this approach leads to better decision-making.

  1. What lessons do you think hold the most value for other aspiring founders reading these essays, or not from reading these essays?

I think the frameworks presented across these articles provide invaluable tools for founders, but there's an even more fundamental lesson: identifying what your goal is and what you need to get there. These frameworks help in that regard by forcing you to completely immerse yourself in your idea to identify the what, how, and why of what you're doing, and then map the steps between your current position and your end goal.

From Article 1, the lessons about cognitive biases are crucial, but only if you implement systematic approaches to counteract them. Regular "consider-the-opposite" sessions and external validation of timelines aren't just academic exercises – they're practical tools that can save months of wasted effort.

Article 2's approach to industry research through thesis statements and evidence-based reasoning is something I wish more founders would adopt. This process transforms vague industry familiarity into actionable insights and can reveal unique opportunities that casual observers would miss.

The lessons from Article 3 about creating psychological safety and shared definitions within founding teams are particularly valuable when founders are friends. The transition from social to professional relationships requires explicit communication frameworks that don't develop naturally.

Article 4's emphasis on scientific literacy provides a decision-making framework that protects founders from attractive but unfounded theories. The learning styles example resonated strongly with me – there are countless "neuromyths" and business fads that seem compelling but lack evidence, and pursuing them wastes precious resources and credibility.

However, not knowing why you're getting into something or having an unclear goal leads to wasteful exploration. The frameworks become most powerful when they're deployed in service of well-defined objectives rather than undirected exploration.

  1. How have your entrepreneurial mindsets or career paths evolved since these events, and in what ways (if any) did this shared journey shape that evolution?

In terms of my own entrepreneurial mindset, I'm incredibly grateful for the experience. Working on our startup taught me about the type of "productive delusion" required to make ideas successful – the ability to simultaneously believe deeply in your vision while subjecting it to rigorous scrutiny. This experience fundamentally changed how I approach work and career planning.

Since then, my experiences have compounded as I've worked as a software engineer across various industries. I'm currently working as a Fullstack engineer at TaxGPT, and throughout this journey, I've deliberately chosen to work only at startups. Once you've experienced the ownership and comprehensive learning that comes with startup environments, it's very difficult to walk away from that. The ability to see how all the pieces fit together and have meaningful impact across the business becomes addictive.

Rather than immediately launching another venture, I've focused on strategically building my technical skillset and domain knowledge. I'm creating a stronger foundation for future entrepreneurial efforts by developing expertise that will serve as a competitive advantage. This approach reflects how I've internalized the lessons from these articles – I'm methodically building expertise (Article 2), maintaining scientific literacy in my technical work (Article 4), and developing collaborative skills across teams (Article 3).

My next goal is definitely to build my own startup once I feel my technical skillset and knowledge have reached the level where I can execute effectively. These formative experiences didn't diminish my entrepreneurial ambitions but rather matured them into a more strategic, prepared approach to company building. I now recognize entrepreneurship not just as a singular event but as a journey requiring deliberate skill development over time