JavaScript and TypeScript developer — web and mobile fed by one API

What I deliver in this ecosystem

What they have in common is one contract underneath all of them; I am not building a design system, I am building the interface that talks to the API.

• Three layers, one contract

  The same feature ships as a REST API, a web UI and a mobile app at once. I keep the split strict: web and mobile never talk to each other, only over the shared API.

• The mobile client

  The iOS and Android half of the same product, with React Native and Expo. Getting it through the stores is part of the job too.

• The type layer

  TypeScript carries one contract from API to UI. Writing the contract twice, once at each end, means there is no contract.

• Build and styling pipeline

  The build pipeline that cuts dev server startup to seconds, and a utility-first styling layer. The toolchain keeps changing; the job of these two layers does not.

The hard part is the contract, not the code

Most of the errors I meet on the interface side look like interface errors and turn out to be contract errors. When a field name, a date format or the meaning of an error code drifts between layers, the result is a cluster of failures that all look unrelated and share one root. So I start from what the back end promises, not from how the interface will look.

Not tied to a single library

All three are different answers to the same question; which one gets opened is decided by the product's needs.

• The Vue side

  I spent a long time here — component-based interface architecture, routing and state management. Not a lost investment: it is where I can compare the two approaches.

• The React side

  The centre of gravity moved here through mobile needs, and having the same mental model on web and mobile made things easier.

• Interfaces out of a server-side frame

  Approaches that pull a modern interface out of a server-side frame and cut the code shipped to the browser.

What makes me replace a tool

The longest-running thing I have watched in this ecosystem is the tooling changing — AJAX with jQuery, then Gulp, then Webpack, then Vite. The decision went through the same order every time.

01 The bill is always configuration

Every migration cost the same thing: configuration. What is expensive is not the tool itself but the setup weight of making it run.

02 The return has to beat the bill

I take on a new tool when it returns more than the configuration bill I pay for it. When it does not, the old tool stays where it is.

03 "More modern" is not a reason

The age of a tool is not a measure. The measure is which concrete job it makes cheaper in this product.

04 Build time is a line item too

I apply the same measure on the compiler side: build time is a cost line, not a detail.

What sets its own rules on mobile

My expectation that React experience from the web would transfer turned out half right: the component thinking is the same, the rest is not.

• Navigation architecture

  Navigation is built together with the screen architecture; router habits from the web do not carry over as they are.

• List rendering performance

  List rendering performance is one of the headings I work on separately on the mobile side.

• Versioning with OTA updates

  Being able to ship an update without a store round makes version management a subject in itself.

• Store submission

  Getting it through the store is part of the job as well — and a craft independent of the app's code.

What I do not do

Accessibility auditing, building a design system and advanced animation work are not my field, and I say so when it needs saying. The parts of interface architecture that touch the system side — SSR decisions, caching strategy — are written on sade.dev.