4) Failure to Launch

Behind-the-scenes building Vambrace AI, a company on a mission to forge stronger relationships with users. Subscribe to follow along or visit the site here:

(typos are to make sure you’re paying attention)

Introductory Remarks

Dear Vambracers —

In last week’s post, Mindset, we explored key guiding principles around mindset as I gear up for the early stages of the journey in search of product-market fit. Of course, a critical prerequisite to achieving product-market fit is actually launching a product and so today’s post discusses my failure to launch, general sources of launch anxiety, and a more pseudo-tactical checklist for pre-launch readiness protocols.

Failure to Launch

As background, I initially started ideating Vambrace in early April. I then started building out the platform and exploring the idea space in my free time pretty much nonstop since then—and I’m now at a point where I almost have what I feel is a production-ready product. My original plan was to launch by the end of May, and now my new plan is to launch by mid-June. I’m sad to miss the initial deadline that I set for myself—but I also think it’s been fascinating to experience firsthand the launch anxieties that I’ve admonished in founders that I’ve worked with in the past. Here is what I’ve been ruminating on.

Semi-Legitimate Delays

Robust-adjacent feature-set (or, Being in denial about feature-creep)

I know that it’s easy to experience “feature-creep” and that’s something I’ve had to be honest with myself about, but I also do have some intuition around what I’m looking for in my MVP. And so I think it took me a bit longer than expected to like design and build a feature-set and core flow that I feel is appropriately robust and also relevant enough to be worth someone’s time. There’s some difficulty here for me, because I think there’s a legitimate school of thought that says launch with less and focus really on the single thing that really matters—and if the pain that that single addresses is significant enough then that’s the best sign. And I get that, I really do, but I think also there’s been more of a learning curve for me around language and business impact that I want my core MVP to address.

Maybe to even take a step back, really the core flow of my platform is user interview upload and delete. And then there’s all sorts of backend processing that is triggered by interview upload and delete—but that’s really the core. And so it’s taken me more time than expected to nail a streamlined and efficient processing flow—and it took me awhile to decide on what insights we’d extract as part of that processing.

Honestly, I will admit that, the more I write about this, the more confident I am that I don’t have a good excuse for continuing to stew on my feature-set. It’s pretty much done at this point and honestly has been pretty much done for the past few weeks. Really I’ve been spending time on trying to squeeze out some processing efficiencies so that the UX is a bit more intuitive and also trying to ensure a robust backend infrastructure that behaves as expected throughout the core interview upload and delete flow. But, really, I’m pencils-down now, and I’m not going to try to defend my actions here.

Maybe, the only thing I will say is that, the downside of vibe-coding and these wonderful tools is that I can go from idea to implementation within like 30 minutes—and so I think it’s harder for me to be pencils-down when I can make changes pretty quickly. And so I think that’s something that I’ve had to be cognizant of as I’ve been building. But, again, no real excuse here. I just need to launch.

Integrity of backend processing

A legitimate delay has been ensuring the robustness, security, and behavioral fidelity of my backend. As I described in Let’s Get #Technical the most challenging area of development for me has been building out and understanding the backend. And within the context of launch prep and general structural integrity of the platform this is where I’ve been spending most of my time of late. As I just said in the previous section, I’m pretty much pencils-down on the feature-set at this point and now it’s just a matter of running QA and general usability tests to make sure that the backend behaves as expected—and that’s been trickier than expected.

Carveout: One of the biggest improvements I recently made around internal process with backend checks is I finally figured out how to connect my coding platform (in this case Cursor) with my backend infrastructure (Supabase and Pinecone) through the CLI protocol (not sure if right word) and that’s been a huge unlock. Previously I’d been just using the SQL Editor which was a little bit messy and honestly really difficult to nail. 

The broader takeaways here for me are: 

1. Continue to find high-leverage operational or process shifts that unlock exponential improvements in ease-of-use and general development environment coherence; and 

2. If I keep running into issues around some pre-built code thing (in this case integrating Supabase and Pinecone with Cursor via the CLI thing), then I just need to assume there’s a reason the model keeps trying to do that and then spend time and effort to make it work so that the model can do what it default-wants to do. 

So, to put a bow on this section, backend processing has been more logistically and operationally challenging than expected—and so now that’s the biggest area where I still have to shore up the structural integrity of the platform and make sure all is well on the western front. It’s been such a fun experience, though, to see how all the pieces of software come together to abstract away complexity for users.

The psychology of “launch”

And then I think finally I’ve been contending with pretty normal and human anxieties around this concept of “launch.” I’ve watched many y combinator videos where they explicitly advise founders to not get so in their heads about launch, and in my case I’m not like publicizing the launch or anything and I’m not expecting like millions of users—or for anyone to care really—but I’m still definitely in my head about launch.

First, maybe, I’ll define what “launch” means for me, right now, and that is pretty much complete public unfettered access to the platform (but no active external promotion). As in I’ll actually have login and create account buttons on my landing page and then I’ll do like a $12/month subscription and then also pretty much give everyone the option to use the platform indefinitely for free with the code LETLUKESTARVE and then will just ask them to subscribe to this newsletter or something instead of paying the $12/month. I’m less concerned about revenue right now and more so focused on usage.

[I think maybe next post I’ll talk about how I’m planning to track success, what my guiding KPIs are and how I’ll think about product-market fit—but the initial goal I know is just to get people actually using the thing. If I can get 10 people who LOVE it and can’t live without it, then that’s a more positive signal than 1,000 people who have signed up but are meh on it.]

But, to get back to psychology here, I think the actual concept of “launch” and putting something out there for people to use is fundamentally pretty scary. It’s a vulnerable thing to do. And I think that’s also why it’s so exciting. But I think I’m just dealing with more difficulty in actually fearlessly taking that leap than expected. And I think there’s also a lot of anxiety and insecurity around, like, I know this isn’t good enough, but now I’ll have people telling me why it isn’t good enough, and all that I haven’t thought about. And this gets back to last week’s mindset post about being like 90% wrong, and being okay with that. But it’s harder to stomach when others affirm your 90% wrongness, and maybe even think you’re 95% wrong. It’s just scary!

I know I need to shift mindset a bit here around, like, the MVP is really just the start of a conversation with the market—and opening salvo, a pilot episode, an EP—and so I need to keep reminding myself that and not let myself overthink it. I can’t think of any artists who released a hit single with the first song they ever made. And so why would I expect to do the functional equivalent of that within B2B SAAS?

But, to inarticulately put a fine point on all of this: actually launching is psychologically hard—more so than expected—and it’s easier to be “launching in a few weeks” than to have actually put something out there. And I just need to stop being so in my head and launch the thing.

Focus, focus… wait, what was I just doing??… oh, right, focus

[Okay, so I almost forgot to fill out this section, which would have actually served the purpose of the section—in the same way that a bowl’s key function is made possible by the absence of matter. I don’t know if that makes any sense, but I think it tracks.]

The last semi-legitimate challenge has just been remaining focused and diligent in my own personal operations given that it feels like there’s so much that I haven’t done yet and so much that I might be overlooking and so much that I could be doing at any given moment that I think it can be difficult to really lock in and just take things one step at a time and just keep moving forward. And then I face normal attention challenges going from task-to-task and stuff. I think it’s all pretty normal, probably, but something that I’m thinking about and trying to improve.

Especially given that the nature of AI is that you submit a prompt and then kind of wait a little bit for it to execute, and so you can click out of Cursor after giving it a prompt, and then you can get distracted before going back in. But, alas, with any great new technology comes great new pros and cons.

Legitimate Pre-Launch Checklist

Despite the foregoing, here are some pretty legitimate things that I do feel compelled to submit to thorough intellectual and technological examination prior to launch.

Internal metrics tracking

When I do launch, I need to make sure that I have semi-robust systems in place to actually measure usage and see if people are actually using the platform and all and measure growth and find like power users and stuff like that (hopefully). And so I didn’t realize that there is work that has to go into just creating the internal like monitoring dashboards and KPI collection functions in place within the backend to calculate, monitor, and track performance there over time.

I have a fairly simple yet robust-enough system in place right now which tracks like aggregate KPIs across the platform and then I’m also building some edge functions within Supabase directly to do like daily and weekly KPI calculations so that I can spot trends over time. I’m still ironing this out, though, so will report back on how it actually goes.

Onboarding filters for success

A small but important thing I think is to proactively filter out initial users to folks who are most likely to actually benefit from the platform. I know this might bias the results a little bit, but isn’t the point of business to do things that bias the results in your favor? Because, really, I’m not trying to run some statistically fair test here on the overall suitability of my platform for a general population. I’m trying to find the individuals most likely to actually use and benefit from my platform and then do everything in my power to become a critical additive piece of their tech stack.

I do acknowledge that there is a balance here, however, and so in my case the function I’m pretty much running is: optimize suitability for platform while minimizing onboarding friction (which literally means like time-to-insights, in seconds). For me, this means that I’m going to ask users when they press on the sign-up button if they conduct user interviews and if they have transcripts available to upload. The magic of the platform comes from uploading transcripts, and so I just think at this point in time we need to focus on users who are already mostly in the habit of recording user interviews and storing transcripts—or who don’t mind starting to do that more consistently.

There will of course be an option for users who don’t currently do this to join the platform and I’m going to have like a pre-created interview transcript that they can choose to “upload” so that they can see the insights the platform offers and then make some determination of whether or not they’d like to start interviewing users and saving those transcripts.

I guess, really, what I’m trying to say here is that: I know that there will be a lot of friction within the initial version of the platform, and I’m doing my best to pick the lowest hanging fruit off that friction-tree, but I know I can’t reach all the fruit. But, I have to embrace the counterintuitive fact that it’s actually good for there to be some friction in the beginning stages because if users are willing to use my platform despite the friction then that means the pain I’m addressing is significant enough for them to endure the friction. It’s a bit counterintuitive but also I think logical.

Security checks (and figuring those out)

An area that I really don’t want to skimp on is security—and this is also an area where I’m definitely not super well-versed so I do need to spend time here and scrape resources to understand how I can make the platform appropriately secure for an MVP. I don’t think I’m anywhere near SOC-2 compliance or whatever other high level security things are required for enterprise-level products. But I do need to make sure that my API keys are all hidden and safe and that user information is appropriately siphoned-off and like all of that good stuff.

I’ve saved some twitter threads that give some context here and then also going to see what Mr. Chat has to say and will probably do some light-level Deep Research type stuff with complexity and/or Gemini to understand what else I have to be wary of. I also do have to balance the need for appropriate security measures without stressing too too much about it all—because, honestly, I’m just trying to get the thing launched and I don’t think early adopters will care all that much about security—so long as I’ve got the basic security features covered.

Production and development environments (and database duplication)

Another area where I really have to build some muscle (s/o Steve Ballmer) is understanding the flow of like production, testing, and development environments. This is why I’m happy that I just got the database CLI stuff working because I think that will help me manage this process—but I’m just fearful of that which I do not know—which, in this case, is how do I actually like replicate my backend infrastructure perfectly for my production app and then continue to iterate and test in my development environment—and then eventually launch those updates into the production environment without ruining and/or losing any existing user data?

I do think this is an area where I have to get some comfort around the fact that there are most assuredly very reliable and straightforward ways of handling this, as software developers / engineers have probably been doing for decades, and so I know that it’s figure-out-able. It just feels very significant and scary at the current moment. I do know that different environment variables become important here and then being very diligent in like appropriate code branching within GitHub and making sure that I only push like a production branch to Vercel or whatever and then use the right Supabase and Pinecone keys and stuff. But it’s all just still intellectually amorphous to me and so I need to get practical about it and just trudge forward. It will be ugly before it’s pretty.

Firm foundation for future iteration

The last thing I’ll mention here that is a constant anxiety leading up to launch is just making sure that I’m not overlooking anything super obvious that will be a huge headache in the future. I think this relates to the general concept of not knowing what you don’t know—and there’s just a lot that I don’t know right now. So I think the back of my mind is constantly trying to think about things that I might be overlooking that are mission-critical that will cause a lot of pain in the future. This is probably another area where I’ll do some thorough Q&A with ChatGPT and Perplexity and Gemini—the #councilofchat—and give it an authentic good faith go and then just kind of relinquish control and accept whatever fate I unknowingly seal for my future self. And that’s showbiz, baby!

Looking Forward

I promise that, sooner rather than later, I will stop talking about launch and will actually be launched and can provide some more substantive discussion around GTM and early user acquisition and stuff like that. But the purpose of today’s post was to deconstruct some of the psychological self-manipulation that is probably pretty typical of any first-time founder journey.

Thanks for reading along and I hope you have a wonderful and action-oriented week!

Sincerely,

Luke