Building a SaaS company as a non-technical co-founder
Look, you’re not signing up for GuardianUI because I had anything to do with our tech, and frankly, you’re probably not using our product because I’m involved with the company at all. My job is to support the giga-chad GuardianUI team that’s pioneering a new form of E2E testing and monitoring by helping with all the non-technical, business stuff.
All that said, I bring a decent amount of experience building businesses in both an entrepreneurial and corporate setting. I’ve never built a B2B SaaS company though — so GuardianUI is an exciting new challenge.
Even though we’ve been creating the predecessor to GuardianUI over the last few months, I recently decided I’d start building more in public to share my learnings. TBD if any of it’s useful to people - or if anyone but my wife will read this - but time will tell.
Several weeks ago, we pivoted our original idea (called “ELSYN”) into its current version, which we now call GuardianUI.
Here’s some of my process/thinking since we made that move.
WTF is ‘E2E Testing’
Let’s be honest, if you asked me three months ago what “E2E Testing” stood for, I would have had no clue. I obviously understand the concept of GuardianUI’s product and its importance relative to how it provides meaningful value to web3 teams, and more importantly helps protect web3 users. I could explain it narrative form, but I had no idea how end-to-end testing worked under the hood (still don’t, but at least now know it’s a thing).
It took the sharp minds of Lienid, Brightiron, and Ivelin to show me the light and ELI5 it so I could grasp the core concepts of how our testing framework would work and where our solution fits in relative to other web3 security companies. I still ask dumb questions daily — but I’m okay being dumb. It’s how I learn. Step 1 was (is?) understanding how our product works at a deep level AND how it’s positioned in the market.
We think GuardianUI has quite a bit of white space to play in, but just because you discover your product is in a crowded market doesn’t mean you shouldn’t move ahead. It just means you need to be thoughtful and intentional about how you’ll stand out from the crowd (e.g. service, price, etc.). Why should a customer chose you over the incumbents?
I get pretty obsessive and typically look for adjacencies to help inform my research and spark my (limited) creativity. Here it was pretty obvious because E2E testing is extremely common in web2 so I’ve spent several hours watching YouTube videos and learning about web2 providers in order to draw analogies between their businesses and what ours could be. I’m also going deep on the other companies on the above chart to get sharper and more articulate on the differences between them and us.
Getting Organized
If you’ve built a startup, you know it’s chaos 24 x 7, and it’s all-hands-on-deck at all times. There’s so much that needs to get done before we launch that it can get overwhelming quickly — especially if you don’t have a reasonably clear picture of everything. To exacerbate things, we’ve intentionally decided to bootstrap the business for now, which means it’s an extremely small team wearing many different hats as we all push towards launch while moonlighting.
There’s always “unknown unknowns,” but I like to map out everything I can think of that needs to get done pre-launch, prioritize them, and assign an owner to each. This is EVERYTHING. It helps me ‘see the board’ even if the board is a bit daunting. So anything from creating the twitter account, to building a pitch deck, to determining the cap table, to finalizing the testing framework and everything in between.
We’ve used notion for most of the non-technical tasks and documentation and github projects for all engineering related tasks. I prefer a kanban board because my monkey brain finds satisfaction moving cards from left to right until they end up in their final resting place: the DONE column.
Figuring Out the Cap Table
This one is uncomfortable and can get messy — but it’s the reason Ivelin and I (along with many others) co-founded and are working on Sporos DAO. Sporos enables projects to leverage sweat equity so peoples’ ownership % depends on the ongoing value they provide to the company relative to everyone else. We’ll be applying these same ‘sweat equity’ principles to GuardianUI’s founding team.
I’ve been on previous founding teams where things weren’t in writing or a sweat equity system wasn’t in place. That ends in dissatisfaction or conflict 9 times out of 10.
I co-founded one business years ago where the four founders had a handshake agreement on the equity split, but nothing was in writing. One of the other founders and I worked tirelessly for 6 months pre-launch, while the other founders took more passive roles. In the 11th hour before we went live, the other two founders wanted to change the equity splits (in their favor )— which caused an irreparable rift in our professional relationships. We ended up agreeing to all walk away from the business because it was too difficult to mend fences.
My strong recommendation is have the hard conversations with your co-founders up front on how the cap table will be divided and get things in writing. Better yet, use a form of sweat equity so the cap table stays dynamic based on who’s continuing to show up and contributing real value. Take a look at what we’re doing with Sporos if you’re interested in utilizing on-chain sweat equity.
Getting User Feedback
I’ve been in an embarrassing number of companies / projects that take the “build it and they will come” mentality. Some of those were my own subconscious narcism thinking I knew what the market/customer wants. Many of them were while working on projects under the direction of others while I was employed by larger companies.
You may know what the market wants and how they’d value it, but odds are you’re 80% wrong. That’s why everything we’re doing right now is wholly focused on preparing ourselves to start approaching prospective users for feedback. There’s nothing worse than spending a bunch of time, energy, and resources building a product/business that nobody wanted in the first place.
I guess we’ll see with GuardianUI, but I’d rather prospective customers tell us now so we can address any concerns vs. launch with our heads in the sand. Speaking of, our waitlist is here, and we’d love to chat with you if you’re a web3 project that wants to monitor your app’s live frontend to make sure it’s creating the correct smart contract interactions for users.
I’m fortunate to be teaming up with a dynamic group of guys who are not only great developers but have also built businesses before as well. While I haven’t needed to shoulder all of this by myself by any means, these are a few of the foundational areas in the early-stages of GuardianUI where I’m able to plug in and add value.
In my experience, founders often take some of these things for granted or are unaware of their importance — hence why I’ve highlighted them here.
Come join us on twitter and follow along as we build this thing. Should be fun.
About GuardianUI
GuardianUI is the testing and monitoring platform for web3 frontends. Our SaaS platform integrates and automates end-to-end testing, application performance monitoring for web3 critical paths, and real-time alerting and observability to ensure deployed applications create the expected smart contract interactions for users.
