Dobrion — A Ukrainian-First Volunteering Platform Shipped in 12 Days

Industry: Social Impact / Volunteering Platform · Civic Tech Region: Ukraine Engagement: Fixed-scope MVP delivery Timeline: Jul 2026 – Present Delivery: Full-domain MVP shipped in 12 calendar days (02–13 July 2026) Status: MVP delivered and deployed; actively iterated

Foreword

Ukrainian volunteering runs on group chats. A need appears in a Telegram channel, a dozen people reply "+", someone keeps a list in a spreadsheet, the work happens, and the proof of it disappears into a photo album nobody outside the group ever sees. The energy is real; the infrastructure is not. Nothing is searchable, nothing is verifiable, and an organization that has run two hundred successful deeds has no durable public record to show a donor.

Dobrion was commissioned to give that activity a permanent home: one place where a verified organization publishes a good deed with its concrete needs, a volunteer joins the specific need they can actually cover, and the finished deed produces a public report with its own address that can be shared anywhere.

The constraint was the deadline. The client needed a working, demonstrable product — not a clickable mock — within a two-week window, and the date was fixed by commitments outside the build: partner organizations waiting to onboard, and funding conversations that needed something real to point at. Engain took the project from an empty repository to a deployed MVP covering the full domain — accounts, organizations, deeds, needs, applications, reports, moderation, and a public, search-indexable impact layer — in 12 calendar days, and did it with migrations, automated tests and a CI gate in place from the first week rather than deferred as debt.

1. Project Summary

2. Client Description

3. Story

The client arrived with a thick product vision — a social network for good deeds, an internal contribution currency, a trust-and-reputation layer, a resource exchange, a map and calendar of activity across the country. What they did not have was a first version anyone could use. The risk was the familiar one for mission-driven products: spend a year building the full vision and reach the market with nothing, or ship something thin that cannot carry the vision later.

Engain's first contribution was scope surgery, and the deadline is what forced it to be decisive. With two weeks to a fixed date, there was no room for a feature list negotiated by addition. We worked back from the one loop that makes the platform worth existing — publish a need, match a volunteer to it, prove the outcome publicly — and treated everything else as a later phase that the data model had to leave room for. Contribution tokens, gamified statuses and the resource exchange were deliberately cut from the window; the entities, role model and reporting schema were designed so they can arrive later without a rewrite. Cutting scope was the only lever we would allow ourselves — schema discipline, test coverage and the CI gate were explicitly ruled out as places to buy time, because the roadmap continues directly on this codebase.

From there we owned the whole stack: domain modelling and the relational schema, the NestJS API, the Next.js application, the Dobrion brand and design system, Ukrainian localization down to validation messages, transactional email, file storage, the local Docker environment, the CI gate, and the production deployment topology. The client had a single point of accountability across backend, frontend, design, and DevOps rather than four vendors negotiating an interface.

Two properties shaped every decision. First, the product is Ukrainian-first, not localized-into-Ukrainian: Ukrainian is the source language of the interface, of validation errors, of every email, and no English string is permitted to reach a user. Second, it is public by design — deeds, organizations, volunteers and reports all have addresses that work without an account, render branded social cards, carry Schema.org markup, and appear in a generated sitemap — because a volunteering platform that cannot be shared outward cannot grow.

4. Provided Services

• Product & requirements engineering — MVP scope definition against the client's vision documents, gap analysis, and per-feature written design specs and implementation plans (17 such documents live in the repository).
• Domain modelling & database engineering — relational schema design and 16 incremental migrations that rebuild the database from zero.
• Backend engineering — NestJS 11 REST API across eight feature modules, session authentication and authorization, transactional email, file storage, background jobs.
• Frontend engineering — Next.js 16 App Router application, 20 routes, authenticated product surfaces plus four families of public pages.
• UI/UX & design system — the Dobrion brand (palette, typography, mark), semantic design tokens with light and dark themes, and a component library on shadcn/ui and Tailwind CSS 4.
• Localization — Ukrainian-source i18n via Lingui across UI, forms, validation, API messages, and email templates.
• SEO & social distribution — public entity pages, dynamically generated Open Graph cards, Schema.org structured data, canonical URLs, robots policy, and a dynamic sitemap enumerating every public deed and report.
• QA & test automation — API unit and end-to-end suites, web component suites, and Playwright browser tests, all gated in CI.
• DevOps — Docker Compose development environment, GitHub Actions CI, multi-service production deployment, error monitoring, and environment configuration management.

Technology Stack by Layer

5. Requirements & Challenges

• Trust is the product, not a feature. A wartime volunteering platform is a high-value target for abuse: fake organizations soliciting funds, harvested volunteer phone numbers, fabricated outcomes. The MVP therefore needed an organization verification gate before publishing rights, role separation across volunteer / organization / moderator / admin, a complaint pipeline, account suspension, and content takedown that provably removes an item from every public surface — not just from a list view.

• Personal data must flow only where it is earned. Volunteers submit a phone number in order to be reachable; that number must reach the organizer of the deed they applied to and nobody else. Public profiles, public deed pages and report pages all render from the same entities but must expose strictly reduced field sets, with participant photos hidden from volunteers who have not been approved.

• "Needs" had to be a first-class, mutable object. Real deeds do not ask for "volunteers"; they ask for four drivers, one pharmacy partner, and ₴30,000. The model needed typed needs (people, partners, financial, other), editable after publication, multi-selectable at application time — and, later, able to represent a need a volunteer proposed and the organizer adopted, without forking into a second table.

• Discovery is geographic and temporal at once. Volunteers search by what is near them and what is happening soon. That meant address autocomplete, a calendar with period views, a map view, and filters by city, radius, category, status, organizer and the viewer's own participation — composed, not alternative.

• Outcomes had to be publicly verifiable and independently shareable. A report buried inside a deed page cannot be sent to a donor. Each report needed its own permanent address, its own social card, arbitrary named impact metrics, a confirmed participant list drawn from approved applications, and automatic notification to everyone who took part.

• Ukrainian-only, with no leakage. Every string a user can reach — including library-generated validation errors and email subject lines — had to be Ukrainian, with the Ukrainian catalogue treated as the source of truth rather than a translation target.

• Mobile-first under real conditions. The primary device is a phone, frequently on a poor connection. Long organization names, long filenames and dense filter bars all had to survive narrow viewports without breaking page layout, and uploads needed visible per-file progress and cancellation.

• A hard two-week deadline, with no MVP debt permitted. This was the governing constraint on the entire engagement. The client had a fixed date driven by partner onboarding and funding conversations, and the scope was an entire domain — accounts, organizations, deeds, needs, applications, reports, moderation, public pages — not a single feature. The engineering constraint ran against it: the result had to be a production foundation with migrations, automated tests, a CI gate, error monitoring and environment separation, because the roadmap continues directly on top of it. Two weeks of throwaway velocity would have cost more than it bought. Reconciling those two demands — ship a full domain by the date, and ship it on a foundation that survives — drove nearly every architectural decision in section 8.

6. Solution Overview

Delivery model. Under a fixed two-week deadline the instinct is to skip process and start typing. We did the opposite, because rework is what actually consumes a short window. Work proceeded feature-by-feature through a fixed loop: written design spec → implementation plan → implementation → automated tests → review → merge through CI. The repository carries that history explicitly — 17 design specs and plans covering the calendar rebuild, event editing, application status visibility, need multi-select, share cards, upload progress, event deletion, proposal adoption, and donation links. Nothing non-trivial was written directly into code. Combined with AI-orchestrated implementation across all four tracks in parallel — backend, frontend, design system and DevOps — that is what made a full-domain build fit the window: decisions were made once, on paper, and executed at machine speed rather than debated mid-implementation.

Phase 1 — Foundation (02–03 July). Single pnpm workspace with three packages: api (NestJS), web (Next.js), and shared (the cross-stack type contract). A complete Docker Compose development environment — PostgreSQL, Redis, API, web, an SMTP interceptor for mail testing, and an Nginx reverse proxy — plus git hooks, a GitHub Actions CI gate, and production deployment wiring. The Dobrion brand system landed in the same phase, so no feature was ever built against placeholder styling.

Phase 2 — Core domain (04–06 July). Authentication, invites, users, organizations, moderation, and the deeds domain across both backend and frontend; the enum contract centralized into @shared/types and bundled into the API build; full Ukrainian localization; the events calendar and map with Google Places geocoding; mandatory email verification; and a security-audit remediation pass covering error mapping, pagination cursor validation, upload caps, URL scheme enforcement and session regeneration on authentication.

Phase 3 — Participation & public surfaces (07–13 July). The application lifecycle with its full status matrix; needs editing and multi-select; organizer-side review context including applicant profile and reachable phone number; community photo galleries; the four families of public pages with branded Open Graph cards and structured data; standalone public reports with impact metrics; per-file upload progress; and the dynamic sitemap.

Phase 4 — Post-MVP iteration (17–23 July). Deed deletion for authors and platform staff, a reworked needs editor, adoption of volunteer-proposed needs into the deed itself, donation links on financial needs, boot-time migrations for the deployment platform, and a configuration flag to temporarily bypass organization moderation while the client's verification process is staffed.

7. Features

Good deeds lifecycle. Create, edit, clone and delete a deed; a status lifecycle of upcoming → ongoing → completed; eight categories (humanitarian, logistics, medical, education, evacuation, fundraising, community, other); geolocation via Google Places with coordinates resolved server-side from the place identifier; map rendering and a Google Maps link.

Itemized needs. Each deed carries typed needs — volunteers, partners, financial, other — editable after publication through a dedicated editor. Financial needs support a donation link, turning a stated funding gap into a one-click contribution path. Needs are tagged by origin, distinguishing what the organizer asked for from what a volunteer proposed.

Volunteer-proposed needs and adoption. When applying, a volunteer can select multiple existing needs and propose something the organizer did not think to ask for. The organizer can then adopt a proposal into the deed as a real need, where it becomes visible and joinable for everyone else — turning the application form into a channel for supply the organizer did not know existed.

Applications and participation. Apply with a mandatory phone number; the organizer approves or declines with full review context (applicant profile, application date, selected needs, reachable contact details) and a pending-count badge on their deed list. Volunteers can withdraw; re-application is blocked after a decline and permitted after a withdrawal. Application status is surfaced consistently on deed cards, the deed page, the calendar and the activity feed.

Calendar and map. Period-based calendar views for volunteers, organizers and the dashboard, with filters by city, proximity radius, category, status, organizer and own participation, plus a personal calendar of the deeds a user has joined. A map view carries the same filter set.

Discovery feed. A card-based catalogue of deeds with cursor pagination and a mobile-adapted, horizontally scrollable filter bar.

Photos and galleries. Photos attached at creation time through a staging upload; a full-screen lightbox with gallery navigation; and a community gallery where approved participants contribute their own photos, hidden from volunteers who have not been approved.

Public impact reports. Organizers submit a summary, activity list, partner organizations, photos, arbitrary named impact metrics validated on both sides, and a confirmed participant list selected from approved applications. Each report is published at its own permanent address with its own branded social card, timestamped with its publication date, and announced automatically by email to the organizer and every approved participant.

Organizations. Registration with legal identifiers (including EDRPOU), legal type, contact person, phone, description, website, activity areas and logo; an administrator verification workflow with notification of approval or rejection; a settings page; a publishing gate until verification passes; and a rating computed from completed-deed scores.

Volunteer profiles. Editable profile with avatar, biography, city (via address autocomplete), skills and social links; a reduced public profile available only for active accounts and carrying no contact details; and a share action with a branded card.

Public surfaces and SEO. Account-free public pages for four entity types — deed, organization, volunteer, report — each with a dynamically generated Open Graph card compositing the entity's photo onto the brand template, Schema.org structured data (Event, Organization, Person, Report, BreadcrumbList), canonical URLs, robots control, branded not-found pages, and a share panel for Facebook, Telegram, X, Viber and WhatsApp. A dynamic sitemap enumerates every public deed and report, and a guest who clicks "join" is returned to the deed after registering or signing in.

Moderation and administration. Complaint submission and processing; moderator takedown that removes a deed from every public surface; user status and role management; an admin panel with platform statistics; and a persisted activity feed rendered as a day-grouped timeline for organizations, moderators and administrators.

Authentication and access. Session-based registration and sign-in with Redis-backed cookie sessions; mandatory email verification by code with resend; password reset by single-use link; OAuth sign-in and account linking for Google and Facebook, with provider buttons hidden when a provider is not configured; and an invite system whose tokens exist in the database only as cryptographic hashes.

Transactional email. Ten branded Ukrainian templates — welcome, email verification, password reset, invite, new application, application approved, application declined, organization verified, organization rejected, and report published — rendered from React components and delivered through an interchangeable driver.

8. Stack

Key Architectural Decisions

9. Engain AI-Native Approach

10. Project Timeline

11. Project Outcomes

• The deadline was met, at full scope. Eight backend modules, sixteen database migrations, twenty application routes, four families of public pages and ten transactional email templates went from empty repository to deployed product in 12 calendar days — with the migrations, automated tests, CI gate and error monitoring of a production system rather than a prototype's shortcuts. Nothing in the committed scope was traded away to hit the date, and nothing was left as debt to pay down afterwards: iteration resumed on the same codebase four days later.

• Coordination moved out of group chats into structured, itemized needs. By making the need the unit of matching rather than the event, the platform can tell an organizer exactly which of their asks is still uncovered, and let a volunteer commit to precisely what they can deliver. Volunteer-proposed needs turn the application form into a discovery channel for supply the organizer did not know to ask for.

• Every completed deed now produces a public, verifiable artefact. Reports have their own permanent addresses, branded social cards, confirmed participant lists and organizer-defined impact metrics — giving organizations a durable accountability record to show donors, and giving the platform a growth surface that works without an account.

• Trust and data protection built into the architecture, not bolted on. Verification-gated publishing, four-role separation, revocable server-side sessions, a complaint and takedown pipeline that clears every public surface, explicit response serialization, and ownership-scoped lookups together mean the platform's safety properties are enforced by structure rather than by discipline.

• Genuinely Ukrainian-first. With Ukrainian as the source locale — including validation library messages and every email — the product reads as built for its users rather than translated for them, and shipping an untranslated string is structurally prevented.

• A foundation the roadmap can land on. Contribution scoring, trust marks, the resource exchange and financial integrations were consciously deferred, but the role model, entity schema and reporting layer were designed to receive them. The next phase extends the MVP; it does not replace it.

• Ongoing effort reduced by AI-automated maintenance. With delivery complete, AI agents handle routine triage, maintenance and dependency work — keeping a social-impact platform's running cost proportionate to a non-profit budget.

Interested in a comparable delivery? Book a call with Engain.