Open Call Manager

Organizations such as galleries, festivals and grant programs run open calls: time-boxed public submission campaigns. Technically, Open Call Manager is a vertical SaaS that combines:

Configurable intake

Per-campaign forms, eligibility rules, file requirements and deadlines.

Applicant tracking

A CRM-style pipeline (draft → submitted → vetted → judged → awarded) with bulk triage.

User management and RBAC

Four roles (owner, admin, judge, applicant), scoped per organization and per campaign, not global.

Review workflow

Judge assignment, configurable scoring schemes, and blind review enforced at the data layer.

Payment gateway and payouts

Entry-fee checkout, marketplace-style settlement to each organization, platform commission.

Async media processing

Upload normalization and derivatives for images, PDFs, audio and video.

Transactional email

Invites, receipts and results.

Revenue model: a commission on collected entry fees, with a free tier for no-fee campaigns. I chose it over a subscription so there's no cost to adopt and revenue tracks usage. It drove the payments architecture: Stripe Connect and a per-tenant fee rate.

In the product

Screens from the running app with seed data: an organizer creating a call, a judge scoring an entry, and an artist building an entry on a phone.

Data collection

Seven scrapers, one per source, because each source needed a different technique.

Every scraper paces its requests with randomized delays, backs off on 429s and Retry-After, resumes after interruption, caches paid API queries, and can run behind a rotating VPN. Output goes to SQLite, with aggregate reports on top.

Findings that shaped the product

• Most campaigns charge an entry fee, so payments are core to the product, not an add-on.
• More than half of apply links go to bespoke sites or generic form tools, not to any submission platform. That's the addressable gap.
• Requirements are inconsistent (for example "300 dpi" for images viewed on screen), so the platform normalizes media server-side instead of pushing that work onto applicants.

Competitive analysis

I profiled 41 platforms from a written research plan and stored the results as structured data: profiles, pricing tiers, features, constraints and language support. 31 were fully profiled, and 10 were flagged for manual review rather than guessed at.

The gap: every form builder handles intake. None has a review workflow, an applicant status portal or award tooling. The form is a commodity; the review pipeline is the product.

Only one competitor confirmed blind review, and none confirmed per-field blind review.

Compartmentalized specs

Before writing code, I split the system into specifications with one concern each and a clear owner for every decision. Each one is a document of record that other specs reference rather than repeat.

All of them were generated in Claude Code plan mode (a practice I adopted while building Sprogeny), challenged by Google Gemini as a second opinion, and changed only through dated amendments, so the history of each decision stays visible.

Domain decisions, made deliberately

A pre-build decision session went through every open question across the specs. The AI restated each one and laid out options with a recommendation; I decided each one, or deferred it with a trigger for revisiting it.

1. 1 Two domains opencallmanager.com (organizations, judges) and shareyour.art (applicants)
2. 2 nginx TLS, forwarded headers, routing to the app
3. 3 SvelteKit on Node One deploy, hostname-routed into two route trees
4. 4 Supabase Postgres, Auth, row-level security
5. 5 Stripe Checkout per entry, Connect settlement to each organization
6. 6 RabbitMQ Job queue between the web and media tiers
7. 7 Python/Celery worker ffmpeg and ImageMagick, dead-letter queue
8. 8 DigitalOcean Spaces S3-compatible object storage; SendPulse for email

export const reroute: Reroute = ({ url }) => {
  if (url.pathname.startsWith('/api')) return;
  const area = resolveHostArea(url.hostname);
  if (area) return `/${area}${url.pathname}`;
};

case when oc.blind_judging ? 'artist_id'
  then null else e.artist_id end as artist_id,
case when oc.blind_judging ? 'full_name'
  then null else p.full_name end as full_name,

Next: AI content moderation. TypeSafe Jev will classify campaign and submission text for spam and policy violations, such as requests for off-platform payment, ahead of human vetting.

Systems design

Service boundaries

The web tier (SvelteKit) and media tier (Python worker) talk only through a queue and object storage, so they deploy, scale and fail independently.

Consistency

Payment state changes only on verified webhooks; webhook event IDs are recorded so a redelivered event isn't applied twice.

Idempotency

Refunds use one idempotency key per entry, so a withdrawal racing a campaign cancellation can't refund twice; cancellation itself is safe to re-run.

Failure handling

Failed media jobs go to a dead-letter queue rather than being dropped, so they survive an outage and can be replayed.

Security boundaries

Authorization lives in Postgres (RLS, column grants, masking views); uploads are untrusted and processed under a restricted ImageMagick policy.

Data lifecycle

Account deletion is a queued, re-runnable process that is re-applied after a backup restore; payment records are kept per retention policy.

Scaling path

Shared VPS → dedicated droplets per service → replicated droplets for horizontal scale. The queue boundary is what makes the split cheap.

Stack decisions, from experience

Where the experience came from

• Art Review Generator

  RabbitMQ worker pattern, polite scraping, SendPulse, DigitalOcean + NGINX

  Source on GitHub
• Sprogeny

  Flask → SvelteKit/TypeScript, PM2 deploys, plan-driven builds

  Source on GitHub
• lucidbeaming.com

  Long-running site refactored to SvelteKit

  Source on GitHub

Repo structure for a team

A parent repo with five submodules (app, media worker, message queue, docs and brand), each versioned and deployed independently. Work reaches main from dev only through reviewed pull requests. A CLAUDE.md in every repo encodes the conventions for humans and agents alike, and a Backlog.md board holds 214 tasks across 19 milestones, each task becoming a branch and a PR.

Delivery: four months, steered by hand

I ran the project myself for four months, monitoring every task and adjusting the plan as I learned. The initial plan was a deliberately aggressive 14-day sprint of about 45 tasks; its real value was forcing priorities to be decided early. When the target shifted for business reasons, I immediately raised the bar on security and accessibility instead of just extending the dates. About 170 more tasks were added as audits, testing and launch preparation exposed new work. The MVP shipped on 5 October 2026.

See the month-by-month timeline ↑

Infrastructure evolution on DigitalOcean

1. 1 · Done Local development in Docker
2. 2 · Done Staging droplet running Docker images
3. 3 · Done Shared VPS with PM2-managed processes
4. 4 · Done Dedicated droplets per service
5. 5 · Planned Replicated droplets for horizontal scaling

Quality

Tests

80 unit (Vitest) · 26 database (pgTAP: RLS and roles) · 21 e2e (Playwright, both domains)

Migrations

68, each reviewed like code

Accessibility

WCAG 2.2 AA audit. Page loads with serious or critical axe violations went from 37 of 48 to 0 of 27, and axe now gates the e2e suite.

Security

Database and API attack-model audit; every high finding fixed, mediums tracked.

Design: user-centric, not decorative

I designed the logo and set the colors and typography. One token-based design system runs at two densities: compact for organizers, relaxed for applicants. The admin side deliberately matches the tools organizers already know, so there's nothing new to learn. The visual design is kept basic for legibility, including for people with low vision, and the artist entry flow is mobile-first, with good layouts for larger screens.

One example: the brand amber was only 2.2:1 against white, so the focus ring uses a darker amber at 5.05:1 that keeps the brand feel and meets WCAG.

Each model has one job, and work written by one model is reviewed by another, and by me. Different models have different blind spots.

Claude Code

Builder: plan-mode specs, implementation, tests, research runs, audits; Playwright MCP for browser checks

Google Gemini

Second opinion on plans and docs

OpenAI Codex

Reviews every PR with prioritized findings (P1/P2), alongside my own review

Mistral Vibe

Independent code review passes

Superdesign

Design exploration for complex admin screens, to my direction

TypeSafe Jev

Next: in-product moderation of campaign and submission text

The review loop, with me in the middle

1. 1 Claude Code implements a backlog task and opens the PR.
2. 2 Codex reviews the diff and reports findings ranked by priority (P1/P2).
3. 3 I read every Codex finding and decide which ones are real, relevant and worth acting on. Only those get posted to the PR, under my name.
4. 4 Claude fixes each posted finding in a follow-up commit and replies with the commit, what changed and how it was verified.
5. 5 I review the fixes and the evidence, and merge.

Neither model talks to the other directly. I'm the filter between reviewer and builder, so every finding on a PR is one I chose to act on, and none of the models' judgments go unchecked.

PRs in the app repo

107

Codex findings I chose to post

30

threads answered with a verified fix

23

What the findings caught

Concurrency and races

Duplicate piece positions from parallel uploads; a checkout racing a cap change; check-then-update on campaign status

Authorization and data integrity

Media still editable after submission; blind review with no write path; stale agreement wording accepted

Fail-closed behavior

A fee setting resolving to NaN; rule checks passing when a read failed; a seed guard that was optional

Test quality

A tautological money assertion; RLS tests with no denial case; Playwright specs registered twice

Operational safety

A migration that would abort on historical rows; unbounded memory reading a remote image

From the review threads

Why this works: the reviewing model has no stake in the code it reviews, I filter its findings so the builder only acts on ones that matter, the fixing model has to show evidence rather than just agree, and every finding stays on the PR as a record. Mistral Vibe ran independent passes at milestones; its review of the checkout and judge-invite work flagged a non-transactional invite flow, where an email could be sent before the insert failed.

Next: production release · TypeSafe Jev moderation · replicated droplets for horizontal scaling.

• An aggressive plan is still worth writing.

  The 14-day sprint didn't hold, but it forced every priority to be decided up front, and that ordering survived the change of schedule.

• Use slack to raise quality, not just extend scope.

  When the timeline moved, security and accessibility were the first goals I expanded.

• Small side quests compound.

  Design exploration, deployment tiers and code audits, done alongside the main tasks, kept the codebase lean and ready to scale.