Project Builder Platform: engineering projects, auctions and document workflows

Project Builder Platform was a product system for managing engineering projects. The workflow involved customers, moderators, chief engineers, contractors and administrators. A user could move through project creation, auctions, discussions, file uploads, approvals and final delivery.

The hard part was not CRUD. The hard part was the amount of business rules: who can see which action, which statuses are changed manually, which processes should finish automatically, which notifications must not be lost, and how document versions should move through a signing workflow.

My Role

I worked on backend architecture and core business modules. During part of the project I also handled fullstack development and helped bring the product to an MVP state: backend, frontend flows, infrastructure and deployment setup.

My responsibilities included:

• backend architecture based on Clean Architecture and CQRS;
• GraphQL API on NestJS/Fastify;
• domain modelling for projects, roles, auctions, files and documents;
• a multi-round auction system with statuses, automatic completion and real-time updates;
• chats, notifications and background jobs using Redis, BullMQ and WebSocket;
• document workflow: file versions, signing chains, S3 storage and asynchronous PDF conversion;
• Docker infrastructure, CI/CD and deployment process.

Architecture

I kept transport concerns separate from business scenarios. A resolver accepted the request and validated input, while command/query handlers coordinated the use case. Status rules, permission checks, side effects and persistence details were placed in domain services and repositories.

This mattered because the project had many stateful workflows. An auction was not just a list of bids: it had rounds, timing rules, participant state, UI events and background jobs. Documents were not just uploaded files either: they had versions, signing history and conversion jobs.

Non-Trivial Parts

The most sensitive area was state transitions. If those rules are scattered across resolvers and services, each new condition can break a neighboring workflow. I kept workflows explicit so that allowed transitions and permissions were visible in one place.

Another important part was asynchronous processing. Notifications, auction completion and document conversion should not block the user-facing request. Queues and Redis helped keep those operations reliable while real-time events were delivered separately.

Result

The result was an MVP of a complex platform with roles, auctions, documents, notifications, chats and project management flows. For me, this case is mostly about engineering judgement: not just writing an API, but keeping the domain model maintainable while the product keeps growing.