Case study · Research information system
One platform for university research.
SURI (System for UPM Research Intelligence) is an API-first Laravel and Vue.js platform at the University of the Philippines Manila that unifies research registration, document management, reporting, and approval workflows, serving 50+ users and replacing manual spreadsheet compilation with reporting that runs in seconds.

Research administration at a university generates a constant stream of registrations, documents, approvals, and reports. Before SURI, these workflows at the Research Grants Administration Office (RGAO) ran by hand, compiled manually across spreadsheets and disconnected tools, across multiple offices, each with its own permissions and its own idea of what a "project" means.
Manual compilation doesn't just cost time. It fragments the record of the university's research activity, makes reporting a recurring project instead of a query, and leaves approval workflows without a single system of record.
SURI consolidates the research lifecycle into one platform serving 50+ users across multiple offices.
Research registration
Final registration, management, and funding records for university research.
Document management
Research documents handled inside the platform instead of scattered files.
Approval workflows
Workflows that previously ran by hand, tracked and automated end to end.
Reporting
Reports that once required manual spreadsheet compilation now run in seconds.


SURI is built API-first on Laravel with a Vue.js frontend and a MySQL database. The API-first decision matters because SURI does not live alone: it is designed to join a broader ecosystem of research systems, with authentication and role-based access control treated as architecture, not features.
The next step of that work is TRACE, the research-team workspace in development on the same API and records, and ARIA, the assistant that answers from the office's approved content. Both reuse SURI's authentication, services and audit trail instead of building their own.
I lead SURI's architecture and development and own it through production: deployments, production database architecture, and release management. The platform runs live for the university's research administration. This is operated software, not a prototype.
For engineers and technical recruiters: what SURI is made of, as of 2026.
- Stack. PHP 8.4 and Laravel 12 on MySQL 8, with a Vue 3, Vite and TypeScript single-page app (Pinia, vue-router, Tailwind). Study titles and objectives are encrypted at rest with Laravel's encrypted casts.
- Sign-in. Google OAuth through Socialite, then a Sanctum cookie session for the SPA. University accounts are admitted by domain, outside accounts by approved invitation, and an account with no role or permission is turned away on every request. The mobile flow uses a one-time code with PKCE exchanged for ability-scoped bearer tokens that expire after 24 hours.
- Access control. spatie/laravel-permission with roles for super admin, admin, executive, project handler, encoder, researcher, research assistant and unit viewer, and 38 named permissions enforced as route middleware. Unit viewers see one college or institute only, and the scope fails closed when no unit is set.
- Domain model. About 170 Eloquent models and 250+ migrations. A research registration carries a temporary reference until approval mints the permanent one; status columns cover pending, approved and rejected with reconsideration, and change requests add superseded. Around it: budget versions and fund tranches, purchase requests and orders, document tracking, contract review, help desk, publications and presentations.
- Approval as one transaction. Approving a registration locks the row, mints the reference number, stamps the registration and certificate dates, writes an audit diff, generates the certificate PDF and queues the email only after commit.
- Audit trail. Every write goes through a helper that records actor, action, table, record, a JSON diff, IP, user agent and URL, and never throws. Validation errors, 404s and unhandled exceptions land in an error-log table.
- Reporting. An analytics hub with eight sections cached for five minutes per filter set, seven prebuilt reports, model-written custom reports grounded in a query tool, and exports to XLSX and CSV (OpenSpout), PDF (dompdf) and DOCX (PhpWord). Monthly, quarterly and annual reports run on a schedule and downloads are logged.
- Workflow automations. A staff member describes a rule in plain English; a model compiles it into a rule graph at authoring time; a person reviews and arms it; deterministic PHP runs it from model observers. Automations can never delete, approve or reject.
- API. Versioned routes under api/v1 (32 route files), FormRequest validation, one error envelope, named rate limiters per feature, and shared-secret or HMAC middleware for server-to-server integrations such as the AWTOR sync, Google Apps Script bridges and help-desk intake.
- Quality and delivery. Pest, with 176 test files and about 1,500 test cases. GitHub Actions runs the suite against MySQL 8, then a self-hosted runner deploys: main to production, develop to staging. Scheduled jobs drain the queue, back up the database weekly, run health checks every five minutes and enforce data retention.
One platform now serves 50+ users, unifying registration, document management, reporting, and approval workflows that previously ran by hand.
Written by Ruther Bergonia, Software Systems Architect & Senior Full-Stack Engineer, Metro Manila. I architected and built SURI end to end. More about me.
Related case studies
Start here
Have a system worth building properly?
Tell me what you're building and what's getting in the way. I'll come back with an honest read on whether I'm the right fit, and how I'd approach it. Replies within one business day.