Skip to content
Alexandru Stanciu
Alexandru Stanciu · Frontend Engineer

I care about what happens after it works.

Frontend engineering, architecture & product thinking.

Let’s build something

The experiment

Let's build something.

You have a simple product. You have a short deadline. And you know requirements will change.

The product is a booking page for a small clinic: a patient picks a doctor and a time.

The brief

We need to launch quickly. For now, patients only need to book an appointment. More features will probably come later.

What do you build?

The AI experiment

Now let's let AI help.

AI can make implementation dramatically cheaper. It can also make a plausible assumption you didn't notice.

New requirement

Show patients only appointment slots that are actually available.

AI engineering proposal

Filter unavailable appointment slots in the client using the availability data returned by the API.

Why This keeps the API simple and gives the interface control over filtering.

Estimated implementation 2 person-days

The performance experiment

The user wants to book an appointment.

Does everything need to load first?

What should the user wait for?

Press an answer to watch the page load that way.

Technical detail

Server-render what doesn't need interaction. Hydrate what does. Defer what doesn't matter yet.

That is the whole of it. What follows is what this page does about it, which is the version of the argument that can be checked rather than believed.

What this page does

  • Everything you have read here is static HTML, rendered when the site was built. No request stands between you and it.
  • The only JavaScript it ships is interaction: the theme control, one island per experiment, and the control that takes an appointment.
  • The reviews, the recommendations and the analytics are no JavaScript at all, so there is nothing of theirs to defer. The cheapest non-critical work is the work that never had to be written.
  • There are no third-party scripts, no analytics of our own, and no fonts from another origin.

The responsive experiment

Mobile isn't a smaller desktop.

The same appointment, at four widths. Nothing is added, hidden or reordered to make a width work: what changes is how much of the page stands side by side.

What should the page become?

Drag the width, or jump to one of the four the page was designed at.

390 pixels

Designed at

Doctor

Dr. Oana Popescu

Central clinic

Date

17 September

Available times

Appointment details

Clinic
Central clinic
Doctor
Dr. Oana Popescu
Date
17 September
Time
09:00

Confirmation

One column

Five steps in the order they happen, each on its own rule.

One column. Five steps in the order they happen, each on its own rule.

Same product. Different hierarchy.

Doctor, Date, Available times, Appointment details and Confirmation: the same five areas at every width, and the same order for a screen reader as for an eye.

The engineering principle

Responsive design isn't shrinking the interface.

It's deciding what the interface should become.

Real work

Where the thinking comes from.

Three places where I have built software. Each one taught me something about building it.

Synygy

I built the tool I wished the process had.

Business Analyst

A monthly process asked every employee to fetch their own payment details from the company's intranet, then complete an invoice by hand.

I built a VBScript inside the Excel template that did both: it retrieved each employee's details and completed their invoice, which until then was filled in by hand.

The technology was simple. The useful part was recognizing that the process itself didn't need to remain manual.

By hand

  1. Fetch the payment details
  2. Complete the invoice

replaced by

In the template

Retrieves the details and completes the invoice

Two steps a month, done by hand, replaced by one the template does.

Intouch Games

From building games to building the systems behind them.

Web Developer

I built web-based games for desktop and mobile: the interface, the game logic, the interactions, the animation and the way a game talks to the server.

Alongside the games, I contributed to the internal JavaScript frameworks, the game-development framework, and an editor used to build them.

Sometimes the highest-leverage frontend work isn't another feature. It's improving the system that makes the next feature easier to build.

The framework

A shared base a game is built on

The editor

A tool used to build a game

used to build

The games

Desktop and mobile, in a browser

Two things the games are made of: a framework to build on, and an editor to build with.

Adobe

Frontend engineering at product scale.

Frontend Software Engineer · Since 2019

I work on Adobe's account experiences: the interfaces customers use to sign in, to create and manage an account, and to see subscription and account information.

They are large-scale, customer-facing experiences, used by millions of users.

The interesting part isn't just the interface. It's building frontend systems that have to stay understandable, reliable and evolvable at that scale.

One account, and the customer-facing experiences built around it.

Independent work

I have also built websites and web applications independently, ranging from WordPress and custom PHP implementations to React applications.

About

I'm interested in the part between “it works” and “it's good.”

I'm a senior frontend engineer focused on React, TypeScript, JavaScript and the architecture behind complex interfaces.

After years of building large-scale products, I've become increasingly interested in the decisions that determine how well software survives change.

Contact

Have a hard problem?

I'd rather talk about that than a job description.

Let's build something worth changing.