SciRec Psychometric Assessment Platform

Executive Summary

TKX Media will design, build, test, and launch a production-ready replacement for SciRec's Bubble-based psychometric assessment platform. We will preserve the workflows and business logic that already work in your prototype, and deliver a faster, more secure, and more scalable system on a modern code stack.

This proposal covers every item in Section 8 of the RFP and addresses all MVP scope in Section 3 of the SRS — the three portals, eight question types, role-based access, Stripe credit ledger, weighted composite scoring, candidate-safe deployments, PDF reporting, proctoring, GDPR compliance, and the MVP foundations that put WCAG 2.2 AA and SOC 2 Type II within reach in Phase 2.

Recommended stack

• FrontendNext.js 15 (TypeScript)
• UITailwind + shadcn/ui (Radix)
• DatabasePostgres via Supabase (RLS)
• AuthSupabase Auth
• PaymentsStripe (Checkout + Webhooks)
• EmailResend + React Email
• HostingVercel + Supabase
• ObservabilitySentry · PostHog · Better Stack

About TKX Media

TKX Media is a full-service digital agency based in South Jordan, Utah. We build and operate production web applications for clients across legal, healthcare, ecommerce, B2B services, and multi-location franchise operators. We hold Clutch-recognized standing, maintain a 95% client satisfaction rate, and ship work 1.8x faster than the industry average.

We work as an extension of our clients' teams rather than as an outside vendor. SciRec will work with the same people week to week — including the partner who signs this proposal.

Why we are a strong fit for this build

Technical Approach

3.1 Recommended stack

3.2 Database selection rationale

The SRS asks for written justification of the database choice. We recommend PostgreSQL via Supabase over document or key-value alternatives for three concrete reasons:

1. The data model is relational. Companies own jobs; jobs reference assessments and batteries with per-assessment weights; assessments contain ordered questions; candidates produce scored responses joined back to questions. These joins are first-class in Postgres and awkward in document stores.
2. Row Level Security is the cleanest tenant isolation model. Supabase exposes Postgres RLS policies that map directly onto the four client roles (Super-Admin, Admin, Editor, Reviewer), the internal SciRec staff role, and the Phase 2 Organizations sub-unit model. RLS is enforced in the database, not in the application — which materially reduces the risk of access-control bugs.
3. Audit logging is straightforward. Postgres trigger functions write to an append-only audit table on every significant action, serving the SOC 2 readiness requirement in RFP §4.3 directly.

3.3 High-level architecture

The platform is a single Next.js application serving three logical portals (Candidate, Client, Internal), differentiated by authenticated role. Server components fetch data through a thin tRPC layer that calls Supabase via the service role for trusted operations and via the user role (with RLS) for everything else. Stripe webhooks drive the credit ledger. Resend handles transactional email through background functions. PDF generation runs server-side and is stored in Supabase Storage with signed-URL access.

Key architectural choices, mapped to RFP non-negotiables:

• Candidate-safe deployments (RFP §4.1). Vercel's atomic deployments combined with a session-aware "assessment in progress" flag. New deployments do not interrupt active assessment sessions because client-side state and server APIs are versioned for the duration of the session. A feature flag (replacing the Bubble Variables toggles) lets SciRec block new assessment starts during scheduled releases.
• Performance over varied connections (RFP §4.1). Server components reduce JavaScript shipped to the client. Static assets are CDN-delivered. Assessment payloads are paginated by question. The candidate runtime targets sub-100KB of JavaScript on first load.
• High availability (RFP §4.1). Vercel's edge network and Supabase's multi-AZ Postgres provide redundancy. Point-in-time recovery is included. Encrypted nightly snapshots replicate to a separate AWS region.
• Architected for Phase 2 (RFP §4.5). Strings are externalized from day one to support future i18n (including RTL and non-Roman scripts). The scoring engine is implemented as a pure-function library that statistical extensions (tertiles, quartiles, Z-scores) plug into without schema changes. The assessment process model supports multiple stages even though only one stage is exposed in the MVP.

3.4 GDPR compliance

• Data subject access: clients and candidates request and download a machine-readable export of their personal data through a self-service flow.
• Right to erasure: a candidate-initiated deletion flow purges PII while retaining hashed, anonymized response data for psychometric integrity. SciRec staff can also action erasure requests from the internal portal.
• Lawful basis and consent: candidate consent is captured at the start of every assessment with versioned consent records linked to the candidate ID.
• Data residency: primary database hosted in the EU region (Supabase EU-West) by default; jurisdictional preference confirmed in discovery.
• DPA: a Data Processing Agreement is provided and signed before any production data is handled.
• Session replay and analytics tooling run with PII masking on by default (see §3.8).

3.5 Security

• TLS 1.3 in transit (TLS 1.2+ minimum per RFP); AES-256 at rest via Supabase and Vercel.
• Sessions secured with HttpOnly, Secure, SameSite=Lax cookies.
• Password policy: 12-character minimum, breached-password check against HaveIBeenPwned, rate-limited login, lockout on repeated failures.
• OWASP Top 10 protections: parameterized queries, output encoding, CSRF tokens, content security policy, security headers via Vercel edge middleware.
• Dependency scanning via Dependabot and weekly npm audit; secrets in GitHub Actions environments, never in code.
• Third-party penetration test included in the fixed price (see §9.2).

3.6 Accessibility

The MVP foundations in RFP §4.2 and SRS §3.4 are table stakes:

• Component library (shadcn/ui on Radix primitives) ships keyboard nav, focus management, and ARIA semantics by default.
• Heading hierarchy, landmark regions, and form-field labelling enforced through linting (eslint-plugin-jsx-a11y) and code review.
• Color palette selected at design time using a contrast checker; tokens validated in CI.
• Assessment-taking interface tested with NVDA and VoiceOver during QA on every sprint that touches it.

Full WCAG 2.2 AA compliance — including third-party audit and remediation — is quoted separately in §9.3.

3.7 SOC 2 readiness

We will build the MVP so that SOC 2 Type II certification in Phase 2 is a documentation and observation exercise, not a re-architecture:

• Audit logging. An append-only audit_log table records every authentication event, permission change, data export, credit transaction, and significant data modification — with timestamp, actor, and resource.
• Infrastructure as code. All infrastructure (Vercel projects, Supabase configuration, Resend domains, Stripe webhook endpoints) captured in Terraform and version-controlled.
• Separation of duties. Production secrets live only in Vercel's production environment. Developers have no direct production database access. Releases require pull-request approval from a second reviewer.
• Data retention. Configurable per-resource retention policies, scheduled deletion jobs, verification logs.
• Documentation. A security and operations runbook is delivered at handover, formatted to align with the SOC 2 trust services criteria.

When Phase 2 begins, we will recommend an experienced SOC 2 auditor partner. Building to the criteria from day one is the work that matters; the audit itself is structured once the foundation is in place.

3.8 Monitoring, error tracking, and session replay

RFP §8.2 asks specifically about production monitoring, session replay, user-behavior understanding, and GDPR implications. Our recommendation:

• Sentry — error tracking and performance. Source-mapped stack traces, release tagging, performance traces for slow API routes. PII scrubbed via beforeSend hook.
• PostHog — product analytics and session replay. Replay enabled only for client-portal and internal-portal users; disabled on the candidate-facing assessment runtime by default. PII masking on all text inputs; replays purged after 30 days.
• Better Stack — uptime and structured logs. External heartbeat checks against all three portals.

Candidate consent for analytics is captured at session start; the candidate runtime can be configured to disable replay entirely if you prefer a more conservative posture. The final posture is agreed in discovery.

Development Process

4.1 Methodology

Two-week sprints with a fixed cadence: planning Monday, mid-sprint check-in on Wednesday of the following week, demo and retrospective on the closing Friday. Each sprint produces a deployable increment in a staging environment that SciRec can review at any time.

4.2 Requirements breakdown

SRS requirements are translated into epics → user stories → implementation tasks. Each user story carries explicit acceptance criteria written in Given/When/Then form. Stories are not considered done until acceptance criteria pass and code is reviewed by a second engineer.

4.3 Workflow and communication

• Project board: Linear (sprint, backlog, and roadmap views accessible to SciRec).
• Source control: GitHub, with branch protection on main, required reviews, and required passing CI.
• Branching: trunk-based development with short-lived feature branches; deployments go through staging before production.
• Code review: every change reviewed by a second engineer; QA performs exploratory and regression testing on each merged feature.
• Communication: shared Slack channel with SciRec founders for asynchronous questions; weekly 45-minute video call; written sprint review delivered each Friday.
• Scope changes: handled via the change-control process in §9.5.

4.4 Testing

• Unit tests with Vitest for pure scoring logic and utility functions.
• Integration tests with Vitest + Testing Library for components and tRPC procedures.
• End-to-end tests with Playwright for critical paths: candidate completes assessment, client creates and assigns assessment, Stripe purchase consumes credit, internal admin adjusts credits.
• Tests are written alongside code, not after. E2E tests run on every PR and block merges on failure.
• Cross-browser matrix: latest Chrome, Edge, Firefox, Safari on macOS and Windows; tablet sizes tested on iPad Safari and a representative Android tablet.
• UAT: a structured UAT window precedes launch (see §5).

Project Plan

5.1 Phases and milestones

5.2 Effort estimates by area

5.3 Assumptions and dependencies

• SciRec founders available for a weekly 45-minute review call and asynchronous Slack within one business day.
• Access to the existing Bubble application provided within five business days of contract signature.
• Visual design direction (brand, palette, type) decided within the discovery phase.
• Stripe account created and verified by SciRec; we assist with product and price configuration.
• Email-sending domain owned by SciRec; we configure DNS together.
• The penetration test is conducted by a third party that TKX engages on SciRec's behalf within the fixed price.
• Bubble data migration is excluded from the MVP and quoted as a Phase 2 item.

5.4 Risks and items to clarify

• SRS question type gaps. §3.1.4 numbers question types 3.1.4.1 through 3.1.4.4, then skips to 3.1.4.6; "Multiple Ratings" sits inside §3.1.4.2 (Multiple Choice). We have inferred intent and gathered clarifying questions in §11.
• Proctoring scope. MVP relies on browser-level signals (fullscreen, copy/paste, window/tab change). Camera-based identity verification is Phase 2.
• App-update behavior. The SRS describes the Bubble Variables toggles but invites alternatives. Our proposed mechanism is in §3.3.
• Data residency. We assume EU-West for the primary database. A different preference can be set in discovery.

Proposed Team

A four-person delivery team led by a TKX Media partner, supplemented by external specialists for the accessibility audit and penetration test (see §6.2 and §9.2). Named team members are confirmed before contract signature and any time a team member changes.

6.1 Primary point of contact

Stephen Krain, Co-Founder & Partner at TKX Media, is the primary commercial point of contact for this proposal. The day-to-day delivery lead (the Lead Engineer above) is named when the team is confirmed, ahead of contract signature.

6.2 Subcontracting

TKX may engage external specialists for two specific scopes within the fixed price: a third-party penetration test (§9.1) and, in Phase 2, a third-party WCAG 2.2 AA accessibility audit. Any subcontractor we engage will be named and disclosed before that work begins. No other subcontracting is anticipated.

Scope Summary

The MVP fixed price covers the full set of capabilities described in Section 3 of the SRS, with the clarifications below. Items the SRS explicitly descopes (organizations, dimensions, candidate anonymization, tags, multiple stages, and the others listed in SRS §6) are excluded from the MVP fixed price and addressed in §9.3 (Phase 2 pricing).

7.3 Items worth considering for MVP inclusion

Two Phase 2 items are unusually cheap to include now:

These are recommendations, not assumptions. The MVP fixed price in §9 excludes them.

Post-Launch Support

Twelve (12) weeks of post-launch support are included in the fixed price, commencing on the date of production launch. This exceeds the RFP minimum of four weeks because three months is when most genuine production issues surface.

8.1 Covered

• Bug fixes for defects in delivered functionality (any deviation from agreed acceptance criteria).
• Performance issues observed in production that originate in code we shipped.
• Security patches and dependency updates for critical vulnerabilities.
• Configuration adjustments to observability tooling and email templates.
• Up to four hours per week of light advisory time for SciRec founders (training, walkthroughs, Phase 2 planning).

8.2 Not covered

• New features or scope expansions (handled via change control or Phase 2).
• Third-party outages outside our shipped code (we diagnose and advise; resolution is upstream).
• Hosting and infrastructure costs (paid directly by SciRec to Vercel, Supabase, Stripe, Resend, Sentry, PostHog, etc.).

8.3 Response time commitments

8.4 Continued support after twelve weeks

• Hourly: $145/hour, open-ended.
• Retainer: $1,800/month for up to 16 hours.
• Phase 2 sprint engagement: priced per §9.3.

Pricing

9.1 MVP fixed price

9.2 Hosting and infrastructure costs

Estimated ongoing monthly costs for production infrastructure, paid by SciRec directly to providers:

9.3 Phase 2 indicative pricing

Each item is quoted as indicative; final pricing is confirmed at the start of each Phase 2 sprint. Prices assume work undertaken within twelve months of MVP launch.

9.4 Payment schedule

Three milestone payments tied to verifiable completion criteria. TKX does not invoice for work not yet delivered.

Invoices are due net-15 from milestone sign-off.

9.5 Change control

The fixed price assumes the SRS v6 scope as written. Changes are handled as follows:

1. Either party raises a change request in writing (Slack or email) describing the change.
2. TKX produces a written change-impact assessment within three business days, covering scope, effort in hours, price impact, timeline impact, and dependencies.
3. SciRec approves, modifies, declines, or defers. Approvals are logged in the project change log.
4. Changes under $1,500 of impact, not affecting the critical path, are absorbed without modifying the milestone schedule.
5. Changes over $1,500 of impact are added to the contract as a written amendment and invoiced separately on the next applicable milestone.
6. Changes that materially affect timeline trigger a revised milestone schedule, agreed in writing.

9.6 Break points

Either party may pause or terminate at three pre-defined break points without penalty, paying only for work completed to date:

• After discovery (end of week 2). If either party concludes the engagement is not viable, work stops. SciRec pays for time-and-materials work to date against discovery and design hours, capped at the 30% kick-off payment.
• After client-portal sign-off (end of week 10). Either party may pause. SciRec retains all delivered work and source code; outstanding work for completed milestones is invoiced.
• After candidate-runtime sign-off (end of week 12). Same terms as above.

Outside of break points, the engagement may be terminated with 30 days' written notice. SciRec pays for all work delivered to the termination date, plus a 15% wind-down fee against the next unstarted milestone. Source code, designs, and documentation are handed over in their current state.

Intellectual Property

TKX Media accepts SciRec's IP terms in RFP §7 in full. All source code, designs, schemas, documentation, and other deliverables produced under this engagement become the sole property of SciRec on payment of the relevant milestone.

We will reuse only general-purpose open-source libraries and frameworks, all of which are listed in a third-party-license inventory delivered with the source code. We are not reusing any TKX Media proprietary tooling that would create future dependency.

Questions and Clarifications

The following are best discussed during discovery. None are blockers to proposal evaluation.

11.1 SRS clarifications

• §3.1.4 numbers question types 3.1.4.1 through 3.1.4.4, then skips to 3.1.4.6. We assume no missing 3.1.4.5 — please confirm.
• "Multiple Ratings" is described inside §3.1.4.2 (Multiple Choice) but functionally resembles a per-option numerical entry. We will treat it as a sub-type of Multiple Choice unless otherwise advised.
• §2.2 says weights can be zero but not negative. We will enforce ≥ 0 and document zero-weight behavior (assessment retained but excluded from composite).
• §3.1.2 refers to a 60-day validity period as if fixed. Should this be configurable per company or per job, or is 60 days a global constant for the MVP?
• "Manual scoring scale (min 0 or 1; max 1–10)" — we will allow the client to set the lower bound (0 or 1) and the upper bound (any integer 1–10) per question.

11.2 Operational clarifications

• Preferred data residency (we assume Supabase EU-West).
• Existing Bubble user counts and whether data migration will be needed (drives Phase 2 effort estimate).
• Preferred branding direction for the visual refresh (existing logo? new brand work?).
• Preferred ATS to prioritize for the first Phase 2 integration.
• Session-replay posture preference for the candidate runtime (disabled by default in our proposal).

11.3 Items we recommend descoping or adjusting

• Defer Job Groups reinstatement and tags to Phase 2 (the SRS already proposes this; we agree).
• Include Google sign-in in MVP and defer Apple sign-in — the marginal cost of the first is small; the second adds setup overhead with limited additional value.