One student. One week.
An openly credited build.

Built independently, with help acknowledged.

I’m a 13-year-old Indian high school student, and I founded relayskills. I built RelaySkills as my own independent project over one week. I wanted to explore how people could learn from one another by sharing practical skills instead of relying only on money.

I built the main website framework and initial structure myself, then used AI to help develop the rest of the experience: ideas, supporting pages and content, additional implementation, debugging, refinement and testing. “Independent” means I was the student creator directing this project—not that every line, asset or idea was produced without assistance.

The one-week timeline and contribution split are the creator’s own account. The percentages are an approximate description of overall effort, not an independently measured count of code, hours or ownership. AI-generated work still requires human review; responsibility for the submitted project remains with its creator.

What the week involved

The build brought together a skill-exchange concept, an initial interface, linked pages, member accounts, a Cloudflare Worker, persistent D1 records, R2 integration code, and repeated revisions. As features were added, the work also involved connecting forms to real storage, finding inconsistencies, correcting navigation and making the interface behave across screen sizes. The project remains a learning experience, not a claim that every production problem was solved in a week.

The support behind the work.

I would like to thank my mentors and teachers for their guidance, encouragement and support in helping me reach this stage. Thank you to the people who were part of my learning journey and encouraged me to keep asking questions, improving the project and understanding what I was building.

These acknowledgements do not mean the running website sends user messages to Leonardo.Ai, DeepSeek, OpenAI, or a general cloud language model for the local RelaySkills guide. Provider use is limited to the functions described in the Privacy Policy; third-party names, trademarks, and licences remain with their owners.

How RelaySkills works.

RelaySkills uses a multi-page frontend and a Cloudflare Worker backend. Pages are ordinary HTML files. Shared CSS gives them a common appearance, and JavaScript adds navigation, preferences, forms, search and asynchronous updates. The Worker serves the pages and the application’s same-origin JSON API.

1. BrowserLoads HTML, shared styles and JavaScript.
2. RequestA form or interaction calls a same-origin API using Fetch.
3. Worker + D1Checks identity, permissions and inputs, then reads or updates records.
4. ResponseReturns JSON; the interface renders the result or a clear error.

Why the server matters

Opening an HTML file directly only opens the frontend. Account saving, messaging and other persistent features need the published Worker or a supported local preview. Both frontend and API use relative, same-origin URLs, so the browser does not need a separate public API address.

How records are stored

The published datastore is Cloudflare D1, a managed SQLite-compatible database bound to the Worker as DB. It contains account information and collections for supported features. The project’s Worker supports an R2 bucket binding for permitted uploads, but that binding is not enabled in the current deployment, so new media uploads are unavailable until activation. A local preview may use a separate local adapter and local data; local and live records are not the same dataset.

What stays in the browser

Some interface preferences and local helper state use localStorage. That storage belongs to the current browser and device; it is not account-wide cloud storage. Server-backed settings and records use API requests. The interface should not describe a local-only selection as a real enrollment, booking or submitted report.

What happens inside the main workflows.

Accounts, profiles and preferences

Registration and login are handled by the Worker. Passwords are stored as one-way password hashes rather than readable passwords. A signed, HttpOnly session cookie identifies the session; signing protects integrity, not secrecy. Account and administrator permissions are checked on protected routes. Write requests use a CSRF token to help prevent another website from submitting actions through a signed-in browser.

Profiles store teaching skills, learning interests, location preferences, language, timezone and other settings. Visibility rules limit what another member can see. Profile editing shows unsaved changes, a saving state and confirmation after a successful response. A departure warning helps prevent accidental loss of edits; a failed save leaves the edits available to retry.

Skill discovery and explainable matching

Discovery reads public profile and offer records. Matching runs in the Worker and compares the learner’s needs with eligible members. It uses explicit rules rather than a trained recommendation model: skill fit, learning goal, teaching style, session format, schedule overlap, language, proficiency, session history and reliability. Each result includes the points awarded and explanations. These are compatibility scores, not a proven percentage chance of success.

The current maximum weights are 35 for skill fit, 10 each for goal, style and format, 15 for shared availability, 8 for language, 5 for proficiency, 4 for session history and 3 for reliability. A strict search can exclude weak skill matches. Availability comparisons use timezone-aware windows over the next eight days. Missing history is disclosed rather than replaced with invented reviews.

Inbox, groups and safety

Conversations and messages are persisted on the server. Access checks determine which participants can read a conversation or attachment. The interface supports operations such as unread indicators, typing updates, blocking, reporting and group management. Message updates use repeated HTTP requests rather than a WebSocket service. A report creates a record for administrator review; it is not an automatic guarantee of resolution.

Student-account safeguards include age-derived restrictions, member-selected profile visibility, and guardian-consent review fields. These are application safeguards, not proof of identity or a guarantee of safety. Administrators still need to review concerns and apply appropriate policies.

Calendar, workshops and video

Signed-in members can publish a workshop from Host a workshop. The server checks the title, future start time, IANA timezone, duration, capacity and learning outcomes, and assigns the signed-in member as host. Each newly hosted workshop creates one shared calendar event and meeting thread. Reservations add attendees to that event; cancelling one place leaves other attendees booked. The host manages the schedule, cancellation and completion through Calendar, with changes reflected in the workshop listing. Existing workshops and accounts are retained.

Calendar records store participants, start and end times, timezone, reminders and changes. Times are normalized and converted for display. Workshop registration records capacity and attendance-related state. A background reminder worker creates platform notices when due. Calendar export uses ICS files and Google/Outlook event-composer links; it is not two-way OAuth calendar synchronization.

Video rooms use browser media APIs and WebRTC. Camera and microphone access require browser permission. The Worker handles room permissions and exchanges connection-signaling data; peer connections carry the media. Network conditions can require configured STUN/TURN infrastructure, and large calls would require a different media-server architecture. A successful page load alone does not verify video connectivity on every network.

Time credits and account records

Time credits are internal exchange units, not currency or a bank account. The ledger stores payments, one-credit one-way exchange transfers, streak milestone rewards, adjustments and refunds with references and resulting balances. Streak rewards are 25 credits at 7 days, 100 at 30, 400 at 100, and 1,000 at 365, once per milestone. A transfer checks the amount and balance before recording the outgoing and incoming entries. Disputes are reviewed through administrator tools. Corrections create further entries rather than silently rewriting the original transaction. Merely passing a scheduled end time does not prove an exchange occurred or automatically settle a payment.

Time credits are the transferable account balance used for exchanges and Gifts & vouchers. Other activity records may still appear in member portfolios for context, but there is no separate catalogue or automatic prize-claim system connected to them.

Innovation, marketplace and learning records

The innovation area stores member proposals, comments and support activity, with additional review handling for student submissions. Marketplace records support offers and purchases in internal credits. Funding pledges record expressions of support; no payment processor transfers money. The learning journal stores a member’s own reflections and practice minutes. Achievements are calculated from recorded account activity; they are not accredited certificates.

Feedback, newsletters and administration

Feedback is saved with a publication-permission choice. Public testimonials include only permitted public fields; an email address is not included in the public testimonial response. Newsletter sign-up validates the email and consent, saves it, and exposes the list only to administrators. The administrator can copy addresses and send updates manually. The website does not claim to have sent an email just because a subscription was recorded.

The admin panel provides account controls, content review, reports, disputes, recorded-data charts and the newsletter list. Administrative actions are logged. The charts are drawn using the browser’s Canvas API, with values calculated from records—not preset decorative datasets.

RelaySkills AI: a local website guide

RelaySkills AI matches questions to a local knowledge base of website topics using keywords and spelling similarity, then returns guidance and relevant links. It is not the same as the AI tools used to build this project. The current implementation does not use a general cloud language model for these answers, and it should not be treated as an expert or a source of verified personal advice.

Recorded numbers, clear limits.

Existing content, including starter workshops, ideas and feedback, is preserved and displayed. Public summary numbers come from /api/platform/metrics, and public record cards come from /api/public/content. Visible summaries refresh every 5 seconds while the page is active and refresh again when the user returns. This is polling-based freshness, not a claim of instant streaming.

Registered active accounts

Non-administrator accounts whose status is active; includes existing starter accounts. This is not a count of people currently online or recently active.

Publicly listed skills

Distinct skill names from eligible public profiles and published offers. This is a catalogue count, not a claim of verified expertise.

Countries represented

Distinct country values recorded on active member profiles, regardless of whether the individual profile or location field is public. This aggregate reveals no country names, profile names or individual private locations.

Public groups and private group chats

Public community groups are counted separately from private inbox group chats. Private chat totals reveal no names, messages or members. A public group’s linked chat is not counted twice. All saved public groups remain available, including the original starter groups.

Recorded calls, sessions and meetings

Counts saved calendar sessions that are completed or have elapsed, accepted or ended direct calls, completed or elapsed Study Together sessions, and standalone video rooms with recorded attendance. Cancelled, declined, missed, ringing-only and future records are excluded; linked rooms are deduplicated. This is a count of saved platform records, not independently verified attendance. Hours remain based on confirmed calendar-session durations.

Public feedback rating

The average of actual published site-feedback ratings with publication permission. It is not a teacher rating or a session-success rate.

Zero means a measured empty collection. “No data yet” means an average has no ratings. “Unavailable” means the statistics request failed. “Compatibility error” means required statistics are missing or invalid: restart the updated server and refresh. Saved accounts and content are included regardless of starter IDs. These are counts of saved records, not claims that every entry is independently verified or organically created. Historical records are retained, not deleted.

Pages without a connected course catalogue, formal certification service or published resource collection state that limitation. Fabricated participation totals, outcomes, testimonials and progress bars have no place as evidence of actual activity.

Tools, libraries and standards.

HTML, CSS and JavaScript

The frontend uses native web technologies: semantic page structure, responsive Grid/Flexbox layouts, shared design tokens, DOM events and Fetch requests. It does not use React, Vue or Tailwind as its application framework.

Cloudflare Workers

The published Worker handles same-origin routing, authentication, validation, permissions, application logic, JSON responses, session cookies, and static asset delivery.

Cloudflare D1 and R2

D1 stores structured account, profile, community, calendar, credit, moderation, and activity records. The Worker includes R2 integration code, but the current deployment does not have the R2 binding enabled, so new object uploads are not active. Any future activation remains subject to the deployed binding and retention controls described in the Privacy Policy.

IANA timezone database

Timezone identifiers support profile validation, scheduling, streak dates, and overlap calculations across countries with multiple timezones.

Boxicons

Boxicons supplies the interface icon font. Its stylesheet and font file are self-hosted with the RelaySkills website so the interface does not depend on a third-party CDN at runtime.

Browser APIs

Fetch communicates with the Worker. FormData collects input and uploads. localStorage holds browser-local preferences. Canvas renders admin charts. MediaDevices and WebRTC support calls. ResizeObserver helps layout-aware navigation; the Clipboard API supports explicit copy actions. Browser capabilities and permissions affect availability.

HTTP, cookies, OAuth, JSON and ICS

JSON carries API payloads. HttpOnly signed cookies support sessions. Google OAuth supports optional account linking and sign-in. ICS exports calendar events. Google and Outlook links open event-composer interfaces; they do not imply background calendar synchronization.

Development and testing tools

Node.js runs build scripts and focused checks; Wrangler packages and deploys the Worker. Browser tools assist with viewport checks, screenshots, and interaction testing. Development tools may change without becoming runtime services used to process member content.

Third-party projects retain their own names, rights and licences. Acknowledgement is not a claim of endorsement or a replacement for licence compliance. The live integration list is intentionally limited: Cloudflare delivery and D1 storage, Google OAuth where enabled, Google Analytics measurement, Boxicons delivery, and browser APIs described above. R2 is configured in code but is not active in the current deployment.

Where the pieces live.

The website’s own API

The /api/ routes are RelaySkills application endpoints—not a collection of external paid services. For example, /api/auth/me describes the current session, /api/profile saves profile changes, /api/matches computes matches, /api/calendar returns permitted calendar information, and /api/credits returns the signed-in member’s ledger. Administrator routes require administrator access.

Forms send structured requests, wait for a successful server response and then render the saved state. Validation errors should explain why a request was rejected. Private API responses must not be copied into public statistics or exposed merely to make a page appear busy.

What this project does not claim.

Automated checks cover selected authentication, privacy, messaging, scheduling, credit, newsletter, matching and settings behaviors. Passing tests is useful evidence, but not a guarantee of security, accessibility, performance or compatibility on every device. Desktop and mobile viewport checks are not the same as a full real-device test programme.

The published application uses D1, polling-based updates, browser media APIs, and a rule-based guide; R2 integration code is present but its live binding is not enabled. A larger public service would still need continued work on backups, monitoring, email delivery and recovery, abuse prevention, accessibility, moderation capacity, and video infrastructure. No formal certifications, paid subscriptions, or unconnected integrations should be presented as working services.

AI helped accelerate the build, but it also required checking and correction. The purpose of this page is to make the contribution and implementation understandable—not to hide assistance or overstate what has been built.

Created by a 13-year-old Indian high school student
With thanks to my mentors, teachers and the tools that helped me learn.