In the following exchange, Onboardbase’s founder, Dante Lex (@dantelex), recounts having to pivot for a reason that often goes unmentioned: lacking the right resources that certain startup ideas demand from the outset.
He also discusses the harsh fundraising market, the urgency of being Default Alive, the unexpectedly arduous enterprise of building after landing the first few paying customers, and what it takes to bring a dev-focused security product to market.
— The 2 reasons that informed their pivot
— Why early validation isn’t nearly enough
— The Default Alive goal
— Why founders should be wiser about adopting free tools
— How all roles at Onboardbase begin with mastering security
— Selling to a most discerning persona: engineering leaders
The 2 reasons that informed their pivot
Before Onboardbase, I worked on a SaaS management solution (Billisimo). Its promise was compelling enough: Help people save thousands today, millions tomorrow.
But we had to pivot.
Because 1) we found out that the target audience (SMBs and startups) we were hoping to start with (that most B2B startups hope to sell to at first) did not care enough to pay for a solution like ours.
As early-stage companies use very few tools. Many of them are accessible for free, thanks to discounts from accelerators, Google, AWS, and the rest of the ecosystem. They simply don’t have enough tools to manage.
Then 2) at the higher end of that market where money was to be made, the barrier to entry was relatively high due to the existing competition (with millions in funding and miles ahead of us). We had to stand out. We needed a novel approach.
The only way to differentiate meaningfully seemed to integrate directly with SaaS products that needed managing. A single platform would allow you to perform actions such as removing/updating seats across your SaaS suite.
There were only a handful of solutions to this at the time.
But building it out required a lot of engineering effort. At the same time, we were just a team of 3 with no funding and no access to an industry network. That’s why we held full-time jobs during the day and built our own thing at night.
We decided to abandon that idea and continue talking to people who had shown some interest in identifying other pain points we could tackle. Only to stumble upon a personal problem. Something I had to solve at my day job as an engineering lead at a startup.
Why early validation isn’t nearly enough
Whenever a new teammate joined, we shared environment variables and keys over Slack/email. This wasn’t secure. My security-first mind was always nudging me not to, but my speed-first mind was like, “Ah, let’s just do this quick and get on with the work.”
Even our startup team of 3 had this problem.
I tried finding a solution and came across HashiCorp Vault.
They had a fantastic tool with some fundamental problems.
-
It was super hard to set up. You had to have a lot of engineering work done or knowledge to get started, which could take anywhere from 3 weeks to more than a month, depending on your engineering capacity.
-
It wasn’t collaborative. From what I have learned working with developers, you need those collaborative features for security to be adequate. Devs can get creative around such constraints, but why couldn’t we build something as easy as Slack?
We started pursuing this idea.
We spoke with those early Billisimo users about how they were managing their secrets. To our surprise, most of them copied and pasted them all around Slack, email, and, worst, even WhatsApp.
Or they had to rely on some combinations of GitHub secrets, their codebase, or AWS. Several solutions weren’t practical and didn’t translate into safe workflows.
We started building a tool to handle secret credentials for all teams but slowly began to niche down to developer-specific secrets. On average, devs shared way more of those than anyone within the workplace.
Thus, Onboardbase became a central security system plugged into your workspace and deployment systems. Pushing critical info via secure pipelines and in real time.
We built it fast.
Writing the first line of code around December ‘21 and beginning testing with real customers. We got into an accelerator (ODX by On Deck) and raised a pre-seed of $125K.
We had felt that thanks to all this validation, things were to go smoothly thereon.
We were wrong.
Validating an MVP wasn’t enough. Those paying customers quickly started requesting features to distribute better, analyze usage, and more. We had to build a more robust platform as fast as we could.
We even lost some of those first users because of our pace and needing more bandwidth to build for an unexpectedly demanding roadmap. We learned our lessons and have grown more stable and efficient since, continuously course-correcting with beta users.
We are serving around 350 customers today.
Right now, we’re not too focused on the product and are actively scaling our reach. With a launch planned soon, we want to sell more to folks (CTOs, engineering leads, DevOps teams) at medium-sized enterprise companies that prove very hard to sell to.
But we have to keep at it.
The Default Alive goal
Customers paying for products is the best way to grow.
Especially given the market conditions, fundraising hasn’t been going well.
We started the process in December last year, paused for the holidays, and kicked it off again in March. People who initially committed have defaulted because of the economy. We can’t fault them for that. But we’ve got some checks in.
We still need more to come in.
Until then, the only alternative is to fund our journey from the revenue we generate and get to Default Alive. Being profitable will give us the time, focus, and energy to continue building without waiting on investors for years.
That’s been our goal.
We want to close bigger deals and carry on the investor conversations on the side.
Although, we’ll continue offering a free plan even when we target more and more upmarket segments.
Infrastructure solutions should all be accessible for free. Because the individual developers of today, no matter the size of their company, will start (or join) startups tomorrow. They need to be able to deploy tools for side projects and initiate word of mouth within their networks.
Why founders should be wiser about adopting free tools
A related tip on the Default Alive bit is about how we manage costs. Given the nature of our product, we use a multi-cloud infrastructure spread between AWS, GCP, and DigitalOcean. So that we rarely go down due to a single point of failure.
A lot of these infra tools also come with free credits, but founders shouldn’t just choose them for that reason. The credits will eventually run out, and you will incur huge expenses. And you want to avoid making a switch while scaling.
Before jumping on to any of these tools for their discounts/credits, you need to plan and ask consciously: Will I be able to pay consistently whenever the actual price kicks in?
Only a few founders ask/answer that question.
How all roles at Onboardbase begin with mastering security
We’ve learned this over time, but security needs to be first for a solution like ours. Always! And it needs to be owned by every single Onboardbase employee.
In the sense that you aren’t just a product manager here. You are a security engineer that does product management. You’re a security engineer who does customer success. You’re a security engineer who does sales.
That’s our first ask for anyone who joins the team.
We all must be grounded in security to perform our jobs well. There’s focused training that we require all teammates to undergo, and we seek out those with a background in security or the capability of learning.
Having that necessary grounding as a team is how we communicate that security can’t be left for later and must be solved for yesterday. It’s how we can inform them that shipping fast doesn’t have to come at the cost of bypassing/overlooking security.
Selling to a most discerning persona: engineering leaders
As I noted above, while developers are often the first users and the ones who refer us within a team, we sell to CTOs or engineering leads, as they’re responsible for managing vulnerabilities, securing pipelines, and ensuring that nothing is being spilled.
And pitching these people (I’m one of them :)) on anything isn’t always a straightforward idea.
As an engineer, if I adopt a tool, a friend must recommend it to me, or I need to read about it somewhere. So the approaches that have worked for driving discovery are getting referrals by continually investing in the product and publishing dev-first content on the blog.
If you read our blog, even if you aren’t using Onboardbase, you can always pick up a security practice or two to implement within your workflow.
Our blog is among the few that focus on such subjects.
And we are already seeing a ripple effect of getting 10K targeted visitors each month.
Regarding the proposition the target audience needs to buy into, we’re up against the status quo. It’s normal for them to do things a certain way. Sharing keys on Slack is recognized (like eating carbohydrates :)) though not ideal, it remains everyday behavior.
Security’s prominence as an issue only surfaces during an actual breach.
This is true across small and big teams.
Then, people also tend to view solving for security as a stage-specific, resource-draining exercise to be addressed when their teams scale.
Companies implementing Onboardbase get a secure-by-default, accessible, and collaborative approach as they scale.
Related reading from the Relay archives:
— Eduflow’s co-founder, David Kofoed Wind, on pivoting despite PMF
— Contenda’s co-founder, Lilly Chen, on the enterprise builder’s dilemma
Especially notes on navigating the most difficult parts of building in the current environment.