authentik is an open source Identity Provider that unifies your identity needs into a single platform, replacing Okta, Active Directory, and auth0. Authentik Security is a public benefit company building on top of the open source project.

---

“How to be great? Just be good, repeatably.”

Consistency is often credited as more important to success than bursts of inspiration. However when we’re talking about startups, standardization and innovation are often presented as conflicting mindsets. Standardization is for scaleups and enterprises, introduced around the same time as red tape and bureaucracy. Innovation is for scrappy startups, along with “move fast and break things” and “do things that don’t scale”.

Authentik Security is just over a year old, you can still count our team members on your hands, and we do a bit of both. Here are some things we’ve standardized that have helped us be more efficient (and where we’ve kept things fluid).

Where we’ve standardized

Release management

Standardizing our release process is something we touched on before, but as it’s such a big shift we want to give some more details here.

Authentik Security, the company built on top of authentik the open source project, is a little over a year old. With a full-time team working on new features and improvements, we were shipping bigger releases. We had a loose monthly cadence, but shifted to around every three months, after our Discord users replied to our community poll and expressed a desire for more time between releases.

In our early days, the team didn’t always know exactly when a new release might go out until close to the end of the month, when we threw together a release date. This lack of predictability made it harder for the rest of the team to help out with testing, docs reviews, useability testing, and so on. Marketing and promotion of new releases was something of an afterthought. We weren’t operating as a single unit in support of making releases smooth and impactful.

Switching to a more predictable timeframe and, most importantly, implementing a release checklist was a big step forward in maturity. The checklist reminds us of all the very many minor steps that have to happen before a release. Along with the checklist, we now have:

• A target release date to work towards
• Standing meetings and communications about release readiness
• A release candidate build for the team and community to help out with testing
• Documentation written and tech reviewed in parallel with the code
• Time to prepare marketing launch activities

With the increased structure, the team now feels like a cohesive unit, working together in service of successful releases.

Change management

Our security engineer implemented a change control process, for when we add new tools, or change processes, or move content and code to different repos. Change management is likely not a top priority for most companies until they reach a certain scale, but as a security company we’ve tried to implement good security posture from the outset. These types of processes are often easier to start when small than impose later (when you have a bigger team that’s used to doing things differently).

“At Y Combinator we still only have four people, so we try to standardize everything.” — Paul Graham, The Future of Web Startups (2007)

Naming conventions

Pull requests

We use a naming convention for our pull requests that reflects the directory path of the file that’s changed. Currently, this mainly helps with the  generated portion of our Release Notes: the exact directory path dictates the sorting order of the item as it appears in the Release Notes.

This practice also helps when reviewing a long list of PRs, since it makes it easy to see at a glance what area of the codebase the PR touches. In the future, we plan to use even more automation; for example, if a PR has a certain element in its title, we can automatically create a patch build for a breaking change.

Infrastructure

Everything in infrastructure needs a name, but it’s just not realistic to have one standard for naming infrastructure elements—any naming standard goes out the window as soon as you're tired of writing names that must adhere to a ridiculous lengthy number of characters, or on the opposite side, restricted  by a DNS character limit.

However, depending on the context, we do try to apply certain standards. For example, we make deployments repeatable with bash scripts and YAML files (that, in turn, template other YAML files). Even the fundamentals of selecting our tooling and internal processes is another version of standardization; as a team we standardize on certain tools and workflows in order to reduce churn and increase productivity.

Frontend development

Code quality on the front-end is enforced by a variety of standard industry tools, including fairly strict configurations for TypeScript, ESLint, Prettier, and we even spellcheck our comments with CodeSpell.

Our front-end is written with the Lit-Element framework, and we adhere the Web Component Best Practices whenever possible.

We will be providing a test harness for our custom elements and aggregate components in the near future. When these are present, we will provide a Storybook story and Mocha test for each of them. We ask that contributors do the same.

Documentation

Documentation is an important area for standardization and templatizing. Over the past decade, technical documentation has finally become recognized as part of the product, indeed an essential part of the product. Documentation also contributes to SEO for the company, helping to drive discovery and engagement. The more powerful (shall we say feature-rich?) the software becomes, the better the docs need to be. This is where using some standards and templates can be really powerful. There are three primary areas where we use standardization in documentation:

• We use templates for both our regular docs and for any Integrations that community members want to add. We have separate templates for the different types of documentation: conceptual (the “why” content), procedural (the “how to” steps), and reference (those values and params you need to know).
• Using a Style Guide is another important method for strengthening content through standardization. Using standards such as bold text for UI components, italics for variables, and courier font for code snippets makes it easier to move through documentation and absorb the important information.
• A third example of using standardization is docs is having good information architecture in our documentation. That means structuring our docs to make it easy to find conceptual information about what features do, common use cases, and opinionated best practices, without cluttering the procedural information.

Team hardware

While we don’t go so far as to require approval for installing new software on company machines, it has benefited us to standardize on MacBooks for team members (we also talked about this in a recent blog post). We are a long way away from having a dedicated IT team to help people with laptop issues, but by defaulting to one machine, the team is able to support that one, and help each other. If anyone has a strong preference for something else and is confident they can deal with any troubleshooting themselves, they’re free to do so.

Onboarding

Onboarding doesn’t tend to get standardized until startups have People Ops and/or IT teams on staff. However, we use authentik to implement SSO for all new team members, so they get access to everything they need on their first day with just one login—with the added benefit of dogfooding.

All of the apps the team needs are displayed on a single page in authentik, accessible using a single login. When a new team member starts, we simply add them as a user in authentik, and they are ready to go!

Where we’ve kept flexibility

Standardization is often one of the hallmarks of when a startup is no longer a startup. Authentik is still small and nimble enough to allow more fluid processes and roles where it makes sense.

While some tasks fall naturally to specific roles, there is still room for people to pick up work and ideas that aren’t strictly part of their job descriptions. This goes back to our founder’s previous post, which talks about hiring people with the experience and curiosity to explore beyond their roles. We do a weekly PR backlog refinement session together—arguably this doesn’t need to be a synchronous meeting, but we find value in coming together as a team to review and discuss the backlog.

Working in a greenfield environment is great, because you can do anything. It’s also overwhelming, because you can do anything. Finding the right level of process and guardrails has been helpful for reducing that cognitive load for our team.

As always, we are interested to hear your thoughts on this topic. Leave some comments here, find us on Discord, or send us an email to [email protected].