The Architecture Decision That Almost Killed My SaaS at Week 6

At week 6 of building Step2Dev, I made an architecture decision that almost ended the product.

Here is what happened, what I learned, and how I recovered.

## The Decision

I decided to store AWS credentials directly in my database. Encrypted, of course. But stored.

My reasoning: easier for users to connect accounts, easier for me to build the connection logic, industry-standard practice (or so I told myself).

## Why It Almost Killed the Product

I showed an early architecture diagram to three DevOps engineers I trusted.

All three said the same thing: "I will never put my AWS credentials in someone else's database. Even encrypted."

I had built 6 weeks of product on an assumption that my users would never accept.

## The Pivot

I rebuilt the AWS connection model from scratch using IAM role assumption. Instead of storing credentials, Step2Dev assumes a cross-account IAM role that the user creates and controls. No credentials stored. No secrets in my database. The user retains full control and can revoke access instantly.

This is the right model. It is also harder to build. It took me 3 extra weeks.

## What I Learned

With security, never make assumptions. Ask your users directly. "How comfortable would you be with X?" is a question I should have asked in week 1.

The three engineers who gave me hard feedback potentially saved the product. If I had launched with credential storage, I would have had zero DevOps engineer users. The audience is too security-aware.

## The Principle

Build for the most paranoid user in your target audience, not the most trusting one. In DevOps, the most paranoid user is usually the most experienced one. Those are the people you want.

If you are building anything that touches cloud credentials or infrastructure: the right answer is almost always "never store it." Find another architecture.

What security decisions have you had to revisit in your projects?