Staybit was a SaaS product I built to help companies onboard, offboard, and manage employee access across the tools they use every day.
The idea came from a problem I experienced while working as VP of Engineering at SkydropX. The company was growing quickly across engineering, sales, support, and other departments. HR created the corporate email for new employees, but after that, each team was responsible for giving people access to the tools they needed.
Some teams had a checklist. Others had no formal process at all.
That meant new employees sometimes had to request access one app at a time, delaying their onboarding and creating unnecessary friction from day one. There was no central place to see which apps someone needed, which ones had already been provisioned, and which ones were still missing.
Staybit came from that pain.
I wanted to build a product that helped companies answer a simple but important question:
Who has access to what?
What I built
Staybit was designed as a platform for employee app provisioning and deprovisioning.
The goal was to let companies connect the tools they already used, define which apps employees should have access to, and manage onboarding and offboarding from one place.
Some of the core ideas included:
- Employee onboarding and offboarding workflows
- App provisioning and deprovisioning
- Integrations with common SaaS tools
- Visibility into who had access to what
- Audit-friendly records of access changes
- A central dashboard for managing employee access
I wanted Staybit to feel like a practical tool for growing companies: not as heavy as an enterprise identity platform, but serious enough to solve a real operational and security problem.
Why I built it
Every company eventually becomes a collection of tools.
There is a tool for communication, a tool for code, a tool for design, a tool for sales, a tool for support, a tool for documentation, a tool for analytics, and then a few more tools nobody remembers approving.
That is manageable when the team is small. But as the company grows, access management becomes fragile.
A new employee joins, and someone has to remember every app they need. Someone changes roles, and their access may need to change. Someone leaves, and the company needs to make sure access is removed quickly and reliably.
This is not glamorous software, but it matters.
Bad access management creates security risk, operational friction, and unnecessary manual work. Staybit was my attempt to make app access feel less like a scattered checklist and more like a system.
The hard part: integrations
The biggest challenge with Staybit was integration coverage.
For a product like this to make sense, it needs to cover a company’s core tools. If Staybit supported GitHub but the company used GitLab, it did not solve their problem. If it supported Intercom but the company used ServiceNow, it did not solve their problem. If it covered five tools but onboarding depended on twelve, the value was incomplete.
In this category, the missing integration is often the one that breaks the workflow.
That made the MVP much harder than I expected.
I was not just building one SaaS product. I was building a product that needed to connect to many other products before it could fully deliver its promise.
And every integration had its own problems: OAuth flows, permissions, rate limits, edge cases, expired tokens, incomplete APIs, and different models for users and roles.
Some tools made basic actions surprisingly difficult. A few required an enterprise plan to create or manage users through the API. Others did not expose the actions I needed at all.
I considered workarounds.
One option was using headless browser automation to log into third-party tools and perform actions through the UI. Technically, that could have unlocked more apps, but it also felt risky. Staybit would have needed broad access to a customer’s admin interface, which created obvious security and trust concerns.
Another option was to show “pending tasks” when an integration could not complete an action automatically. That was safer, but it diluted the main promise of the product: click a button and onboard or offboard an employee automatically.
That tension was difficult.
Staybit needed automation to be valuable, but automation depended on APIs I did not control.
What I learned
Staybit taught me that a real problem is not enough.
The pain was real. I had experienced it myself. Other companies experienced it too. But the product still needed the right customer, the right wedge, the right distribution strategy, and enough trust for companies to let an early-stage product touch sensitive internal workflows.
The target customer was also narrower than I initially expected.
A company needed to be large enough to feel the pain of fragmented onboarding and offboarding, with enough employees, tools, and employee rotation for the problem to matter. But if the company was too large, it probably needed an enterprise solution like Okta.
The ideal customer was probably a growing startup or mid-sized company that had outgrown manual access management but had not yet adopted a heavy enterprise platform.
In retrospect, I should have found one or two committed first customers before building so much of the product. Then I could have built the integration stack around their actual tools, their actual onboarding process, and their actual buying motivations.
Instead, I was trying to build something that could fit every startup.
That is a very expensive place to start.
The user and the buyer
Staybit also taught me an important B2B lesson: the user and the buyer are not always the same person.
The main user of Staybit would probably have been an IT manager or operations person responsible for managing employee access.
But the buyer might have been the HR lead, a founder, or an executive.
That distinction matters.
The product needed to work beautifully for the person doing the actual provisioning and deprovisioning. But the marketing needed to communicate value to the person responsible for budget, risk, onboarding, security, or operational efficiency.
Same product. Different motivations.
Competition and timing
Some potential customers I interviewed were already using other tools. When I looked at those competitors, their integration catalogs were years ahead. Some had more than 200 integrations already built.
Meanwhile, I was still struggling to finish the first 10.
That was humbling.
It did not mean the idea was bad. It meant the category had a high execution bar.
Staybit was also built before AI agents became common in software development. At the time, coding each integration could take me several weeks. Today, with a well-structured prompt, an AI coding agent could help build a lot of the integration boilerplate much faster.
That does not remove the hard parts. You still need to understand the API, test edge cases, handle authentication, and make the integration reliable.
But the economics of building integration-heavy products are changing.
Current status
Staybit is currently paused.
After working on it, I shifted my focus to other products, including LastRelease and later Consultorial.
But Staybit remains one of the most important projects I have built. It forced me to think seriously about B2B SaaS, integrations, security, onboarding, trust, and the difference between building software and building a business.
It also changed how I think about MVPs.
Sometimes an MVP can be small because the product category allows it.
Other times, the minimum version required to deliver the promise is much larger than expected.
Staybit was in the second category.
Looking back
I still believe the problem Staybit tried to solve is real.
Companies keep adopting more software, not less. Employees join, move, and leave. Access needs to be granted, reviewed, changed, and removed. The operational burden does not disappear just because the company is small.
But Staybit taught me that a real problem is not the same thing as a simple go-to-market path.
The product needed a sharper initial customer, a clearer wedge, a faster path to value, and a more focused integration strategy.
Staybit was a product about access.
In the process, it taught me a lot about focus.