Rebuilding the Fluidstack Console (Freelance Case Study)

From March 2024 to August 2025, I worked with Fluidstack as a freelance frontend engineer. My main mission was clear: rebuild their console from the ground up.

The existing console had serious usability and stability issues. Instead of continuing to patch it, the decision was made to rebuild the core flows properly. I led the frontend side of that rebuild.

The Starting Point

Fluidstack needed a console where users could:

• Deploy and manage instances
• Create and manage API keys
• Add SSH keys
• Handle account top-ups
• Authenticate securely

At first, we worked with designers. Eventually, those designs were dropped. From that point on, I took ownership of the user experience directly.

I proposed interaction patterns, designed flows, implemented them, and connected everything to the backend. Requirements arrived progressively. We shipped, gathered feedback, adjusted, and shipped again.

What I Built

1. Full Console Frontend (End-to-End)

I rebuilt the main Fluidstack console using:

• Next.js
• React
• TypeScript
• TanStack Query
• Tailwind CSS
• Radix UI + shadcn/ui (customized)

Core features included:

• Instance lifecycle management (create, start, stop)
• API key management
• SSH key management
• Account top-ups and recurring top-ups
• Full WorkOS authentication flow, aligned with backend behavior

I was shaping how the product felt and behave to some extent.

2. Atlas Console

Later, I was asked to help the Atlas team.

Atlas focused on clusters and Slurm-based workloads. It required a different mental model compared to single-instance workflows.

I designed and built the Atlas dashboard frontend from scratch, adapting the UX to match:

• Cluster-based architecture
• Permission-based actions
• Capability-based UI controls

After reaching a stable milestone, the project transitioned internally to their team.

How I Worked

Work came in waves. Some periods involved near-daily shipping. Other periods were quieter.

Tasks came through:

• Linear
• Slack
• Direct stakeholder requests

I collaborated with:

• Backend engineers working in FastAPI
• Marketing and operations stakeholders
• Product and non-technical contributors

When users reported friction or requested features, those requests came directly to me. I implemented changes quickly and iteratively.

The pace was fast. Requirements evolved often.

Engineering Decisions That Made a Difference

The backend APIs changed frequently during development.

To avoid fragile integrations, I used Orval to generate typed API clients from the OpenAPI spec.

In practice, this meant:

• Regenerating clients frequently
• Letting TypeScript surface response mismatches immediately
• Catching integration issues before they reached production

Instead of discovering breaking API changes at runtime, we saw them at compile time. That kept delivery smooth even during heavy backend iteration.

Results

• Replaced a fragile legacy frontend with a modern, stable console
• Improved clarity and usability of core workflows
• Reduced integration friction during backend changes
• Maintained high delivery velocity across shifting requirements

I don’t attach business metrics because they weren’t consistently shared in this freelance model. The impact shows up in shipped scope, improved workflows, and sustained delivery without major frontend incidents.

What This Project Says About Me

• I can rebuild a core product surface from scratch.
• I can design and implement UX without heavy design supervision.
• I can move fast while keeping systems stable.
• I work well across engineering, product, and non-technical stakeholders.
• I adapt to evolving requirements without losing structure.

This project wasn’t about flashy features. It was about building solid foundations and shipping consistently.

And that’s often what matters most.