2
4 Comments

How Cloudpen started (and why I'm still building it)

I didn't set out to build a cloud IDE. I was helping someone get started with web development and watched them spend an entire evening just trying to get Node.js running on their machine. They never wrote a single line of code that night.

That stuck with me.

I'd been building web apps for a while and had gotten so used to my own setup that I'd forgotten how brutal that first experience is. The installations, the PATH errors, the Stack Overflow rabbit holes before you've even started. It's not a skill issue — it's a friction issue.

So I started building Cloudpen. A browser-based IDE where you open a tab and you're already in. Real Monaco editor (same engine as VS Code), a real terminal with Python, Node.js, C, Go and more, one-click deployment to a live URL, GitHub sync, and Quill — a built-in AI assistant so you're never stuck alone.

No setup. No installs. Just code.

I'm a solo founder, self-funded, building this in public. Cloudpen launched on Peerlist Launchpad in June 2026 and the response has been encouraging. There's a free plan with real functionality — no card required — and a Pro plan at $12/month ($6 for students).

Still early. Lots to build. But the core works, people are using it, and I'm not stopping.

If you're building something or just learning, give it a try at cloudpen.dev. I'd love to hear what you think.

posted toAvatar for product Cloudpen
Cloudpen
  1. 1

    One thing I'd be careful with:

    The setup-friction story explains why Cloudpen exists, but it doesn't necessarily explain why someone upgrades.

    A lot of developers agree that setup is annoying. Far fewer pay to remove it.

    The interesting decision feels like which moment Cloudpen wants to own after the user gets past the first successful session.

    I wouldn't make that call casually in-thread because it ends up shaping the buyer, positioning, and what the Pro plan is really selling.

    1. 1

      @aryansinh That's a really sharp observation, and honestly one I've been thinking about too.

      You're right that "setup is annoying" gets people in the door, but it doesn't explain the upgrade moment.

      The way I currently think about it is that the free plan is designed to get developers to their first deployed project. The upgrade happens when they want to own that environment: custom domains, more storage, GitHub auto-redeploys, and Quill without hitting the daily cap.

      The moment I'm trying to own is when someone has something live and wants to keep building on it without friction. At that point, Cloudpen becomes less about avoiding setup and more about having a development environment that's always available and ready to ship from.

      That said, your comment is making me rethink how I'm positioning the upgrade path inside the product. Really appreciate the insight 🙌

      1. 1

        That's exactly why I'd keep pressure-testing it.

        The useful part isn't whether the upgrade happens after the first deployment. It's deciding which moment Cloudpen should ultimately own.

        That's the kind of call I wouldn't make casually in a thread because it tends to shape positioning, onboarding, and monetization at the same time.

        If useful, drop your email and I'll send the tighter version properly.

        1. 1

          @aryansinh Would love that — support@cloudpen. dev
          Thanks for pushing on this