Senior Full-Stack Engineer — Fintech Regulatory Futures Index

Building the public\ infrastructure for open regulatory standards ============================================ The Fintech Regulatory Futures Index is a joint initiative of the Fintech\ Foundation and GFTN: a new international benchmark for evaluating fintech\ regulatory environments. Five thematic dimensions, roughly twenty-nine\ indicators, each with a published four-level scoring rubric authored by working\ groups of regulators, supervisors and academics. What separates it from every comparable benchmark is that the methodology is open to\ challenge. Any visitor can take a single indicator, rewrite its language, sign\ the submission, and have it published alongside the official text. Readers\ endorse individual components. Where a pattern emerges across submissions, the\ working groups revise. The Index debuts at a major industry event October 13, 2026.  **October 7 is a hard deadline.** We are hiring a Senior Full-Stack Engineer to own the build of the public site and\ the participation layer beneath it. This is a hands-on role. You will write\ code daily, design the data model, and ship to a fixed public date. A designer\ is already engaged and will deliver the visual identity, interaction design and\ front-end craft; you own everything a design tool cannot do. Strong written\ English and substantial overlap with US Eastern hours are required. ## The first decision The designer is working in Framer. Either the participation layer lives as a separate service that the Framer site embeds, or the front end is rebuilt in Next.js with her work as the design\ reference. We have not decided, and we want the incoming engineer’s\ recommendation rather than a prescription from us. ## WHAT WE ARE LOOKING FOR ### Must-Have: Technical Foundation **TypeScript and React, with Next.js or equivalent** Server-rendered public pages that\ must be fast, indexable and citable, alongside a genuinely interactive editor. **Node.js backend services and API design** Public write endpoints, private preview\ links, admin routes, and export jobs on a small, comprehensible surface. **PostgreSQL schema design** Relational modeling of a framework that is finite but\ constantly amended: dimensions, indicators, rubric anchors, evidence sources,\ cross-references between dimensions. **Versioned content modeling** The hard modeling problem here. Indicators move from v0.3\ to v0.4; a submission must permanently record which version it forked from and\ which anchor it altered; published pages must state which version they reflect\ and expose a change log. Temporal or append-only modeling experience is\ directly relevant. **Headless CMS integration** Five working groups of non-technical staff will edit the\ canonical text. Editing must not require a developer or a deploy. ### Must-Have: Participation Integrity **Public writes without user accounts** Contribution requires a name, institution and\ contact email, and nothing more. No login, no profiles. Everything downstream\ has to work under that constraint. **Abuse and duplication resistance on anonymous endpoints** Rate limiting, bot\ mitigation, and endorsement de-duplication that holds up without identity,\ degrades honestly rather than silently, and does not punish a legitimate\ contributor on conference wifi. **Moderation as an explicit state machine** Draft, private link, submitted, approved,\ rejected, held, published, adopted. Nothing publishes automatically. Every\ submission is reviewed by the relevant working group before it becomes public. **The public fork library and variant display** Approved submissions publish\ beneath the canonical text of the indicator they fork, signed and attributed,\ so each indicator accumulates a family of alternatives. Plus a browsable\ library filterable by dimension, by indicator and by most-forked. The hierarchy\ problem is load-bearing: canonical text stays unmistakably canonical while\ variants stay readable beside it. **Component-level endorsement** Readers back a specific rubric anchor or a specific evidence\ source rather than an indicator as a whole. One tap, no account, resistant to\ trivial gaming. **Aggregation across submissions** Per indicator: how many forks, which anchor was edited\ most, in which direction the language is being pushed. This is the output the\ working groups actually act on, and it is a first-class feature rather than a\ reporting afterthought. **Provenance and post-publication immutability** A published submission is citable by\ academics. It records what it forked from and cannot be quietly edited\ afterwards. **Separation of official and community content at the infrastructure level** Distinct URL\ patterns, distinct share-card generation, no ambiguity in a preview or a\ screenshot. A community submission mistaken for official methodology is a\ reputational failure, not a cosmetic one. **PII minimalism** Contact emails are collected and never published. Retention,\ deletion and export handled deliberately. ### Must-Have: AI Integration **Constrained LLM rewriting in production** One feature: a contributor writes a\ plain-language objection and a button renders it as rubric language in the\ house register, in the same editable field. Nothing more. **Guardrails and prompt discipline** The model must not invent evidence sources, cite\ authorities, or evaluate the merits of a change. Output is always an editable\ draft, never a submission. You own the failure modes, the cost ceiling, and a\ light evaluation harness that catches meaning drift. ### Must-Have: Front-End Delivery **Implementing another person’s design faithfully** Including motion, and including the\ parts that are harder to build than they look. **Mobile-first contribution flow** The realistic contributor is a central banker on a phone\ during a conference session with about four minutes. The editor is designed for\ that case first. **Accessibility to WCAG 2.1 AA on a dark theme** Contrast fails easily in this palette. Full\ keyboard navigation and reduced-motion support. **Permanent, citable URLs and per-indicator share cards** Academics will cite indicator\ pages. URLs do not change. ### Must-Have: Shipping Behavior **Delivery against an immovable public date** Bias toward a V1 with known limitations\ over a complete system that misses October. **Internal tools for non-technical users** A moderation queue and admin views that five\ working groups can use without training. **Low-operations infrastructure and real handoff** We have no infrastructure team and no\ appetite for anything exotic. Managed services, documented, maintainable by\ whoever comes next. **Scope discipline** A contributor forks one indicator, never the index. No accounts,\ no rival indexes, no reweighting, no comment threads, no forks of forks, no\ public scoring of jurisdictions. We defend this boundary and need someone who\ treats it as a relief. ### Strong-to-Have • Framer or Webflow custom code components and their real limits • Public consultation, civic tech, or government digital service delivery • Editorial or data-storytelling interactives • Diff and version-comparison interfaces • Anti-abuse work on unauthenticated public forms at meaningful volume • Persistent identifiers and citation practice for scholarly content • Policy, academic, standards-body or think-tank clients • CSV and JSON export pipelines for non-technical reviewers ## To apply Send two or three things you have shipped with links, ideally with a real backend rather than a static site; your recommendation on the Framer question above in a paragraph; a note on LLM\ integration you have run in production and how you kept it in bounds; and your availability through early October with your preference for fixed-price or hourly. We are a nonprofit, resourced to pay market rates.