Huddle Cloud: project facts
- Project
- Huddle Cloud
- Period
- 2025
- Role
- Frontend Lead · Fullstack Engineer
- Summary
- OpenStack-powered cloud infrastructure platform
- Description
- A cloud console where users can spin up virtual machines, manage Kubernetes clusters, deploy apps, and use AI models. I worked on the frontend dashboard and parts of our Go backend services that talk to OpenStack.
- Domains
- Infrastructure UX, Cloud Platforms, Systems Management, Observability
- Technologies
- Next.js, React, TypeScript, Go, OpenStack, PostgreSQL, React Query
- Ownership
- The frontend dashboard and user console
- Ownership
- Large parts of the application API layer built around our Go services
- Ownership
- Auth flows and user session syncing
- Ownership
- Stripe billing integration for hourly usage
- Ownership
- SEO setup and sitemaps for our landing pages
- Ownership
- Internal tools for our team to manage users and resources
- Learning
- I learned that cloud products are mostly about hiding complexity. The real work is taking raw infra details and making them feel like a regular SaaS dashboard.
- Professional signal
- I naturally take ownership of messy systems and stay around until the pieces actually fit together.
a cloud console where users can spin up virtual machines, manage Kubernetes clusters, deploy apps, and use AI models. i worked on the frontend dashboard and parts of our Go backend services that talk to OpenStack.
we wanted people to use cloud infrastructure without dealing with raw OpenStack complexity.
i spent most of my time hiding complexity. we built APIs between OpenStack and the app layer, added background auth refreshes, handled failures safely, and made resource creation feel predictable.
we launched a working cloud console that became the main way our team and users spin up VMs. i worked heavily on the frontend and contributed to the Go API services we needed to make it run.
- ·the frontend dashboard and user console
- ·large parts of the application API layer built around our Go services
- ·auth flows and user session syncing
- ·stripe billing integration for hourly usage
- ·SEO setup and sitemaps for our landing pages
- ·internal tools for our team to manage users and resources
- ·we had too many moving pieces.
- ·• auth lived in multiple places
- ·• infrastructure had separate state
- ·• virtual machines changed slowly
- ·• users expected instant updates
i learned that cloud products are mostly about hiding complexity. the real work is taking raw infra details and making them feel like a regular SaaS dashboard.
i thought cloud products would mostly be infrastructure problems. most of the work ended up becoming UX problems.
- ·raw infrastructure complexity
- ·scattered creation flows
- ·unclear provisioning state
- ·simpler dashboard UX
- ·guided step-by-step workflows
- ·better resource visibility
cloud products are mostly complicated systems pretending to be simple buttons.
i would simplify how we fetch VM states. instead of polling endpoints, Id probably set up WebSockets or server-sent events earlier to save server resources. i would also split our Go services into smaller, more focused helper files so its easier to manage.
- ·i probably refreshed the virtual machine details page thousands of times while testing if the status buttons actually worked.
- ·we spent a full weekend debugging why Stripe webhook events were failing, only to realize it was a tiny timezone mismatch in our Go service.
i naturally take ownership of messy systems and stay around until the pieces actually fit together.