Spairly

Spare AI capacity, paired with work worth doing for educators and underserved communities.

Comment

Inspiration

Powerful AI tools are increasingly available, but useful access is still uneven. An educator, library, nonprofit, or underserved community may have a valuable research, translation, accessibility, or data-analysis need without the budget, compute access, specialist knowledge, or time required to finish it. At the same time, many people and organizations already have AI tools they are authorized to use and capacity that sometimes sits idle.

Spairly comes from combining spare and pair: spare AI capacity, paired with work worth doing. It creates a free place where someone can describe a bounded outcome and a willing contributor can use their own authorized tools to deliver it.

For the demonstration, I use a fictional but realistic request from Kurigram Community Library in Bangladesh. The library wants to prepare a farmer workshop comparing ten years of rainfall patterns with public rice-price data, but it does not have the resources for a substantial AI-assisted data project. The result uses real public NASA POWER and WFP/HDX data and produces documented tables, charts, methodology, limitations, citations, and English and Bangla community summaries. No real beneficiary data or sensitive personal information is used.

What it does

Spairly is a production-deployed, two-sided collaboration workspace.

  1. A requester creates an account and publishes a clearly scoped project, including the desired result, intended audience, permitted public sources, preferred language, and an optional Social Good designation.
  2. Amazon Nova 2 Lite performs three focused, structured analyses through Amazon Bedrock:
    • scope triage identifies whether the request is bounded, what may be missing, and whether service boundaries apply;
    • impact analysis evaluates the stated Social Good rationale without pretending to verify charitable status or real-world impact; and
    • contributor matching ranks fit against pseudonymous contributor profiles, authorized tools, interests, and languages.
  3. Social Good projects receive a visible marker and priority placement when the stated impact is supported by the information provided.
  4. Contributors browse available work, claim a project, complete it using only tools they are authorized to use, and upload a result ZIP.
  5. Result packages stay in private quarantine while Spairly validates the ZIP structure and AWS GuardDuty Malware Protection scans it. Only a package that passes both checks becomes available to the requester.
  6. The requester downloads the checked package, asks for a revision or confirms completion.
  7. Confirmed contributions advance a nineteen-badge recognition system, including milestones for Social Good, education, language access, accessibility, follow-through, and early participation. Contributors can share polished public badge cards, including on LinkedIn.

Spairly's public marketing and policy pages are statically generated in ten languages for search visibility and international accessibility. Authenticated requests can be translated on demand for another participant, with a visible AI-translation disclosure and the original request remaining authoritative.

How I built it

The frontend is built with Next.js 16, React 19, TypeScript, and statically generated public pages. The production website is delivered from a private, versioned Amazon S3 bucket through Amazon CloudFront with Origin Access Control, security headers, Route 53 DNS, and ACM certificates.

Amazon Cognito provides account creation, verification, and OAuth 2.0 authorization-code flow with PKCE. The authenticated workspace calls an Amazon API Gateway HTTP API protected by Cognito JWT authorization and a CloudFront edge secured by AWS WAF and a private origin token.

AWS Lambda and DynamoDB implement request creation, project discovery, contributor profiles, claiming, completion, archiving, translation records, assessment state, and badge progress. Amazon SQS isolates AI assessment work from interactive API requests and provides retry and dead-letter handling. Amazon Bedrock invokes Amazon Nova 2 Lite with constrained prompts and structured response schemas.

The AI path deliberately excludes requester names, email addresses, organizations, Cognito identifiers, and credentials. Model inputs contain only the project and pseudonymous matching fields needed for the specific analysis. Translations are stored separately, labelled as AI-generated, and never replace the original request.

For result delivery, contributors receive a short-lived, size-limited presigned upload into a private S3 quarantine prefix. A Python Lambda validates archive paths, expanded size, file count, compression ratio, encryption, nested archives, symbolic links, executable content, and allowed formats. EventBridge and AWS GuardDuty Malware Protection provide the malware result. An idempotent security worker promotes only the exact clean version to requester-accessible storage; unsuccessful or inconclusive security outcomes remain blocked and can pause the contributor account for review.

Terraform defines the complete production AWS environment as a modular monorepo: DNS, edge delivery, identity, data, application workflows, a dedicated VPC, and observability. CloudWatch alarms, encrypted notification paths, usage limits, AWS Budgets, lifecycle expiration, queue recovery, and WAF rate limits support production operation.

What was built during the hackathon

I conceived, designed, and implemented Spairly entirely during the official hackathon build window, which opened June 20, 2026. The repository’s first commit is dated July 26, 2026. I built the production website, AWS infrastructure, authenticated requester-and-contributor workflow, Amazon Nova assessment and matching system, on-demand translation, secure result-package pipeline, contributor badges, policies, observability, and end-to-end demonstration during the event.

I built Spairly using established third-party frameworks and managed services, including Next.js, React, TypeScript, Terraform, AWS services, Amazon Nova through Amazon Bedrock, and the Silktide consent manager. The demonstration uses public NASA POWER and WFP/HDX datasets. I do not claim those tools or datasets as original work; the Spairly product, architecture, workflows, integration, and user experience are my hackathon work.

Challenges I ran into

Making AI substantive without giving it authority it does not have

A single free-form model call would have been easy but difficult to evaluate, secure, or recover. I separated the workflow into scope, impact, matching, and translation operations with narrow inputs, explicit schemas, stored provenance, bounded retries, and clear UI disclosures. AI recommendations organize work; participants still decide what to claim and whether a result is useful.

Securing contributor-delivered files

The result package crosses a meaningful trust boundary. I designed a quarantine-first pipeline so requesters cannot access an upload until both structural validation and malware scanning succeed. Version matching, idempotency, lifecycle policies, failure queues, security alerts, and temporary account pausing protect against race conditions and unsafe results.

Keeping a two-sided workflow coherent

Requesters and contributors see the same task from different perspectives. Claiming, release, revision, completion, archiving, badge progress, and notifications must remain consistent when events are retried. Conditional and transactional DynamoDB writes prevent duplicate ownership changes and duplicate recognition.

Supporting language access without uncontrolled model spending

The public site is statically localized for discovery, while user-submitted requests are translated only when another participant needs them. Stored, versioned translations avoid repeating successful work, and the original text remains available for comparison.

Demonstrating impact honestly

The demo needed to show a compelling need without inventing a real customer or using private information. I created a clearly disclosed fictional library scenario and built its result package from cited public datasets. The analysis also demonstrates a valuable outcome: responsible AI work can rule out a tempting relationship instead of manufacturing a dramatic conclusion.

Accomplishments I'm proud of

  • A working production requester-to-contributor flow at spairly.com, not a clickable mockup.
  • Three focused Amazon Nova assessment stages plus on-demand translation, with minimized model inputs and stored structured outputs.
  • Ten-language public discovery and policy coverage with 135 indexed public URLs.
  • A secure result-package pipeline with private quarantine, strict ZIP limits, structural validation, GuardDuty malware scanning, clean-version promotion, and lifecycle retention.
  • Nineteen distinct contributor badges with shareable public social cards.
  • Production infrastructure defined in Terraform and protected by Cognito, CloudFront, WAF, API Gateway authorization, queues, alarms, encryption, rate limits, and an AWS budget.
  • A truthful end-to-end demo showing both requester and contributor perspectives, a checked bilingual evidence package, completion, and recognition.

What I learned

Matching is not only a recommendation problem; it is a trust-boundary and state management problem. The most useful role for AI here is to reduce ambiguity, surface missing context, improve language access, and make relevant work easier to discover—not to certify people or make final decisions.

I also learned that free access needs operational discipline. On-demand translations, per-account and edge limits, asynchronous queues, short-lived uploads, lifecycle expiration, and serverless infrastructure make the pilot more feasible without weakening the experience.

Finally, recognition can help turn one-time volunteering into an ongoing habit. A clear trail of confirmed contributions gives people a reason to return while keeping the focus on useful work rather than raw token consumption.

What's next for Spairly

The next phase is a focused pilot with educators, libraries, nonprofits, and community organizations. I want to measure request clarity, time to claim, completion rate, revision rate, language access, and the types of work that create the most practical benefit. Spairly does not yet claim real-world user adoption; the current production system and controlled demo establish technical feasibility.

Product priorities include stronger contributor discovery, better list-level translation, clearer project lifecycle controls, accessibility testing with disabled users, safer administration and appeals, and partner onboarding. I also want to publish transparent impact measures and reusable guidance that helps requesters define work contributors can responsibly complete.

The long-term opportunity is a global layer for pairing underused, authorized AI capacity with useful work—especially where conventional budgets and access fall short.

Built With

Share this project:

Updates