When You're Too Deep in Code to Write About It

Solo Founder Dilemma: Code First, Write Later?

I've been deep in code for the past week. So deep that writing feels foreign right now. It's one of those periods where you're so focused on building that you forget everything else exists.

The irony isn't lost on me. I spend all day creating user experiences and here I am, struggling to find time for a simple blog post. But that's the reality of heavy development cycles. Sometimes you have to choose between shipping features and talking about them.

What I've Been Building

Most of my time went into Cloud Atlas Insight - our FinOps optimization platform. Sounds boring, but it's actually pretty interesting from a design perspective.

The core challenge was this: how do you make cost optimization recommendations actually actionable? Anyone can tell you "hey, this server is oversized." But then what? How do you plan the fix? Validate it won't break anything? Execute it safely? Monitor the results?

That's where the Flow Engine comes in.

The Flow Engine Problem

I redesigned this thing three times. Maybe four. Each iteration felt close but not quite right.

The first version was too technical. All charts and metrics. Users felt lost.

The second was too simple. Just a list of recommendations. No context, no guidance.

The third was getting there but the interface felt clunky. Too many clicks to get anywhere.

The current version is getting closer to what I want. We ask the system to generate optimization plans based on pre-analyzed cost data. The generated plan appears as an artifact - similar to how Claude shows artifacts in conversations. When you click on it, it takes you to our Flow Engine workspace where you validate and execute the plan step by step.

Each step can trigger different actions - code generation, script execution in terminal, API calls. We're still refining the experience but it's starting to feel seamless. I'll share a demo video soon to show how it all comes together.

Technical Architecture

Behind the scenes, it's more complex than it looks.

Each AWS project gets its own workspace in our Flow system. Within that workspace, we track dozens of optimization candidates - oversized instances, unused storage, commitment opportunities.

Each candidate has its own process flow. Its own workspace. Its own conversation thread.

But here's the tricky part: each optimization might have 5-10 execution steps. Resize the instance, update the load balancer config, test the application, monitor for issues. We track all of that. Separate sessions for each step.

The API design was crucial here. How do you manage hundreds of simultaneous optimization workflows without everything becoming a mess?

We ended up with a candidate-based system. Each optimization candidate is independent. It has its own execution plan, its own history, its own status. But they all connect back to the main project workspace.

The Interface Challenge

The hardest part wasn't the backend architecture. It was making it feel simple on the frontend.

Users don't want to think about "candidates" and "execution plans." They want to say "make my AWS bill smaller" and have it happen.

So we built the chat interface to hide that complexity. You have a conversation about your infrastructure. The system generates optimization plans in the background. Presents them as simple cards you can review and approve.

But when you drill into execution, that's where the step-by-step guidance appears. Code examples, AWS CLI commands, rollback procedures. Everything you need to implement the change safely.

What's Next

I'm pretty happy with where this landed. The interface feels smooth. The architecture is solid. But there's still work to do.

Integration testing across all five repositories. Performance monitoring for the real-time features. User documentation that actually makes sense.

And maybe, if I'm lucky, more time to write about it.

Balancing coding and communication is hard. When you're in the zone, breaking that flow to write feels counterproductive. But I know documenting the journey matters too.

Next week I'll try to find a better rhythm. Ship features and talk about them. Not just one or the other.

For now though, back to the code. These optimization workflows won't build themselves.