schooloffreelancing/back-office

1. Overall shape

This repository is a static, content-driven training portal rather than an application with a backend. The root is dominated by HTML pages, shared CSS/JS, and third-party front-end plugins. The site’s purpose is to present training information, onboarding steps, policies, and many outbound community/support links.

2. Primary user-facing boundary

The main entry points are index.html and the many sibling pages such as about.html, getstart.html, faq.html, training.html, contact.html, mentor.html, linux.html, kyc.html, and policy/legal pages like tou.html, refund.html, security.html, impressum.html, and notice.html. These pages form the public site navigation and are the core of the architecture.

3. Content model

The repository is organized as a set of independent static pages instead of a single app shell. Pages appear to be manually authored and themed consistently, with repeated structural patterns likely shared through common CSS/JS rather than server-side templates.

4. Shared presentation layer

Styling is centralized in css/style.css, with a source map present in css/maps/style.css.map. Fonts live under fonts/. This is the main UI layer that gives all pages their common branding, layout, and responsive behavior.

5. Client-side behavior

The site’s custom interactivity is concentrated in js/script.js. This is likely where navigation behavior, smooth scrolling, animations, form/UI helpers, and page-specific enhancements are wired up. There is no evidence of a backend API; client-side JavaScript is only an enhancement layer.

6. Front-end plugin subsystem

The plugins/ directory bundles vendor assets such as Bootstrap, jQuery, AOS, Animate.css, Slick, Venobox, MixItUp, and a Google Maps integration. Architecturally, these are supporting UI components used by the static pages for animation, carousel/gallery behavior, filtering, modal/lightbox views, and map display.

7. External service and community integrations

The site is heavily connected to external platforms rather than internal services. The README points to Google Docs session materials, Trello for onboarding, Facebook/WhatsApp/Telegram/Gitter/Slack for communication, and YouTube/social channels for community presence. These links are part of the operational flow of the training program.

8. Training pipeline as a business flow

The README describes a multi-step onboarding process: initial contact, prerequisite check, payment/deposit, then onboarding into training sessions. In architecture terms, this is a human workflow implemented through static content and external tools, not a software workflow backed by application code.

9. Docs and session content

The “Session 1” through “Session 90” links in the README point to Google Docs, which function as the actual curriculum artifacts. The repository itself acts as the front door and index for those materials, while the authoritative training content lives outside the repo.

10. Deployment and automation

The repo includes .github/workflows/ for Jekyll, Node.js, Dependabot, stale issue management, and other housekeeping, plus .circleci/config.yml. This indicates CI/CD around a static site: validate/build the site, keep dependencies healthy, and publish to hosting such as GitHub Pages or a similar static target.

11. Site management and compliance

Files like robots.txt, sitemap.xml, .htaccess, htaccess, keybase.txt, SECURITY.md, and GitHub issue templates show operational maturity around discoverability, hosting rules, verification, security reporting, and contributor workflow. These are supporting boundaries around the public site rather than core application logic.

12. Notable absence

There is no clear backend service, database, authentication system, or API layer in this repository. The architecture is therefore best diagrammed as: browser → static pages/assets → external community/documentation services, with CI/CD responsible for publishing the static site.