Galust OsipyanEmail me

~/portfolio

Galust Osipyan · Senior Full-Stack Engineer

I build the structure your product grows on.

Developing for the web since 2017. I work with React, Next.js and Node.js, deliver multi-brand platforms and microfrontends, and have led teams of 4 to 8 engineers.

Email meDownload CV

Yerevan, Armenia · GMT+4 · open to remote roles

SPECIMEN 01 · FLUORITE · GROWN IN ORDER

~/case-studies

One foundation, many products.

Three platforms where one well-built base had to serve several brands or apps at once. Client names are withheld under NDA. The problems and the decisions are real.

Case 1

Multi-brand web platform for a US restaurant group

Four restaurant brands on one Next.js codebase, with a typed BFF in front of the backend services.

Food service, United StatesSenior Software Engineer

  • Next.js
  • React
  • TypeScript
  • Node.js
  • Express.js
  • OpenAPI

Context and problem.

A restaurant group ran four brand websites. Instead of four separate applications, all of them were served from one Next.js codebase. Each site still had to look like its own brand, and not every feature was meant for every brand. On top of that, the pages needed data from several backend domain services. Calling each of them from the browser would mean more requests and more data-shaping logic on the client.

Constraints.

One shared codebase for all four sites. Brand differences had to live in configuration, not in copied code.

What I did and why.

  • I built the per-brand theming, so the same components picked up each brand’s styles instead of being duplicated per site.
  • I implemented the feature flag system used to switch functionality on or off for each brand. A feature could be built once and enabled only where it was needed.
  • I wrote a Backend-for-Frontend (BFF) service in Express.js. It received requests from the frontend, called the relevant domain services, and returned one combined response. TypeScript types were generated from the services’ OpenAPI specs, so the contract between the BFF and the services stayed typed and breaking changes showed up at build time rather than in production.

Result.

Four brand sites ran on one codebase, with brand differences handled through theming and flags. The frontend worked with a single, typed API layer instead of several services at once.

Case 2

Shared platform for a seven-brand retail group

Seven retail brand sites built from one component base, with editors publishing content on their own.

Retail, United Arab EmiratesLead Software Engineer, team lead

  • Next.js
  • React
  • TypeScript
  • Monorepo
  • Contentful
  • Third-party payments

Context and problem.

The client owned seven brands, and each needed its own website. Much of the UI was the same across brands. The client also required that their team could edit different parts of the pages on their own, without asking developers for each change.

Constraints.

Seven sites to deliver, so building each one separately would repeat the same work seven times. Content changes had to go live without developers in the loop.

What I did and why.

  • I led the team and set up a monorepo with a shared component base. Each brand site was assembled from the same components, so a fix or improvement made once reached every brand.
  • I proposed Next.js Incremental Static Regeneration (ISR) for the pages. Pages are served as pre-rendered static files, which keeps them fast, and they are regenerated after content changes in Contentful. Editors could publish updates without waiting for a full rebuild and redeploy.
  • I also integrated a third-party checkout and payments system into the brand websites.

Result.

The group’s sites shared one component base instead of seven copies. The ISR setup solved the client’s content-editing problem: their team could update pages themselves while the sites stayed static and fast.

Case 3

Microfrontend platform for a travel company

Five Preact microfrontends loaded at runtime, with styles isolated in Shadow DOM.

Travel, GermanyLead Software Engineer

  • Preact
  • Module Federation
  • Shadow DOM
  • Node.js
  • Express.js

Context and problem.

The client needed five features of its website delivered as independent microfrontends. The host application loaded them at runtime, and each one became its own section of the site. Each had to work inside the host without its styles leaking out or the host’s styles breaking it.

Constraints.

The host loaded each microfrontend as a separate bundle at runtime, so every library added to one of them added to the weight of the page.

What I did and why.

  • We built the five microfrontends in Preact. It keeps the same component model as React but ships far less code, which matters when one page loads several apps.
  • The microfrontends were exposed through Module Federation and rendered inside Shadow DOM, so their styles stayed isolated from the host page.
  • Data shared across the whole site lived in the host, which passed it to each microfrontend. Inside each microfrontend, I proposed Context instead of Redux for sharing state between its components. It covered what each app needed without adding another library to every bundle.
  • The backend was a Node.js service on Express.js.

Result.

Five microfrontends ran inside the host as separate sections of the site, with isolated styles and small bundles. State stayed simple: the host handled shared data, and each app used Context instead of an extra state library.

~/stack

Tools I trust in production.

Grouped by area.

Languages & Frameworks

  • TypeScript
  • JavaScript
  • Node.js
  • NestJS
  • Express.js
  • React
  • Next.js
  • Preact
  • Astro

Back-End & Databases

  • PostgreSQL
  • MySQL
  • MongoDB
  • RESTful APIs
  • GraphQL
  • OpenAPI
  • BFF
  • Contentful

Tools & DevOps

  • Docker
  • AWS
  • CI/CD
  • Sentry
  • Prometheus
  • Grafana
  • RabbitMQ
  • Kafka

Testing

  • Vitest
  • Jest
  • React Testing Library
  • Playwright

Front-End

  • HTML
  • CSS
  • SASS
  • Tailwind CSS
  • Redux
  • Shadcn/UI
  • Radix UI
  • Storybook

$ whoami

Remote by default, reliable by habit.

Since 2020 I have worked remotely with international teams, first as an engineer and later as a team lead.

The problems I like most are the ones where one codebase has to serve many products. I care about the parts other developers build on: shared components, typed APIs and clear boundaries between systems.

I do my best work in teams that measure outcomes, not activity.

I work in English (C1), and also speak Russian (C2) and Armenian (native).

~/contact

Building something that has to scale? Let’s talk.

Tell me about the role or the project. Email works best. LinkedIn works too.

Email me
LinkedIn(opens in a new tab)Download CV