The client was tracking members in WhatsApp groups and a paper notebook. Entry/exit had to work reliably on cheap Android tablets at the door — 24/7, no tolerance for downtime. The critical constraint wasn't the CRUD; it was designing the access flow to work on unreliable hardware and survive poor network conditions without losing state.

MongoDB over PostgreSQL — the membership schema changed constantly during development (kitchens, PT sessions, and class scheduling were added mid-build). A flexible document model saved weeks of migrations.

Deno over Node.js — I'd been building Yelix on Deno and knew the runtime well. The built-in security model and native TypeScript support meant less boilerplate in the API layer.

Self-hosted on a VPS — the client couldn't justify cloud pricing for a regional gym. Self-hosting with proper monitoring (Sentry) kept costs under control while maintaining reliability.

Universities ran internship approvals entirely on paper, routed physically between 4 different roles (student, advisor, workplace, internship office) — each with different authority levels. The state machine had 12+ distinct states and rejections at any step had to route back to the correct party with the original context intact, not just "rejected."

Next.js with React Server Components — the document-heavy views (PDF previews, form history) rendered far better server-side. Reduced client bundle size significantly.

DrizzleORM over Prisma — requirements changed frequently. Drizzle's migration model gave more control over schema changes without the abstraction overhead.

MinIO for document storage — PDFs and attachments couldn't live in the database, and MinIO gave an S3-compatible self-hosted option the university could control. Auto-PDF generation via pdf-lib for official forms.

The client needed bilingual (TR/EN) content that their non-technical team could update without breaking layouts or losing translations. The previous site was static HTML nobody dared to edit. The goal was a system where the team owns the content — not the agency.

Astro for the build — zero client-side JS by default, fast to load, and the static output is straightforward to deploy and maintain. No runtime to babysit.

Contentful for the CMS — its i18n handling is genuinely good, and the editor experience is approachable for non-developers. The client's team was editing content independently within a week of handoff.

Every Deno web framework I found was a Node.js port — they worked against the runtime instead of with it. Deno has native TypeScript, Web platform APIs, and a granular permission system. None of the existing frameworks actually used these. I wanted a framework where Deno's design decisions were features, not obstacles.

Built on Deno's native HTTP server — not a compatibility layer. Uses standard Web API Request and Response objects throughout, which means any knowledge of Fetch API transfers directly.

TypeScript inference over decorators — kept the API surface small and avoided the magic that makes debugging painful. Route types are inferred, not declared separately.

Building a platform a volunteer-run developer community could actually sustain — events, blog, documentation, daily university cafeteria menu — without depending on cloud services or recurring costs that might disappear. It also needed an ad management panel, web push notifications, and scheduled campaigns, none of which exist as off-the-shelf solutions for a budget of zero.

Custom background job runner — Deno.cron wasn't available. I built a campaign-based scheduler with retries, concurrency control, and status tracking from scratch, tuned to the community's actual publishing patterns.

Web push over SMTP — email deliverability for a small org is a maintenance headache. Web push is free, instant, and doesn't require managing a sending domain.

Government use means zero tolerance for data loss and clear audit trails — but the team had student-project resources. The platform had to handle hundreds of simultaneous form submissions during registration windows, maintain a full submission history, and be recoverable if anything went wrong.

Astro for reliability — static output means no runtime failures for the public-facing parts. Server-side routes only for registration and submission handling, where state actually matters.

Designed for peak load — registration windows are the stress test. The architecture was explicitly designed for the worst-case burst, not the average request rate.