In many organizations, progress is safeguarded by process. At Gridraven, progress is driven by accountability. Decisions aren’t distributed across layers and steering groups; they’re owned end to end by the people who design, build, and operate the systems.
It was early 2025 when I needed to add multi-tenant authentication to Claw in order to support our SaaS offering. Normally, projects like these take months. For us it was a few weeks from inception to the solution going live. It’s an aspect that touches security, operations, development, and product departments - it just takes time to coordinate.
Who builds, decides - it’s a motto we use in Gridraven. The ownership of the decision is individual, but never isolated. One person is trusted to make a decision and the team’s role is to validate it quickly and professionally. That trust only exists because the person making the decision will also be the one living with its consequences.
Here’s what that looked like. The requirements were discussed in the office with three of us - me, CTO and CEO. The decision to choose a service to integrate instead of building it ourselves was obvious. As it’s not Gridraven’s core business, the first choice is to outsource such solutions. We explicitly avoided solutions that supported both Saas and on-premise. We do need an on-premise solution too, but products offering both are just too complex. A dedicated solution for each makes the operators’ lives easier, I mean our lives.
There are many services offering authentication. My job was to evaluate each solution’s security. Then I created proof of concepts to understand the integration complexity. That left only 2 solutions that made sense. The deciding criteria between the two was future extensibility. The solution I picked had a nice balance of basic core features and premium add-ons which we might need later. I documented the technical details with the final choice and CTO validated it asynchronously. No meetings.
Between the two of us we covered all the necessary roles: architecture, security, operations, implementation and budgeting. The risk did not vanish - it was owned by the two people with the full context.
In this situation I had a big incentive to choose wisely, because I would be the one fixing the solution when our service is live, customers unhappy and the CEO waiting for resolution. On the other hand new functionalities were also waiting. So I had to balance speed vs stability. If the API connection fails due to authentication, this would mean waking up and fixing it ASAP. Machines pull fresh forecasts every hour and we provide high availability service.
Now, about a year has passed. Customer onboarding has been smooth. As a bonus, the chosen solution supported our internal preview environments and impersonation without code changes. In fact this solution has been very boring from a technical perspective - no incidents, no migration project looming, no plans to change it. It’s the good kind of boring you want in technical systems.
About 10 years ago I worked for a telco as a software engineer. There were many departments like development, architecture, operations, system analysts, business analysts and quality assurance. In that type of organization, the responsibility of choosing the correct authentication system still exists, it’s just diffused among different departments, each one handing off their work to the next. The decision is done according to the process. It’s how big organizations work. Just that coordinating all these teams takes time.
Small teams move fast not because they skip responsibility, but because they own it.