Products you can understand. Systems we can build.

What needed to be solved

A medical centre with a catalogue of hundreds of tariffed services needed each service to have its own page, searchable, with price and unit of measure — not a PDF with the price list. In addition, prices and staff change, so the clinic had to be able to edit them itself, and appointments had to reach reception immediately, not in an email inbox.

What we built

Next.js 14.2.35 (App Router) with React 18, TypeScript and Tailwind. Each item in the medical catalogue became its own static route: 521 `page.tsx` files in `src/app`, of which 481 under `/servicii` — 184 physiotherapy, 122 advisory services, 61 periodic medical examinations, 27 gynaecology, 26 ozone therapy, 23 treatment packages, 18 alternative medicine, 12 diagnostics, the rest by departments. The production sitemap lists 890 addresses. The site is bilingual ro/ru. Editable content (doctors, packages, treatments, articles, settings, images) is stored in a local SQLite database via `better-sqlite3`, with WAL journalling and active foreign keys, administered from `/admin` through 20 API routes; authentication uses `jose` for session and `bcryptjs` for password, and password changes invalidate existing sessions. Appointment and contact forms are validated with `zod` + `react-hook-form` and send the formatted message directly to Telegram, via the Bot API. There is also a price calculator on `calculator`.

What needed to be solved

A club menu changes often, has prices and volumes that must be exact, and is read on a phone, in the dark, by people who speak three languages. A scanned PDF on a QR code does not solve any of that: it cannot be searched, translated, or updated without reprinting the code.

What we built

A digital menu without a framework or packages: the real sources are four JSON files, and a 402-line Python generator writes a single `index.html` from them. 119 products in 21 categories, each with price, volume, composition and photo; 119 short presentation texts, one per product; 119 sets of pairing recommendations (“what it goes with”), which the visitor sees on each card. The menu has three languages: Romanian is the base, and Russian and English cover not only the interface, but also the categories, volumes, compositions, the 82 taste labels and all 119 presentation texts. The basket, favourites list and bill splitting run in the browser, without an account and without a server. Fonts are hosted on the same domain, not at Google. Before each publication, a 233-line script runs 16 checks — that no tracker slipped in, that nothing is requested from a third-party domain, that the JSON is valid and every image exists, that the menu is complete in all three languages, that prices descend in each category and that the structured data on the page is valid. Publication is done automatically from GitHub Actions on merge into `main`, after the workflow makes a full copy of production and keeps it for 30 days.

What needed to be solved

A commune town hall must have an official website compliant with GD 728/2023 — with fixed sections (decision-making transparency, projects and decisions, announcements, documents, contacts, budget) — and must be able to update it on its own, without a developer for every announcement. Without this, information of public interest remains on paper or in a Facebook group.

What we built

Laravel 12 application on PHP 8.2 with MySQL 8, Vite + Tailwind front-end, packaged in two Docker containers (`japca_app` = nginx + PHP-FPM, `japca_db` = MySQL). The architecture deliberately separates two kinds of content: the editorial content that changes rarely (geography, history, institutions, contacts, budget) is kept in a single PHP configuration file of 1613 lines, which Blade templates read directly, while the content that changes often (announcements, photo gallery, projects and decisions, documents, transparency settings) is kept in MySQL and edited from the `/admin` panel. 40 Blade templates, 32 routes, 10 database migrations. Panel authentication is limited to 5 requests per minute from the same address — the sixth gets 429 — and every administrative action goes into an audit table. Security headers and the sitemap are covered by automated tests running in CI.

What needed to be solved

The same thing as with any QR code menu: it has to be fast on a phone, correct in price, readable in three languages and changeable in five minutes when the kitchen removes a dish. In addition, the restaurant does not need any customer tracking — and then the real question is whether someone actually builds a site that collects nothing, or only writes that in the privacy policy.

What we built

A single `index.html` generated by a 377-line Python script from JSON files: 146 products in 31 categories, 143 short presentation texts, plus Russian and English translations for categories, names, volumes, compositions, labels and texts. The basket, favourites list and bill splitting run in the browser. The site is served directly by Caddy 2, with automatic HTTPS. The interesting part is that user non-detection is not a promise, but a rule enforced by continuous integration: on every merge request, CI regenerates `index.html` from sources and rejects the PR if the result differs from the file in the repo (so the published page always matches the sources), then runs 14 checks — no trackers, no automatically loaded resource from a third-party domain, locally hosted fonts, no backup files ending up in the repo, privacy policy present and linked from the footer, full menu in three languages, prices in descending order in each category, valid structured data — and also checks that the security headers and IP address masking in logs have not disappeared from the server config. All GitHub actions used are pinned to the commit hash, and the workflow starts with `permissions: {}`.

What needed to be solved

unverified — we do not have the sources, so I cannot describe the working issue without inventing it.

What we built

React application built with Vite, served statically by nginx, with a Russian version on `/ru/`. 181 addresses in the production sitemap. That is all that can be stated from the outside: the sources are not on this machine, so I cannot name the libraries, structure or integrations.

What needed to be solved

A district dental centre needed a public list of services with prices, clear marking of those covered by compulsory insurance, team, emergency hours and transparency pages — editable by staff, not by a developer. When we took over the project, the admin panel had a serious problem: the admin password was compared in the browser and ended up in the public JavaScript bundle, and write requests to the API could be made by anyone on the internet.

What we built

React 18 + TypeScript application on Vite 6, with `react-router-dom` routing — 22 screens, from services and prices to emergencies, orthodontics, implants, paedodontics, transparency and feedback. Behind it, an Express 4 API running under PM2; nginx serves the built files and forwards only `/api`. Public data (services, team) is kept in JSON files read both by the API and directly by the front end. The part we brought in is security: the password no longer leaves the server — `POST `login` verifies it there and returns an HMAC-SHA256-signed token valid for 12 hours, with a limit of 8 attempts per 15 minutes per IP address and constant-time comparisons; writes to `services` and `team` now require the token; the signing secret is generated automatically in a file with 0600 permissions, kept outside the repo; the API listens only on 127.0.0.1, so nginx is the only public route; CORS is limited to own domains, and the JSON body is capped at 1 MB. On top of that we added CI that builds, checks types and refuses the bundle if it finds a secret in it, plus Dependabot with a weekly npm cadence.

What needed to be solved

A lending company needs more than a website: the application must be submitted online, pass through a decision workflow, produce a PDF contract, generate a payment schedule and leave an audit trail — and all of this must withstand the questions asked by a client requesting their personal data back. The public part (calculators, articles, pages by credit type) must at the same time bring people from search.

What we built

Two halves in the same repository. The public part is a statically built Vite + React Router application — 50 screens, including four calculators (credit, eligibility, refinancing, payment schedule), separate pages by credit type, a blog, pre-contractual information and compliance pages. Romanian routes remain without a prefix, and Russian ones go on `/ru/…`, with canonical and alternate tags generated from the language of the active route. The business part is a modular TypeScript Express backend, with Prisma over PostgreSQL: 16 modules — authentication, role-based rights, application flow, documents, payments, notifications, scheduled tasks, blog, SEO, GDPR, clients, leads, contact, calculator, Google Ads, health — and 18 tables in the Prisma schema, including `Contract`, `Payment`, `AuditLog`, `GdprRequest`, `UploadedDocument`, `DailyKpiSnapshot` and `CronJobRun`. It runs under PM2, with separate scripts for production migrations, pre-launch checks, secret generation, backup and database restore.

What needed to be solved

An auto service is searched for in very specific combinations — make plus operation plus district (“BMW automatic gearbox repair Botanica”). A single “Services” page cannot answer any of that. The technical problem is that the site is a single-page React application, so what the search engine sees is an empty `<div>` if nothing specific is done.

What we built

React 19 + TypeScript application on Vite 6, with React Router, but prerendered at build time: each route comes out of the build as its own HTML file, so the search engine gets content, not an empty page. The address structure has been expanded in verifiable steps in the history — from 206 indexable pages to 316 by adding make × job category combinations, articles and pages by sector of Chisinau. The routes have language versions, a separate image sitemap, Open Graph images and the JavaScript bundle split for faster loading. The last commit fixed a detail that silently breaks indexing: the canonical address, the `hreflang` and the addresses in the sitemap now all emit the same form with a trailing slash.