
ZR Avto
LiveB2B automotive parts platform — catalog, ordering, and inventory for wholesale buyers.
- Python/FastAPI
- React/Next.js
- PostgreSQL
- Docker
I design and build ERP systems, business platforms and SaaS products that companies rely on every day.
Operations break down in the gaps — between a spreadsheet and an order, between what a team knows and what the system actually records. That is where I work.
I build ERP platforms, internal tools and SaaS products that close those gaps: one source of truth, automated where the work repeats, and fast enough that nobody builds a workaround.
Every decision gets made twice — once for the release, once for the version of the system that has to exist in three years. Maintainability and performance are not polish. They are what keeps a platform worth running.
Each project solves an operational problem — cutting manual work, keeping data consistent, and giving the business something it can keep growing into.

B2B automotive parts platform — catalog, ordering, and inventory for wholesale buyers.

Multilingual tourism platform — tours, booking, and guides for visitors to Azerbaijan.
Salon booking SaaS — appointment scheduling and queue management for small businesses.
Task management SaaS built for Azerbaijani SMBs — projects, teams, and workflows.
Technology changes. Engineering principles do not. I choose maintainability over shortcuts, clarity over cleverness, and long-term scalability over quick wins.
Readable code wins. Someone opening this in three years should understand it without an archaeologist.
Secure by design, never bolted on. Auth, authorisation, validation and rate limits belong in the first version of a feature.
Every interaction should feel instant. Server-rendered by default, images sized, transform-only animation. Speed is a constraint, not a later optimisation.
Technology exists to solve a problem. If a feature does not cut work, cut error or add clarity, it does not ship.
Eight steps, in order. The expensive decisions happen early, where changing them is still cheap.
Understand the business goal, find the bottleneck, define scope, and put the highest-value work first.
Wireframes, data model, API surface. Decided before code, so the build has a target rather than a direction.
Flows before screens — the fewest steps to the outcome the user actually came for.
Boundaries, data ownership, failure modes. The decisions that are expensive to change later get made here.
Component-driven, typed end to end, reusable by default. Small pieces that compose into a system.
Responsive, accessibility, performance and regression passes — on real devices, not just a resize handle.
CI on every push, containerised builds, monitoring and logging from day one, and a rollback that has been tried.
Maintenance, updates, optimisation, scaling. Shipping starts the system's life; it does not end it.
TypeScript in strict mode, end to end. The compiler catches what a review misses.
Every change read before it merges, by a second pair of eyes or a rested one.
A design system, not one-off styling. One change lands in one place.
Why, not what. Decisions recorded where the next person will go looking.
ESLint and formatting enforced in CI, so style is never a review topic.
Build, typecheck and lint gate every push; behaviour is verified before release.
Signed, expiring sessions. Secrets stay on the server, always.
Checked on the server for every action, never inferred from a hidden button.
Untrusted input validated server-side before it reaches the data layer.
Login and public forms throttled per client, so brute force and spam cost something.
TLS everywhere, hashed credentials, and security headers set at the edge.
Content and data recoverable. A restore that has never been run is not a backup.
The next developer to open it — often me — should be able to change it without fear. That is most of the job.
Every engagement is built to cut manual work, make the numbers trustworthy, and leave you with a system that can still grow next year.
Centralise operations, inventory, customers, orders and reporting inside one platform instead of five spreadsheets.
Scheduling that reflects real availability, so double-bookings and phone-tag stop being part of the day.
Catalogues that stay accurate at scale, with a checkout that does not lose the customer halfway through.
Multi-tenant products with roles, billing and dashboards designed in from the first release rather than retrofitted.
The repetitive parts of the week moved into background jobs, integrations and scheduled reports.
Typed APIs, third-party sync and migrations off legacy systems — without a weekend of downtime.
The things most people want to know before the first call.
A focused MVP is usually four to eight weeks. A full ERP or multi-module platform runs longer and ships in stages, so you have something usable well before the last feature lands. You get a scoped timeline after discovery, not before it.
Fixed price per scoped phase, so you know the cost before work starts. Scope comes out of discovery — a short paid or free session where we define what the system actually has to do. Open-ended hourly billing is available but rarely the right fit.
Yes. Rebuilding from scratch is often the wrong call. I audit what exists, keep what earns its place, and replace the parts that block you — incrementally, so the business keeps running through it.
That is usually the right way in. Build the one workflow that hurts most, put it in front of real users, and let what you learn shape the rest. The architecture is planned for the full system from day one, so the MVP is a foundation rather than a throwaway.
Yes — updates, monitoring, optimisation and scaling after launch. Shipping starts the system's life. Ongoing support can be a retainer or on-demand, whichever matches how much the system changes.
Yes: payment providers, accounting systems, logistics, government or partner APIs. If it has documentation it can be integrated; if it does not, it usually still can, with more discovery time.
Yes, before any detail is shared. Client systems, data and business logic stay confidential — nothing appears in this portfolio without permission.
Yes. I work with in-house developers, designers and agencies, in the client's tools and process. Written updates and reviewable code mean the work stays visible without daily calls.
Whether you're launching a new product or modernising a system that has outgrown itself, tell me what it needs to do and I'll tell you what it takes.