Akkan

Muzaffer Mert Akkan

Software engineer — ERP & business systems

Samarkand, Uzbekistan

Building a university ERP full time · Open to selected projects

I build the software an organisation runs on — and I own all of it, from the first conversation to the deployed product.

mert@akkan.dev

Muzaffer Mert Akkan — software engineer, ERP and business systems, Samarkand

01 — What I do

Requirements. Systems. Deployment.

Most organisations run on spreadsheets, a legacy system nobody dares touch, and a tool that almost fits. I replace that with software built around how the work is actually done.

I work alone, end to end. I sit with the people who do the work, model their records and rules, build the interfaces they use every day, and put the result on a server I maintain. There is no hand-off between someone who understood the problem and someone who wrote the code.

Recent work: a university ERP in daily use by its HR department; a quotation and design system for an aluminium manufacturer, on desktop, mobile and web; a sales back office for a property developer; a survey that 4 000 students used in its first week without a single failed request.

What I build

  • ERP and back-office systems

    Staff, students, clients, inventory, bookings, contracts — records with history, permissions and audit trails.

  • Quotation, pricing and document generation

    Exact pricing rules, bills of materials, PDF and Excel output that accounting can rely on.

  • Desktop, mobile and web from one codebase

    The same business logic on every device the client’s people actually use, including offline.

  • Replacing legacy and off-the-shelf tools

    Data migration from spreadsheets and old systems, with every record reconciled, and no downtime for the people using it.

  • Multilingual by default

    Uzbek, Russian, English and Turkish interfaces, with one number and date format across all of them.

  • Deployment and operation

    Docker, CI/CD, backups, load testing before launch, and patches applied to live databases that are never rebuilt.

WEB · DESKTOP · MOBILE · POSTGRESQL · TYPESCRIPT · PHP

02 — Work

Five systems.

Two in daily use, one in production with its client, two in development. Every figure below is real and current as of September 2026.

In daily use

2026 — ongoing

Kampus: a university ERP

For: a state technical university in Uzbekistan — about 9 000 students, 800 staff

A university-wide ERP designed and built from nothing by one developer, as the university’s full-time ERP engineer. The HR module — every operation on academic and administrative staff — is finished and in daily use. Academic modules (curricula, course registration, grading, transfers, transcripts, graduation audits) are built and awaiting rollout.

What changed for the client

Staff records that used to live in spreadsheets now have a single source of truth with full history: every change is dated, backed by a document, and attributed to the person who made it.

Administrative document workflows run inside the system instead of across email and paper.

Four interface languages for a multilingual staff.

  • ~120 database tables
  • 230+ stored functions holding the business rules
  • 8 341 student records imported and reconciled
  • 4 interface languages

Detail

Six PostgreSQL schemas. Business rules live in PL/pgSQL functions and constraints, so they hold regardless of which application calls them; a Laravel API exposes them to a React/TypeScript front end. Staff records are effective-dated with document-backed changes and actor-attributed audit trails. Role-based access control and Microsoft Entra ID single sign-on. Reproducible imports of legacy Excel data covering 8 341 students, 97 degree programmes and about 4 000 courses, with every discrepancy reported rather than silently fixed. Transactional upgrade patches, verified nightly backups, Docker deployment on the university’s own servers.

Hardest part: requirements. HR’s process existed in people’s heads and in years of spreadsheets; the model had to hold every historical state without inventing rules the department never had.

Live

2026

A survey that 4 000 students used in a week

For: the same university — its 8 962 active students

Every year the university decides which elective courses to open, and until this year it decided before asking the students. This is a mobile-first application where students sign in with their university account and rate every elective on offer, for both semesters at once. The office reads the demand and opens courses accordingly.

What changed for the client

The decision is now made on data: 244 courses turned out to be wanted by nobody, which the university needed to know before opening them.

A registrar export that had left out 260 students was corrected with a data re-import, not a code change, in the middle of the survey.

Zero failed requests through a launch week in which thousands of students arrived through one campus network address.

  • 4 071 students signed in, first eight days
  • 34 152 course ratings given
  • 2 644 ratings in the busiest hour
  • 0 failed requests with 500 students in the same second

Detail

PostgreSQL, PL/pgSQL, Laravel, React, TypeScript; Microsoft Entra ID sign-in; four languages for every screen and all 860 course descriptions. Transactional row locking so ratings cannot race with survey finalisation — verified with 2 000 contended operations across 50 pgbench clients, zero failures. k6 burst test: 500 students in the same second, p95 252 ms, zero failures; sustained test: 14 238 requests, zero failures. The load tests found two bugs before go-live — nginx keep-alive starving php-fpm, and a rate limiter counting the whole campus NAT as one student — both fixed before the first morning. The live database has taken 12 idempotent schema patches and has never been rebuilt; every patch ends by diffing the live schema against the checked-in one.

In production

2025 — 2026

Plana: design, pricing and quotation for a manufacturer

For: an aluminium window-and-door manufacturer in Samarkand

A desktop editor for designing window and door systems, a mobile companion, and a website with dealer and admin portals. It replaced a third-party design and quotation tool the company could not extend with software the company owns. Desktop, mobile and web are all in use.

What changed for the client

Commercial proposals go out faster and are exact: every profile, glass, seal and hardware quantity is calculated, not estimated.

Dealers work in their own portal with their own tier pricing and order tracking.

The company owns the software and its roadmap; the client has said so in writing about the desktop editor.

  • 3 platforms sharing one set of business rules
  • 1 009 automated tests on pricing, geometry and persistence
  • 1 click to release a new Windows version to every installation

Detail

TypeScript throughout. Geometry, pricing, bill-of-materials, cutting lists and document generation live in shared packages consumed by the Tauri desktop app, the React Native/Expo mobile app and the Next.js site, so a pricing rule is written once. Scenes render through Konva on desktop, Skia on mobile and SVG on the web from the same model. Offline-capable persistence with synchronisation, team-isolated project access, dealer tier pricing, order tracking and an inventory movement ledger. Money is stored in integer minor units and exchange rates are locked when an invoice is issued, so a quotation never changes after it is sent. Windows installers and in-app updates ship through GitHub Actions.

Hardest part: precision under real consequences. The PDF offer is the document the customer signs; a rounding error in a cutting list is a physical mistake in a workshop.

In development

2026 — ongoing

Nivo: a sales back office for a property developer

For: a residential property developer

An in-house replacement for a rented multi-tenant sales platform: the developer’s stock of flats, its clients, bookings, contracts, payment schedules, debts and documents in one system it controls. Inventory, clients and bookings are built; contracts and payments are next.

What changed for the client — so far

The real stock — 596 flats across five blocks — is imported and reconciled against the old system’s own totals, figure by figure.

Every price change, booking and cancellation is recorded with who did it, when and why, in a log the database itself refuses to let anyone edit.

Excel exports whose totals are computed by tested rules, so two people never see two different figures.

  • 596 flats reconciled from the previous system
  • 34 recorded architecture decisions
  • 3 languages, Russian first

Detail

TypeScript monorepo: Next.js (server components and server actions), PostgreSQL 18 with Prisma, a pg-boss worker for exports, documents and scheduled jobs — no Redis. Domain rules in a framework-free core package with a unit test per rule; statuses change only through named events; CHECK constraints refuse what can never be true. Every business table carries a company id and is read through a scoped client, so the single-company deployment can become multi-tenant without reshaping data. Append-only audit log enforced by database triggers. Sessions and passwords implemented without an auth library. Clean-room implementation from a functional audit of the old system; no vendor code or assets.

Every lasting decision is an ADR in the repository — 34 at the time of writing — so the client’s next developer, if there ever is one, inherits the reasoning and not only the code.

In development

2026

A unified inbox for a private hospital

For: a private hospital in Samarkand

Patients write to the hospital through Telegram, phone, Instagram and reviews, and each channel was answered by whoever happened to see it. This system turns every inbound message into a conversation with a status, an owner and a measured response time, so management can see what was answered, how fast, and by whom. Phase one connects Telegram — bot, business account and channel comments — on a core designed so that other channels are plug-ins.

What changed for the client — intended

No inquiry lives in a personal phone; every one has an owner and a deadline.

Supervisors see the live backlog and weekly per-operator reports in one click.

Data stays on servers in Uzbekistan.

  • ≤ 3 s inbound message to inbox, p95 target
  • 100 % of inbound messages reconciled against the source

Detail

Channel-adapter architecture: the ticketing core never imports Telegram types; a new channel is one adapter and one settings page. Telegram Business connected accounts, bot API and discussion-group comments as three adapters over one normalised event schema. Statuses, assignment, teams, canned responses, SLA timers with business hours, cross-channel contact identity, server-side permission enforcement and an audit log. Written first as a specification with explicit decision and verification markers, then built against it.

Have something like this to build?

mert@akkan.dev

Earlier work: a five-language university website with a 12-block page builder (Lighthouse 100 for accessibility, best practices and SEO), a three-language medical-centre site (Lighthouse 99–100), and open-source projects on GitHub.

03 — Approach

Three things to expect.

Understanding first.

I don’t start from a feature list. I start with the people who do the work and the documents they already produce, and I model the records and rules they actually live by — including the exceptions nobody wrote down. The software follows from that model, not the other way round.

Proof — The HR module holds every historical state of a staff record because the department needed it, not because it was elegant. The manufacturer’s quotation rules were audited line by line before a single screen existed.

One person, whole product.

Requirements, data model, interfaces, deployment, operation: I do all of it. Nothing is lost between the person who understood the problem and the person who built it, and nothing waits for a hand-off.

Proof — A university ERP with ~120 tables and 230+ database functions, four languages, in daily use, built by one developer. A survey used by 4 000 students in its first week, built and run by one developer.

Built to hold.

The systems I build carry money, contracts, grades and staff records. They are tested under the load they will meet, their rules are enforced in the database and not only in the interface, and every change is on record.

Proof — 500 students in the same second, zero failures. 1 009 tests on a pricing engine. Audit logs that database triggers refuse to let anyone edit. A live database changed twelve times and never rebuilt.

04 — On record

  • 9 000 students at the university whose ERP I build
  • 120 tables in that ERP, 230+ functions holding its rules
  • 8 341 legacy student records imported and reconciled
  • 4 071 students who signed in to the elective survey in eight days
  • 0 failed requests with 500 students in the same second
  • 1 009 automated tests on the manufacturer’s pricing and geometry
  • 596 flats reconciled into the property developer’s new system
  • 4 languages I work and build in

Figures as of September 2026. Nothing here is rounded up.

05 — Contact

If you have an operation that has outgrown its tools, write to me. Describe the work, not the software — I’ll take it from there.

I reply within two working days. Russian, Turkish, English and Uzbek are all fine. I work on site in Samarkand and remotely with clients in Uzbekistan, Kazakhstan, Russia and Türkiye.