Interface and frontend engineering

Most of my work at this layer falls into 4 kinds: web applications, UI with motion, forms that embed into somebody else's page, and tools that run in the browser rather than on a server. The standard is the same for all 4, though. It has to work on a cheap phone over a thin connection, and it can't lead a tired person into a mistake.

Platon is a Ukrainian payment provider, and I worked on its card-to-card transfer form in 2019-2020, when Platon was a client of Qberry. It's a small thing where the details really matter, because the person using it is handling their own money. You type a full card number and the form splits it into 4 masked fields, moving focus forward as you type and back when you delete. The browser runs the Luhn check and the card-brand check before it lets you submit, and it checks the expiry date as well. The form speaks Ukrainian, English and Russian, and it's built to embed, so it lives inside other pages too. It went live on Platon's own site. It's plain care more than anything clever.

Cropman was a batch image editor in the browser. Say you've got a pile of product shots to prepare before publication. You draw one crop, and the editor applies it to the whole set. The crop size is shared across the set, and the smallest photo caps it, so no crop can ask for pixels a photo doesn't have. The box position is kept per photo, because the product can sit in the center of one shot and off to the left in the next. You only drag a rectangle over a plain canvas, and all the pixel work happens on the server. A finished batch downloads as a ZIP the page builds itself. On a busy day it took 100 to 200 edits, with peaks above that.

At Amerix, a company selling group and individual tours around the United States, the booking widget keeps your whole selection together (mode, dates, tiers, traveler counts, hotel level, transport) and asks the server for one price. The server sends back the complete bill, line by line: the per-traveler price, the tour itself, every paid extra with its unit price, every activity, the discount and the total. The widget and the summary next to it both read that same answer, so they can never show two different prices. The catalog filters work the same way. One query carries every filter at once, from countries and departure city to length, price range, month and sort order, and the reply holds one page of tours plus a match count for each option. So a visitor knows how many tours they'll get before they even click.

When people who aren't developers have to edit a whole site, the interface turns into a renderer. On the faculty site I built one renderer that draws every page from one shared set of blocks, so the same blocks make a department page, an educational program, a news post and the home page. An editor arranges blocks and the page is there, with no release and no developer, unless they need a truly new kind of block. That's on purpose: if every new page needed a developer, each next faculty would have to build its site again from zero.

At The Parker Avery Group the interface is where Ask Udi's answer lands. You ask a plain-language question and get a table, a chart or a report: the browser reads a placeholder in the model's answer, fetches the full result by its id and draws the whole thing. The results stay queryable afterwards, so a different cut of the same data needs no second run. Beyond Ask Udi, I built new modules, services and pages on the platform.

At Mobilauto I built the corporate accounts portal end to end, with dashboards for corporate clients and taxi firms, reports that export to Excel and PDF in one archive, and tables that keep each person's column choices on the server, so they come back next time. The Cabinet24 call-back widget, the one that sits on a customer's own website, was mine from start to finish as well. On the dispatcher application I built the skeleton and the way the panels dock, and inside it positions, order status and driver availability move in real time over prpcow, my own transport library.