What shipping at 5 companies in under 2 years actually taught me

In under two years I’ve shipped production code at five companies — Ebizz Fz, VEVE, WeeNexa, Look4 Dating, and now Platas, where I lead the frontend. That’s a lot of different codebases, teams, and deadlines in a short window. Some of it was chaotic. Most of it taught me something I couldn’t have learned by staying in one place. Here’s what actually stuck, stop by stop.

Ebizz Fz — SEO and “full stack” means owning the whole thing

My longest stretch (Dec 2023 – Feb 2025). I built full-stack apps with React and Node, and one number reshaped how I think about frontend work: responsive design plus SEO optimization lifted site traffic by ~30%. Not a new feature — the same product, made findable and fast.

The lesson: the frontend is not where the work ends, it’s where the user starts. A beautiful app nobody can find, or that loads slowly on a mid-range phone, has a bug — the bug is just measured in analytics instead of a stack trace. I also contributed to a ChatGPT-based startup product here, which was my first real taste of building around an unpredictable, latency-heavy dependency. “Full stack” stopped meaning “I can write an endpoint” and started meaning “I own the feature from schema to Lighthouse score.”

VEVE — you inherit the past, you don’t get to skip it

At VEVE (Feb – Apr 2025) I built a full-stack admin panel with Next.js under a single domain, but the memorable work was migrating a five-year-old Create React App codebase to TypeScript.

Migrations teach you humility. That code wasn’t bad — it was old, written under constraints and conventions that no longer applied, by people who’d moved on. The lesson: respect the code you inherit. Every weird workaround was somebody solving a real problem with the tools they had. The job isn’t to sneer and rewrite; it’s to understand why before you change what, then modernize incrementally so you’re never one bad merge away from a broken product.

WeeNexa — ship the thing, then make it fast

WeeNexa (May – June 2025) was a restaurant management SaaS: a dashboard, a landing page that 100+ users gave real feedback on, and database queries I tuned for a ~20% efficiency gain.

The order there matters. I shipped a working dashboard first, then optimized the queries once I knew which ones were actually hot. Guessing at performance before you have real usage is how you spend a week shaving milliseconds off a query nobody runs. Correct and shipped beats fast and theoretical. You optimize against reality, not against your imagination of it.

Look4 Dating — a real deadline clarifies everything

Look4 Dating (June – July 2025) was the pressure cooker: design and launch a dating app — with Stripe payments and a Next.js admin panel — in two weeks.

A two-week deadline is a brutally effective teacher because it makes every “nice-to-have” argument answer itself. You cannot gold-plate. You build the thing that has to work — signup, matching, payments — and you build it solidly, and everything else waits. The Stripe integration lifted satisfaction ~20% and the admin panel cut management overhead ~30%, but the deeper lesson was scoping under constraint: a real deadline is a forcing function that separates what the product needs from what you’d enjoy building. Those are almost never the same list.

Platas — leading means the code is the smaller half

Now I’m Frontend Lead at Platas (July 2025 – present). We delivered a fully functional staging platform in three weeks on a scalable Next.js architecture, with CI/CD built for zero-downtime deploys.

Leading changed the shape of the work. The architecture and the pipeline matter enormously — a deploy that can’t roll back safely will eventually wake you at 3am — but the harder part is the stuff that isn’t code: keeping the team unblocked, making the workflow legible, deciding what’s worth doing now versus right. Zero-downtime deploys are a technical achievement; a team that can move without stepping on each other is a human one, and it’s the harder of the two.

The throughline

Five very different stops, one repeated lesson: the code is rarely the hard part. The hard parts are findability, respecting what came before, optimizing against reality instead of guesses, scoping honestly under pressure, and keeping people unblocked. Moving fast across many codebases forced me to learn those faster than a single stable job would have — and they’re the parts that transfer no matter what stack the next company uses.

If you’re early in your career and choosing between depth at one company and breadth across several: breadth taught me an enormous amount, fast. Just make sure you’re actually shipping at each stop. Watching real users hit real software is where all of these lessons actually came from.