P—02 · Systems analysisProduction

TechRent

A CRM for construction equipment rental — booking with availability checks, a fleet calendar, payments, manager permissions and an audit log.

Code

Role: Analysis, design, development with Claude Code (graduation project)
Period: 2026.06 → 2026.10
Status: Production
Stack: Go · PostgreSQL · React · TypeScript · Zustand · Docker · Nginx · OpenAPI · BPMN

Interface

01 / 06

Availability calendarA Gantt chart of equipment × days for September: orders by status and a bulldozer maintenance period as a yellow bar.

Problem

Small companies own equipment — excavators, cranes, dump trucks — and part of the time it sits idle. Renting it out pays, but rentals are tracked in spreadsheets and on paper. It is easy to promise one machine to two customers or hand over one that is under repair, and who owes what has to be worked out by hand. A heavyweight ERP is too expensive and too slow to roll out for this.

Solution

TechRent replaces spreadsheets with a simple web service for managers. The system checks whether equipment is free on the requested dates, calculates the rental price from the rates, tracks payments and shows who owes money. The administrator invites managers by link and grants them per-module permissions, and every change goes into an audit log.

A graduation project. I handed the finished system to a company with its own equipment fleet for review and got feedback from its head. I ran it as the analyst and architect — requirements, data model, API, role model — and wrote the code with Claude Code step by step, reviewing every step. I documented the key feature, booking, as an end-to-end case and accepted the implementation against the code, which surfaced 11 mismatches with the requirements.

Goals

01Prevent double booking and renting out broken equipment
02See the whole fleet's availability for a month in a minute
03Calculate prices and debts without manual maths
04Give managers exactly the permissions they need

Features

Equipment catalogue: daily and hourly rates, statuses, photos, maintenance periodsCustomers (companies and individuals) and their construction sitesBooking with availability checks and price calculationAvailability calendar — a Gantt chart of equipment × daysPayments with partial payment and overpayment protectionFinancial summary for a period and a list of debtorsManager invitations by link and per-module permissionsAudit log: who changed what and when, with before and after data

Key requirements

ID	Requirement	Priority
FR-01	One piece of equipment cannot have two active orders with overlapping dates — even under concurrent requests.	Must
FR-02	Broken equipment cannot be booked (422); equipment under maintenance cannot be booked for those dates (409).	Must
FR-03	Price: several days — daily rate × days inclusive; a single day — hourly rate × hours.	Must
FR-04	Payments on an order cannot exceed the order total.	Must
FR-05	The order number ТР-year-NNN is unique and never reused after an order is deleted.	Must
FR-06	A manager sees and changes only the modules the administrator opened to them.	Should
NFR-01	Integrity at the database level: CHECK, UNIQUE, foreign keys and an EXCLUDE constraint.	Must
NFR-02	Every create, update and delete is logged; a logging failure does not roll back the operation.	Must
NFR-03	The whole system starts with a single docker compose up.	Should

Scenarios

ManagerBooking equipment

01Finds free equipment in the calendar and marks the dates
02The form fills in the rates and calculates the total; the manager picks the customer and site
03In one transaction the server checks breakdowns, maintenance and overlaps
04The order gets number ТР-2026-015 and the event goes into the audit log

AdministratorInviting a manager

01Creates a manager and ticks the modules and actions they may use
02Gets a one-time link valid for 7 days and passes it on
03The manager sets their own password — the administrator never sees it
04Permissions go into the token at sign-in; the menu shows only what is allowed

Timeline

Steps 1–3FoundationDocker Compose, a Go API on Chi, migrations embedded in the binary, JWT and roles.
Steps 4–7Core recordsEquipment catalogue, customers and sites, orders with pricing, payments.
Steps 8–11ControlAudit log, Gantt calendar, equipment maintenance, date-derived order statuses.
Steps 12–14Staff and financeDetail panels, manager invitations and permissions, financial summary and debtors.
AcceptanceCase and feedbackThe end-to-end booking case, 11 findings from the code and the company's feedback; all three high-severity ones and repeated numbers fixed.
NextNotifications and documentsTelegram notifications, contract, invoice and certificate in PDF, fleet utilisation analytics.

Challenges

Double booking under concurrent requestsThe check and the write were separate queries. Now it is one transaction that locks the equipment row, plus an EXCLUDE constraint in the database: of 10 concurrent requests one succeeds and the rest get 409.

The form showed only part of the fleetA reviewing company with 24 machines could not find one: the server silently cut the list to 20. An explicit 400 instead of the silent clamp and a picker with server-side search.

Order numbers could repeatCOUNT + 1 handed out a taken number after a deletion. A per-year counter table: the number is issued inside the order transaction, never repeats and leaves no gaps.

Order status depends on today's dateThe database stores only planned and cancelled; active and completed are computed in SQL on read — no nightly jobs and no drift.

Outcome

A working CRM built in 14 steps — about 5,500 lines of Go and 6,500 lines of TypeScript — reviewed by a real company. An end-to-end booking case, OpenAPI, BPMN and a data dictionary; of 11 analyst findings all three high-severity ones and repeated numbers are fixed, and the races are verified with concurrent requests.

Next — server-side checks for order edit and cancel permissions, Telegram notifications and PDF documents.

Technologies

#Go #PostgreSQL #React #TypeScript #Zustand #Docker #Nginx #OpenAPI #BPMN

§ 2.1

Components

Three containers in Docker Compose. Nginx serves the React app and proxies /api to the Go service. Inside the service there are handler → service → repository layers wired through interfaces. Business rules live in the service, while invariants that no write path may break are enforced by PostgreSQL.

FIG. 02 — components

X 000 · Y 000

01
WEBReact + TypeScript. Zustand keeps the session, Axios refreshes the token, the Gantt chart is plain CSS.
02
NGINXServes the build, returns index.html for any SPA route, proxies /api and /uploads.
03
GO APIGo 1.24: handler → service → repository through interfaces. Migrations are embedded in the binary and run on start.
04
POSTGRESPostgreSQL 16: an EXCLUDE constraint against double booking, CHECKs on amounts and dates, a number counter.
05
UPLOADSA Docker volume with equipment photos.
06
TELEGRAMOrder notifications are the next step; the chat_id field is already in the schema.

§ 2.2

Booking equipment

Participants

01 · MANAGERFind free equipmentThe calendar shows orders and maintenance; broken equipment is hidden.
02 · MANAGERFill in the orderRates come from the equipment, the total is calculated, customer and site come from the database.
03 · SYSTEMCheck the datesFormat YYYY-MM-DD and end not before start, otherwise 400.
04 · SYSTEMCheck availabilityBroken — 422; maintenance or already booked for these dates — 409.
05 · SYSTEMSaveNumber ТР-year-NNN, status Planned, an audit log entry.
06 · MANAGERConfirm to the customerPasses on the order number and dates; on refusal picks other dates or equipment.

§ 2.3

POST /orders through the layers

Participants

01 · MIDDLEWARECheck the tokenJWT signature and expiry; id, role and permissions go into the context. No token — 401.
02 · SERVICEParse the datesStrictly time.DateOnly before any checks.
03 · REPOSITORYLock the equipmentBEGIN; SELECT status and maintenance … FOR UPDATE — requests for one machine queue up.
04 · SERVICECheck availabilityBreakdown, maintenance, overlap with active orders.
05 · POSTGRESNumber and insertUpsert into order_counters, INSERT … RETURNING with the computed status. EXCLUDE is the last safeguard.
06 · HANDLERResponse and auditCOMMIT, 201 with the order; a CREATE event in the log, whose failure does not change the response.

§ 2.4

Data model

An order references the customer, site, equipment and manager through foreign keys with ON DELETE SET NULL, so order history survives deletions from reference tables. Rates are copied into the order, so changing an equipment rate does not alter existing totals.

USERS6 f.

iduuidPK

emailvarcharUK

roleadmin|manager

permissionsjsonb

statusactive|pending

invite_tokenvarcharUK

EQUIPMENT8 f.

iduuidPK

namevarchar

categoryvarchar

statusenum

daily_ratenumeric

hourly_ratenumeric

maintenance_fromdate

maintenance_todate

EQUIPMENT_PHOTOS4 f.

iduuidPK

equipment_iduuidFK

urlvarchar

is_primarybool

CLIENTS5 f.

iduuidPK

typelegal|individual

namevarchar

innvarchar

phonevarchar

OBJECTS5 f.

iduuidPK

client_iduuidFK

namevarchar

addresstext

is_activebool

ORDERS12 f.

iduuidPK

numbervarcharUK

equipment_iduuidFK

client_iduuidFK

object_iduuidFK

manager_iduuidFK

statusplanned|cancelled

start_datedate

end_datedate

total_amountnumeric

paid_amountnumeric

payment_statusenum

PAYMENTS5 f.

iduuidPK

order_iduuidFK

amountnumeric

methodenum

created_byuuidFK

AUDIT_LOG6 f.

idbigserialPK

user_iduuidFK

actionvarchar

entity_typevarchar

old_datajsonb

new_datajsonb

Relations · 9

EQUIPMENT— 1 : N →EQUIPMENT_PHOTOS

EQUIPMENT— 1 : N →ORDERS

CLIENTS— 1 : N →OBJECTS

CLIENTS— 1 : N →ORDERS

OBJECTS— 1 : N →ORDERS

USERS— 1 : N →ORDERS

ORDERS— 1 : N →PAYMENTS

USERS— 1 : N →PAYMENTS

USERS— 1 : N →AUDIT_LOG

§ 2.5

API and integrations

GET/api/v1/calendar?from&toEquipment availability for a period, grouped by machine
POST/api/v1/ordersBook equipment: 201, 400, 409 (taken, maintenance), 422 (broken)
PUT/api/v1/orders/{id}Update an order; the order itself is excluded from the conflict check
PATCH/api/v1/orders/{id}/statusCancel an order — only cancelled is accepted
POST/api/v1/paymentsRecord a payment; overpayment is a 422 inside the same transaction
GET/api/v1/finance/summary?periodSummary for a month, quarter or year plus current customer debts
POST/api/v1/usersInvite a manager: a 7-day link and per-module permissions
GET/api/v1/auditAudit log with before and after data (administrator only)

Nginx → Go APIHTTP · REST JSONNginx serves the React build and proxies /api and /uploads to the service.
JWTBearerA 1-hour access token and a 7-day refresh token; manager permissions live in the token.
Telegram (planned)Bot APINotifications on order creation and cancellation; the telegram_chat_id field already exists.

§ 2.6

Key decisions

Decision 01

Order statuses are derived from dates

Choice: The database stores only planned and cancelled; the rest is a CASE WHEN in every SELECT.
Rationale: The status is always current at read time, with no background job that could fail.
Alternatives: Store every status and update them with a nightly job.

Decision 02

Equipment row lock plus EXCLUDE

Choice: SELECT … FOR UPDATE on the equipment row inside the order transaction, and an exclusion constraint on the date range.
Rationale: The lock yields a clear 409 and serialises booking and maintenance; EXCLUDE guards every write path.
Alternatives: A check in code only — lets races through.

Decision 03

Manager permissions in the JWT

+ Pros: No database query per request; The service stays stateless
− Trade-offs: Changed permissions apply after the next sign-in — up to an hour

Decision 04

Invite link instead of a temporary password

Choice: A 32-byte token from crypto/rand valid for 7 days; the manager sets the password.
Rationale: The password is never sent over messengers and the administrator never knows it.

Decision 05

A counter table for numbers

Choice: order_counters per year, upserted inside the order transaction.
Rationale: MAX + 1 reuses a deleted order's number and a SEQUENCE leaves gaps — neither is acceptable for contracts and invoices.

Next · P—01Mito