Oluwatosin Kazeem

PHPSandbox is a web-based code editor where PHP developers can write, run, and share code directly in the browser. No local setup, no dependencies, no configuration headaches. Just open a browser and start coding.

When I joined as the founding product designer, the platform already worked well on the technical side. But the experience was a different story. After running a heuristic evaluation using Jakob Nielsen's method, the problems were hard to miss. The overall styling was inconsistent across the platform, the icon library was all over the place, and there was very little control or flexibility for users. Some interfaces made it obvious that UX had been thrown out the window at some point.

Beyond the evaluation, our Discord community was giving us feedback every day. And most of it came down to the same thing: users could not do what they needed to do. People were hitting walls trying to perform basic actions, running into backend bugs, and getting frustrated enough to ask for account deletion.

The feedback was loud and consistent. People liked what PHPSandbox could do in theory, but the experience of actually using it was not matching up.

When I ran a competitive analysis against 3v4l, Replit, and PhpStorm, something interesting stood out. PHPSandbox already had the most complete feature set. Collaboration, sharing, third-party libraries, integrations, and hosting. We had it all, while competitors were missing two or three of those categories.

The problem was never about features. It was about how those features felt to use.

The embed feature let developers preview and customise how their code displayed on external platforms. I redesigned it to be more compact, using progressive disclosure to surface what was most important to developers first.

This made the interface significantly less cluttered while keeping all the functionality intact. You could still do everything you needed to, but now the interface was not throwing it all at you at once.

On PHPSandbox, we work with notebooks, similar to files on Figma. I simplified the experience of starting a new project by giving developers multiple entry points: clone from GitHub, import using CLI, or create from scratch.

When creating a new notebook, users can seamlessly switch between these methods. And once you are inside, it is a VS Code-style tabbed interface where you can have multiple files open at the same time. Familiar, flexible, and fast.

For sharing, we went with a pattern developers already understood. Similar to Figma, users can share notebooks with others and set permissions to either edit or read-only.

No learning curve, just straightforward collaboration that works the way you would expect it to.

Our team was small and tight. Bosun, the CEO, handled backend and sometimes jumped into frontend work too. Mercy was our frontend developer, Tobi covered backend, and I owned design.

We worked in sync, with daily standups during intense stretches and scaling back to once or twice a week when things settled into a rhythm.

For our design process, sometimes we shipped without formal testing because the Discord feedback had already told us exactly what to build. Other times, we recruited volunteers from the Discord community to test things before they went live. That direct line to real users was one of our biggest advantages.

Over four years, from 2020 to 2024, PHPSandbox grew from a simple online code editor into a full developer platform. After the initial redesign, we relaunched as version 4, and that is when everything took off.

Post-relaunch, the product kept evolving. We added notebook templates so users could get started faster. The left navigation was reorganised to show recent notebooks and template options. We introduced Spaces, which work like projects in Figma, where organisations can group multiple notebooks together. This was a big deal for companies using PHPSandbox because it finally gave them a way to organise their work properly.

We also built a Learn platform where users could learn about PHP and the platform itself. We added floating windows so users could detach and rearrange sections of the app. And we launched a classroom feature that lets educators use PHPSandbox for teaching. It doubles as an interview tool too. You can send code for candidates to fork, edit, and submit for review. On top of all that, we introduced a new pricing plan to reflect the expanded feature set.

I started building a component library specifically for PHPSandbox, but from the very beginning, there was a mindset that we would eventually build more products. So the library was designed with enough abstraction to scale beyond just one platform.

That foresight paid off when it grew into Sandbox, a standalone design system used across all products.

After the v4 relaunch, the platform grew by 400% to over 60,000 users, all with no marketing spend. Growth was driven by word of mouth from the PHP developer community, strong SEO, and our active presence on Twitter.

The onboarding and landing page improvements were the biggest drivers, but the community did most of the heavy lifting in getting the word out.

Working on PHPSandbox for four years taught me how flexible I could be as a designer. I went from fintech to developer tools with very little coding knowledge at the time, and managed to design a platform that scaled significantly. We even attracted grants, though we ended up declining them.

If I were starting PHPSandbox from scratch today, I would pay a lot more attention to component design and colour choices from day one. And honestly, I would want to develop it myself, not just design it. That desire to bridge the gap between design and code is something PHPSandbox planted in me, and it has shaped how I work ever since.