Rodney Dela Cruz

eSerbisyo

Document services platform for Philippine barangays: visual DOCX templates, approval workflows, and QR-verifiable documents issued in minutes instead of days.

Rodney Dela Cruz

Technical Co-founder, eSerbisyo

  • React
  • Appwrite
  • Cloudflare Turnstile
  • Brevo
eSerbisyo.com Landing page

I co-founded eSerbisyo as technical co-founder. It is a document services platform for Philippine barangays, and it exists because of a measurement the company publishes about itself: a barangay clearance that takes two to five business days and fifteen to thirty minutes of staff time becomes one that takes minutes and under two minutes.

That ratio is the product. Everything below is the machinery for it.

The document is the hard part

The instinct is to treat this as a records system: store the request, track the status, print a certificate. The record is the easy half.

The difficult half is that a barangay certificate is not a row. It is a formatted government document with a specific layout, and the layout changes when a council resolution changes it. So eSerbisyo makes the document itself configurable. A barangay uploads a real .docx template, maps fields to placeholders through a visual builder, and from then on the platform renders the document rather than approximating it in HTML.

eSerbisyo form builder mapping custom fields onto DOCX document templates.

The template is versioned, with history and rollback, because a bad edit to a live template affects every document issued after it. Fields carry validation rules and conditional logic, so a request that should have required a field cannot be submitted without it.

Verification that a paper stamp cannot do

eSerbisyo document request queue for reviewing, approving, and generating barangay documents.

An issued document carries a QR code, and the QR is not decoration. It resolves to a verification endpoint that reports whether the document is genuine, without requiring the person checking it to have an account.

The download itself is constrained: the resident sets a password on the PDF, the link expires after seventy-two hours, it is single-use, and the file is deleted once downloaded. Someone who receives a copy of the PDF cannot forward it onward as a reusable document.

This is the distinction I care most about, because a QR code on a document proves much less than people assume. What makes it meaningful is the server-side record behind it, and the expiry that makes a leaked link useless. The code alone is a convenience.

Two tracks, one backend

eSerbisyo runs a walk-in mode and an online track, and the reason it can afford to is that both go through the same engine. A resident standing at the counter with a document request and a resident at home with a phone are the same request with a different origin.

eSerbisyo admin dashboard showing document requests, analytics, and document management.

The online track does not require an account. A resident gives an email address and their barangay, receives a tracking number, and can check status. That is a deliberate constraint: asking someone to register before they can ask a question is the point at which most of them give up.

eSerbisyo public portal where residents request and track documents without an account.

The parts that are not product

Approval runs one or two levels depending on the document, and when it runs two, the same user cannot sign off both. That is separation of duties enforced in code, not in a policy document nobody reads.

Multi-tenancy is enforced at the data layer. Every record carries a barangay identifier and isolation happens in the query, not in a filter applied afterward where a forgotten clause leaks one tenant’s documents into another’s.

Verification of anonymous submissions runs through Cloudflare Turnstile rather than a CAPTCHA, and transactional email through Brevo. Both are unremarkable choices, which is the point — the interesting problems here are document fidelity and tenant isolation, and time spent elsewhere is time not spent there.

What is still rough

The reconciliation between walk-in and online requests is the weak point. The same resident can open a request at the counter and again from home, and the platform flags the duplicate rather than merging it. A human resolves it. That is defensible, but it is a workflow, and it deserves better tooling than a flagged row.

Onboarding is also less than half a day for the entry tier, which means less than half a day to build templates, import the resident directory, and train staff. The larger tiers add one to two days and a more complex approval configuration. The number is real and it is also the ceiling of how much a barangay can absorb before the system is a burden.