A Ukrainian-First Volunteering Platform Shipped in 12 Days
Services: Product Engineering · Backend · Frontend · UI/UX Design · DevOps · QA
The team: [confirm size] — Senior Backend · Senior Frontend · UI/UX Designer · DevOps engineer
Technologies: Next.js · NestJS · PostgreSQL · Redis · TypeScript · React Native (planned)
Integrations: Google Places (address autocomplete + geocoding) · Google Maps · Cloud blob storage · SMTP / transactional email
Timeline: Phase 1 — MVP delivery: 02–13 July 2026 (12 calendar days) Phase 2 — Post-MVP iteration: 17 July 2026 — Present
Website: www.dobrion.net
Customer profile
The client is a Ukrainian social-impact initiative building a national volunteering network. Their audience: volunteers, charitable and civic organizations, and donors across Ukraine. Their thesis: 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 vision is bigger than the MVP: an "economy of good" with contribution scoring, trust marks and a resource exchange on the roadmap. Phase 1 was about proving the core loop — publish a need, match a volunteer to it, prove the outcome publicly — with a foundation the rest of that roadmap can land on.
Challenge
The client needed a working, demonstrable product — not a clickable mock — within a two-week window. The date was fixed by commitments outside the build: partner organizations waiting to onboard, and funding conversations that needed something real to point at. 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 that: 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.
Two harder constraints layered on top. First, trust is the product, not a feature — a wartime volunteering platform is a high-value target for abuse: fake organizations soliciting funds, harvested phone numbers, fabricated outcomes. Second, 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.
The solution
Under a fixed two-week deadline the instinct is to skip process and start typing. Engain 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. 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.
Engain owned the whole stack: domain modelling, the API, the web application, the Dobrion brand and design system, Ukrainian localization down to validation messages, transactional email, file storage, the local development 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.
User roles
-
Volunteer — Discovers deeds by category, city, radius and date; applies to specific needs they can cover; proposes needs the organizer didn't think to ask for; tracks their participation across a personal calendar and activity feed.
-
Organization — Registers with legal identifiers and completes a verification workflow before publishing rights; creates and edits deeds with typed, itemized needs; reviews applications with full applicant context; publishes public impact reports on completed deeds.
-
Moderator — Reviews complaints and coordinates takedowns; a takedown provably removes an item from every public surface (list views, entity pages, sitemap, share cards) — not just from a single list.
-
Administrator — Full platform access with a dedicated admin panel: user status and role management, platform statistics, and a persisted activity feed rendered as a day-grouped timeline.
Every action on Dobrion — a deed created, an application submitted, a task completed — flows into that persisted activity feed. Organizations use it to see what's happening across their volunteers; moderators use it as a quick audit trail.
Key features
Good deeds lifecycle
Organizations create, edit, clone and delete deeds through a dedicated editor. Each deed carries a status lifecycle (upcoming → ongoing → completed), one of eight categories (humanitarian, logistics, medical, education, evacuation, fundraising, community, other), and geolocation via address autocomplete with map rendering.
Itemized needs
Instead of asking for "volunteers," 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. This makes the need the unit of matching, not the event.
The screenshot below shows a real published deed with nine distinct itemized needs, each tagged Partner (for material/financial contribution) or Volunteer (for hands-on work).
Financial needs and one-click donations
Financial needs aren't just a numeric field — they carry a donation link that turns a stated funding gap into a one-click contribution path for donors. An organization posts a need such as "Meals for elderly, 100,000 UAH" with a monobank (or other payment provider) link, and any visitor to the deed page can contribute immediately.
This turns the deed page into a fundraising surface — while the platform itself never handles money. Payment integration stays on the organization's own regulated provider, keeping legal and financial responsibility where it belongs.
Application flow with proposed needs
Applying is the moment where matching happens. A volunteer opens the application dialog, provides a phone number, selects any of the existing needs they can cover (multi-select), and — critically — can propose their own need if none of the listed ones fit their skills. The organizer sees applicant context, contact details, and selected needs in one review view; a proposed need can be adopted into the deed as a real need, where it becomes visible and joinable for everyone else.
The application form doubles as a discovery channel for supply the organizer didn't know existed.
Discovery feed with calendar and map
A card-based catalogue of deeds with mobile-adapted filters — city, proximity radius, category (Humanitarian, Logistics, Medical, Education, Evacuation, Fundraising, Community, Other), status (Planned, Ongoing, Completed), organizer, own participation. A calendar view carries the same filter set for period-based discovery, and a map view shows deed locations geographically.
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 and announced automatically by email to the organizer and every approved participant.
Trust and moderation
Verification-gated publishing, four-role separation, revocable server-side sessions, a complaint pipeline, account suspension, and content takedown that removes an item from every public surface — not just from a list view. Personal data flows only where earned: a volunteer's phone number reaches the organizer of the deed they applied to and nobody else. Safety properties are enforced by structure — through explicit response serialization, ownership-scoped queries, and audit-ready logs — rather than by discipline.
Business outcomes
-
The deadline was met, at full scope. A full domain — backend, frontend, migrations, tests, CI and error monitoring — went from empty repository to deployed product in 12 calendar days. 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 tells an organizer exactly which of their asks is still uncovered, and lets a volunteer commit to precisely what they can deliver.
-
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 sessions, and a takedown pipeline that clears every public surface mean the platform's safety properties are enforced by structure rather than by discipline.
-
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.
The Engain way
-
AI-native delivery model — 40–60% lower cost through senior engineers plus orchestrated AI agents. The saving passes to the client, not to overhead.
-
Speed without debt — Full-domain MVPs in weeks, not quarters. Migrations, automated tests, and a CI gate ship from week one — never deferred as debt.
-
Full-stack accountability — One team owns backend, frontend, design and DevOps. No coordination overhead across three vendors, no interface politics between contractors.
-
80% automated maintenance — Post-launch, AI agents absorb routine triage, dependency updates and bug fixes. Ongoing operational cost stays flat as the product grows.
-
Security & compliance by structure — Data perimeter, revocable sessions, ownership-scoped queries and audit-ready trails built into the architecture from day one, not bolted on afterwards.
-
Direct engineering communication — No account-manager layer. Your CTO talks to senior engineers on our side directly. Feedback loops stay short and decisions traceable.
Interested in a similar delivery for your project?
Book a 30-minute call — we'll walk through your scope and show how AI-native orchestration could compress your timeline the same way.
Book a call → engain.co/book
Case Study | Dobrion | Confidential