Building JoBoEco, Part 1: the problem that justified everything

The beginning — and the chaos

Before writing a single line of JoBoEco code, I participated in organizing a few academic events. The experience was eye-opening — but in the hard way.

The process went roughly like this: a Google Sheets spreadsheet to track registrations, a Google Form to capture the data, manual emails to confirm payments (via Pix with a random key, no automation whatsoever), another form for reviewers to register their decision on submitted abstracts, and finally a Canva-based process to generate certificates one by one, sent out in batches by email at 2am the night before the event.

If you think I’m exaggerating, I’m not. This is exactly how the vast majority of small and medium-sized academic events in Brazil still work today.

The problem isn’t disorganization. It’s the absence of a purpose-built tool. Sympla and Eventbrite are excellent for concerts and corporate conferences, but they have no support for the workflow of a real academic event:

• Paper submissions with multiple modalities (short abstract, extended abstract)
• Peer review with different blinding modes (open, single-blind, double-blind)
• Quotas per participant category — undergraduate students get 2 free submissions, professionals pay per submission, graduate students follow another rule
• Enrollment proof as a requirement for certain categories, with manual admin review
• Mini-courses with limited spots and separate registration from the main event
• Certificates with authenticity verification without depending on an online server
• Proceedings publication in academic format, with BibTeX export for reference managers

Each of these was solved with a different patch. And when you pile patches on top of patches, at some point the whole system collapses — usually on the Friday before the event.

”But why not use X?”

This question comes up the moment you mention you’re building something from scratch. It’s a legitimate question. Let me answer it directly.

EasyChair, ScienceOpen, Open Conference Systems: aimed at large-scale conferences, with interfaces that look like they’re from the 2000s (because many of them are), limited customization, zero integration with Brazilian payment methods, and pricing completely out of reach for small Brazilian university events. EasyChair’s pricing starts at hundreds of euros per event. Unfeasible.

Sympla / Eventbrite: great for ticketing. Terrible for the submission + review workflow. There’s no concept of “knowledge area” with “assigned reviewer” and “submission conditional on enrollment proof”. You could try to build that flow with external integrations — but then you’re building the system anyway, just fragmented and without real control.

Event3: this is the most interesting one to analyze. The platform is Brazilian, focused specifically on academic events, and can cover a good chunk of the registration and submission flow. It’s the closest option to what JoBoEco aims to be. But the business model charges a percentage per paid registration — which in practice penalizes exactly the events that most need an accessible solution. For a university conference with 300 registrations at R$40 each, the platform fee ends up costing more than JoBoEco’s infrastructure for the whole year. On top of that, layout and eligibility rule customization is limited, and there’s no control over the payment confirmation flow — a critical point I’ll detail below.

WordPress + plugins: I tried this once in another context. I won’t get into the details. I’ll just say: 12 plugins fighting each other, a check-in process that depended on an $80/year plugin that stopped working the weekend of the event, and three hours debugging a jQuery conflict in production.

The conclusion was inevitable: the problem is specific enough to justify a specific solution. And recurring enough — events happen every semester at hundreds of Brazilian universities — that the cost of building is worth the return.

The problem of Pix without automation

This deserves its own paragraph because it’s a very concrete pain point. The organizers of UEAP — the State University of Amapá, where JoBoEco was born — had exactly this problem before the platform existed.

The payment flow was: the participant made a Pix transfer to the organizing committee’s key, took a screenshot of the receipt, and sent it by email. A committee member manually checked the screenshot, verified in the bank statement that the amount matched, and then — if everything was right — sent a confirmation email.

This process has several obvious problems: it consumes human time linearly (the more registrations, the more manual work), it’s error-prone, it depends on a specific person having access to the bank statement, and it creates a bottleneck that delayed confirmations by hours or days. In the final stretch of registrations, when dozens of people were making simultaneous Pix transfers, the committee simply couldn’t confirm everything in time.

Some platforms that accept Pix solve part of this, but charge percentage fees per transaction. For non-profit events with low registration fees, that fee eats into a significant portion of the revenue. It’s the kind of cost that doesn’t show up in the initial budget planning and creates friction with the university administration at the end.

In JoBoEco, Pix is processed via MercadoPago’s API with automatic confirmation via webhook — no percentage fee on academic registration payments. Confirmation arrives in seconds, not hours. The admin sees the updated status in real time. This was one of the highest-impact improvements the platform delivered.

Features scattered across N platforms

Another pattern I saw repeated across multiple events: each step in the conference lifecycle lived in a different platform, with no integration between them.

Nine steps, nine systems that don’t talk to each other. Registration data manually copied from Forms to the control spreadsheet. Payment status written by hand in the spreadsheet. Attendee list exported from Sheets for check-in. Approved abstracts copied from the reviewer’s email to the results form.

Every manual data transfer between systems is an opportunity for error. And more: when something goes wrong (the participant says they sent the receipt and aren’t on the list, or the reviewer says they submitted the review and it never arrived), you have to hunt down the data across separate files, with no log, no traceability.

JoBoEco didn’t solve the lives of all Brazilian academics. But for UEAP, it centralized into a single system what was previously at least six separate tools — and eliminated the bulk of the manual reconciliation work between them.

What JoBoEco actually is

The name comes from “Jornada de Botânica e Ecologia” (Botany and Ecology Conference) — the event for which the platform was originally conceived. But the system was designed from the start to be multi-event: each edition is an independent entity in the database, with its own schedule, categories, and settings.

What the platform covers today:

1. Registrations with payment via dynamic Pix (MercadoPago)
2. Mini-course registration with per-activity capacity control
3. Paper submissions with configurable eligibility engine per participant category
4. Peer review with support for open, single-blind, and double-blind
5. In-person check-in via QR Code scanning
6. Certificate generation with offline authenticity verification via HMAC-SHA256
7. Proceedings publication with full-text search, area filtering, and BibTeX export
8. Full admin panel with feature flags configurable at runtime

Each of these has a story behind it. A technical decision, a tradeoff, an attempt that failed before reaching the solution that’s in production. This series is about those stories.

The scale question

A detail that significantly affects the design: academic university events have very concentrated usage spikes. Registrations open, everyone tries to register on the first day. Submission deadline closes, everyone submits at the last minute. On the day of the event, check-in happens in 30 minutes with hundreds of people.

Outside those spikes, traffic is essentially zero.

This created an interesting cost constraint: I didn’t want to pay for idle infrastructure 90% of the time to handle occasional spikes. This directly influenced the stack choice — but that’s a topic for the next post.

Why write this

Part of the motivation is documentation. When you build something with 24 database migrations, 3 review modes, an eligibility engine with 6 verification dimensions, and a certificate system that works offline — you want that knowledge to survive beyond your working memory.

But the other part is more direct: I wish I had found posts like this when I was making those decisions. Posts that explained not just the how, but the why. Why this stack? Why this design? What did you try before? What went wrong? What would you do differently?

That’s what I’ll try to write in this series. Without glamorizing, without hiding the parts that didn’t turn out pretty.

What comes next

In the next part, I talk about the stack decision — specifically why I chose to run everything on Cloudflare (Workers, D1, R2) instead of the more obvious Vercel + PostgreSQL path. It’s a bet I stand behind, but with real tradeoffs worth understanding before going down the same road.