Choosing the Right Systems For Your Startup

In this post we talk about how to choose the right initial systems for your growing startup.

Choosing the Right Systems For Your Startup

When starting your business, you need some core systems; choosing the correct ones can set you up for success. We started from scratch when we started DevRev, which was a very empowering moment as it’s genuinely a “green-field” moment with unlimited flexibility (and long-term consequences).

This post will cover some of our chosen systems and the considerations that led us to those conclusions.

Where To Focus

The core systems come down to the type of business you are in; however, for a SaaS company, the following systems were necessary to get us started:

  • Core
    • HRIS
    • Identity/IdP
    • Payroll
    • Accounting
    • Git/SCM
    • Work management
  • Collaboration
    • Mail
    • Messaging
    • Conferencing
  • Hosting
    • Website
    • DNS/Domains

I didn’t include any infrastructure hosting services we leveraged, as those came later and deserve their own post!

What We Choose And Why

At 3+ years in, we are running the same stack we chose initially, and it’s been working flawlessly.

Here’s what we chose:

  • Core
    • HRIS → BambooHR
    • Identity/IdP → Okta
    • Banking → Brex
    • Payroll → Gusto
    • Accounting → Xero
    • Git/SCM → GitHub
    • Work management → DevRev (obv.)
  • Collaboration
    • Mail → Gsuite
    • Messaging → Slack
    • Conferencing → Zoom/Gsuite
  • Hosting
    • Website → Vercel
    • DNS/Domains → GoDaddy (pre me) then Route 53

The following figure shows a high-level overview of these systems and some flows between them:

DevRev Operate

When configuring this 3+ years ago, we set it up so that everything flows from BambooHR to Okta to all other systems. This means BambooHR is the primary system of record for employees and drives Okta, which in turn drives all other applications. This has worked beautifully and has truly been something we have “set it and forget it.”

HRIS → BambooHR

What is it? An HRIS (human resources information system) is a system that keeps track of all of your employee records and information. It contains vital information like employee IDs, start dates, job history, and many other metrics.

What should you look for?

  • Integration with your preferred IdP
  • APIs for extensibility
  • Required compliance and regulations (this will vary by your business)
  • Payroll integration (nice to have)

What did we choose? BambooHR

Why did we choose this? This one was pretty simple as we were way to small for Workday and the pricing was way too high. BambooHR was priced per user, pricing was good, and they had an integration with our IdP (Okta) which was likely the most essential factor.

Did we actually need an HRIS as a startup? Yes, once you hiring more than founders. At Nutanix, there was no HRIS when I joined, and years after being employed, HR reached out to me to get a copy of my offer letter (yikes).

Conclusion: Once you start hiring non-founders, get an HRIS.

What would we have done differently? Nothing, been impressed with this so far.

Identity/IdP → Okta

What is it? An identity or IdP service is something used for handling authentication. Traditionally these were primarily Active Directory, Redius, or LDAP, however, these have been modernized with Azure AD (well “modernized”) and Okta.

What should you look for?

  • Integrations with our HRIS
  • Integrations with planned apps
  • SAML/OIDC support (all IdP should support this)
  • Scalability
  • SLAs/Uptime
  • Compliance
  • Support

What did we choose? Okta

Why did we choose this? Having worked with Active Directory in some semblance for the past 20+ years, I was very familiar with its functionality and problems. We needed something that was flexible, scalable, and wasn’t built using 20+ year old constructs (Azure AD is still AD).

What did we need?

  • Automated integration with our HRIS for user provisioning during onboarding
  • Ability to federate auth to a variety of different services across vendors
  • Something I could set and forget

We set up BambooHR to be our profile master for Okta, meaning it was the authoritative source of truth for user information; this was a thing of beauty. In 3+ years I haven’t really had to touch this at all.

When a user’s start date is approaching, we have a pre-start buffer we use to pull the employee into Okta (this also works for job changes). Within 5 days of starting, the user is provisioned into Okta and all of their other accounts are provisioned. The email set in BambooHR is used to specify the login to Okta and the primary email the GSuite integration provisions. They get an email to their personal email to configure their Okta account, and voila they have access to all systems they need (well mostly all of them).

Conclusion: Choose an IdP in tandem with your HRIS.

What would we have done differently? Nothing, been impressed with this so far.

Banking → Brex

What is it? Keeping your money safe is crucial for all businesses. This became even more apparent with the failures of SVB and First Republic banks this year. A bank does just what you think, it keeps your money for the business and can be an important part of lending as well.

What should you look for?

  • Insurance limits
  • How leveraged they are (this is key as a bank run can kill the bank)
  • APIs
  • Integrations with other tools (e.g., payroll, expense, etc.)
  • Reporting and visibility

What did we choose? Brex

Why did we choose this? This was a little bit of a bet given that Brex is a fully virtual bank (e.g., no retail locations); however, it has worked out quite well so far. Provisioning cards is simple, reporting is great, and it has APIs we’ve integrated with.

What would we have done differently? Nothing, been impressed with this so far; however, this one was a little surprising.

Mail → Google Workspace (Gsuite)

What is it? Email and collaboration.

What should you look for?

  • SCIM provisioning via IdP
  • Pricing and model

What did we choose? Google Workspace (Gsuite)

Why did we choose this? As mentioned in the IdP section above, I’ve worked a lot with Exchange, Sharepoint, and other Microsoft products and I like the simplicity of the Google Workspace solution. Does it have all of the features of Microsoft 360? No, but it gives us enough of what we need and integrates beautifully with Okta. If we had gone Azure AD on the IdP front, that obviously would have impacted this choice.

What would we have done differently? Nothing, been impressed with this so far.

Source Control → GitHub

What is it? Source control (typically Git), is a system used to lifecycle and store source code and other data.

What should you look for?

  • IdP integration for authentication
  • Groups synchronization
  • CI/CD integrations
  • Usability
  • Data protections
  • Compliance

What did we choose? Github

Why did we choose this? For hosted Git solutions there’s really two core options: GitHub and GitLab, GitHub being the largest by a far cry even though GitLab has some cool features.

With Github we could integrate natively into Okta for SSO and SCIM based user provisioning. As users are onboarded into Okta, and based upon their department (e.g. Engineering), it will automatically invite the users to our organization in GitHub.

We then have IdP synchronization for groups which repo access is mapped to. So as users changes groups, their privileges and visibility can change without us having to re-configure anything on the GitHub side.

What would we have done differently? Nothing, been impressed with this so far.

Work Management → DevRev

What is it? Work management (e.g., JIRA, Trello, Linear, DevRev, etc.), is a system used to track and plan work items. This is primarily important for engineering teams early as as you need to roadmap and plan execution across engineers.

What should you look for?

  • IdP integration for authentication
  • Groups synchronization
  • Customization
  • Simplicity

What did we choose? DevRev

Why did we choose this? One of the core pillars of the DevRev platform is work so we worked to build what we would eventually use. Previously, we had used JIRA for 10+ years at our previous companies, and while we could have used that when building DevRev, we decided to not as it would force us to build fast so we could start leveraging.

We currently run 100% of our build, operate, support and grow on our platform. This is key as we need to “feel the pain” to ensure we build something truly amazing.

What would we have done differently? Nothing, we are building the tool we are using.

essential