Conference hosting, done right: what we build for academic events
Every academic conference runs on a stack of digital duct tape. A submission portal that nobody on the program committee fully understands. A schedule maintained in a shared spreadsheet that breaks every time someone opens it in the wrong version of Excel. A program site assembled the week before the event by a graduate student who is also presenting. A post-event archive that 404s by the following spring.
We have watched this pattern repeat across more than a decade of academic events — as authors, as session chairs, as program committee members, and as the people who ended up rebuilding the platforms when the previous solution collapsed. Conference hosting is one of the service lines we offer because it is one of the things we have actually had to do, year after year, to keep our own work and our colleagues’ work moving.
This post walks through what that service looks like in practice, with snapshots from a division site we have built and maintained for years: aseecoed.com, the web presence for the ASEE Computers in Education Division.
What we mean by “conference hosting”
The phrase covers a wider range of work than most clients expect when they first reach out. A “conference website” is rarely just a website. It is some combination of:
- A public-facing program site — landing page, calls for papers, schedule at a glance, session detail pages, speaker pages, venue and travel information, sponsor recognition.
- A submission and review system — author portals, reviewer assignments, blind or open review workflows, decision notifications, camera-ready upload.
- A scheduling tool — track and room assignment, time-slot management, conflict detection, exportable program PDFs.
- An archive — durable, citable URLs for past programs, abstracts, and proceedings so the work outlasts the event week.
- The operational glue — domain configuration, TLS, CDN, monitoring, analytics, accessibility audits, and the unglamorous patching that keeps the site working between cycles.
Different events need different combinations of these. A one-off symposium with 60 invited attendees needs a clean landing page and a one-page program — not a peer-review portal. A division of a national society running an annual programming track needs a durable home for several years of accumulated content. A multi-day conference with 300 submissions needs the full pipeline.
The current cycle’s home page on aseecoed.com — countdown, conference summary, and a persistent volunteer-recruitment strip across the top.
Snapshot: aseecoed.com
The ASEE Computers in Education Division (CoED) site is a useful exemplar because it sits in the middle of that range. It is not a one-off event site — it is a multi-year division presence that publishes new programming every conference cycle, archives the previous years, and serves as a stable reference for the division’s members between events. We have built and maintained it through several cycles of programming.
A few things to notice in the snapshots:
The home page is content, not chrome. No carousel. No autoplay video. A short description of the division, a clear pointer to the current cycle’s programming, and visible navigation to the archive. The page is fast because it is mostly text, statically rendered, and served from a CDN. Lighthouse scores stay above 95 across categories because we did not negotiate them away in exchange for a design system that nobody asked for.
The full program rendered as a structured grid: four tracks side by side, day filters at the top, every session a clickable card linking to its abstract and presenter detail.
The program is structured data, not a PDF. Each session has its own URL. Each session links to its abstract, its presenters, and its time-and-room assignment. Authors can link to their session from a CV. Search engines can index it. Attendees can bookmark a session on their phone the morning of the event without downloading a 40-page program book. When the schedule shifts — as it always does — we update the source data once and the entire site reflects the change.
The archive is real. Past-cycle programs are not deleted at the end of the event. They are preserved at stable URLs, with the abstracts and speaker information intact, so a graduate student writing a literature review next year can cite the session and link to a page that will still resolve. This is the part that most off-the-shelf conference platforms do badly. They are optimized for the event week. They are not optimized for the decade after.
Attendees build a personal schedule on-device — no account required — then export to their calendar of choice or print a one-page PDF. The same data drives reminders 15 minutes before each saved session.
The stack is boring on purpose. Static-first rendering. Content stored as markdown in a Git repository the client owns. Deployed through a continuous-integration pipeline so a content edit pushes to production in under two minutes. No proprietary CMS. No vendor lock-in. The division could hand the entire repository to a new technical lead tomorrow and have them productive by the end of the week.
The volunteer signup the program chair sends out two weeks before the event. The session grid is generated from the same source-of-truth program data — moderators see exactly the time slots, tracks, and session titles that appear on the public program. No spreadsheet round-trips, no name collisions, no last-minute “wait, who is chairing T308C?” emails.
Volunteer coordination is part of the platform. Moderators, poster judges, session chairs — every academic conference depends on volunteer labor that has to be recruited, scheduled, and confirmed in the weeks before the event. Most platforms ignore this. We treat it as a first-class workflow: a public signup that reads from the same program data that drives the public site, role-aware routing of confirmations, and a chair-facing view that flags sessions still missing a moderator. The recruitment strip on the home page links straight to it.
What we deliver, by tier
The Conferences & Digital Platforms service page lays out three tiers. Here is how they map to the work above.
Tier 1 — Project or workshop site (~$2K–$6K)
A focused, single-purpose site. Conference landing page with calls-for-papers, a one-page program, registration links pointing to whatever ticketing platform the host already uses, and a contact form. Five to twenty pages. Three to five weeks from kickoff to launch.
This is the right starting point for a one-off symposium, a workshop series, a small invited convening, or a project’s outward-facing presence during the announcement and registration window. It is not a peer-review platform — it is a clean, fast, accessible site that makes the event look as serious as it is.
Tier 2 — Conference platform with session scheduling (~$10K–$20K per cycle)
The full pipeline. Submission portal, peer-review workflow, scheduling tool with track and room management, public program site, and a post-event archive. Built for events in the 50–500 attendee range with 30–200 sessions. Eight to fourteen weeks of pre-event work, plus event-week support and an archived snapshot afterward.
Repeat cycles run 30–40% cheaper because the system already exists; we are tuning the workflow, refreshing the design, and shipping the next year’s content. This is where most academic conferences end up landing.
Tier 3 — Multi-year project infrastructure (~$25K–$60K+ over the lifecycle)
The long-horizon engagement. A division site, a research program’s outward-facing presence, or a multi-year funded project that needs not just a website but also one to four deployed web apps — dashboards, classroom-facing tools, data-collection instruments, lesson libraries — running on infrastructure we manage or hand off to internal IT at the end. Three to five years, scoped against the funded period.
aseecoed.com sits in this tier. So do several of the lab and project sites we maintain.
Why this is a Freyja Labs service
Two reasons.
The first is practical. The founders have shipped and maintained academic conference platforms, lab websites, grant-deliverable applications, and classroom-facing tools across more than a decade of funded work. We know what breaks. We know which corners are safe to cut and which corners cost you the next funding cycle. The service line packages that experience for clients who need it without staffing it internally.
The second is philosophical. The same principle that drives our PD work — small tell, lots of do — drives our infrastructure work. We do not want to be the team that disappears after launch and leaves you with a binary you cannot edit. Every site and app we build ships from a Git repository the client owns. Every editable surface is plain markdown. Every architectural decision is documented in a written technical plan you see before any code is written. The deliverables outlast the engagement on purpose.
How to start
If you have an event coming up — a symposium next semester, a conference cycle next year, or a multi-year project that needs durable infrastructure — the first step is a scoping conversation. Forty-five minutes, no charge. We learn the audience, the timeline, and the integration points. You leave with a written sketch of the right tier and a realistic cost range.
Or browse the full service description: Conferences & Digital Platforms.