Skip to content
Tomer Naydnov

§01/Arc

Product · Education · Platform

Arc

The problem was never where the files lived. It was that authoring, teaching and feedback were separate systems.

A learning-operations platform connecting reusable content, live classrooms, student work, instructor feedback and the next teaching cycle.

Role
Co-developer · architecture, product workflows and quality
Span
Jan 2026 — now
Status
Portal online
Team
Co-developed with another engineer

The public Arc portal is reachable. The exact feature set on the audited development branch is not asserted as deployed.

§02/The 60-second version

The 60-second version

01 / What was broken
Teaching material was repeatedly searched for, rebuilt and adapted while the evidence from each classroom disappeared into the next session.
02 / The move
Treat the lesson as a living loop: reusable content becomes a classroom release, student work becomes feedback, and feedback changes what gets taught next.
03 / My contribution
I co-developed Arc across architecture, portal workflows, authentication and authorization, realtime behavior, touch interaction, testing and a broad frontend refactor.
04 / What exists as proof
A reachable public portal and an audited private product repository with dated contribution history and substantial automated test infrastructure.

§03/The full story

Open what matters

The story

The summary above stands on its own. Open the decision trail below, one chapter at a time.

01/SignalThe workaround was teaching us something

The workaround was teaching us something

While teaching and developing educational material, I kept seeing the same quiet tax: instructors searching for the right version, rebuilding something that already existed, or beginning a lesson without the context left by the previous session. That observation is my account of the problem; it is not presented as a measured adoption study.

A shared folder looks like the obvious fix. But a folder can tell you where a file is, not whether it is current, how it belongs in a lesson, what happened when it met a classroom, or what should change next.

02/FrameOne loop, not another library

One loop, not another library

Arc now spans reusable activities and content packs, lesson composition, live classroom release, versioned student submissions, instructor review, revision requests, analytics and operational administration.

The useful abstraction is the loop underneath those features: content becomes a lesson; a lesson becomes an activity; activity produces work; review changes the next version. The portfolio reconstructs that loop instead of publishing private product screens or listing every feature.

03/BuildWorking across the seams

Working across the seams

Arc was co-developed with another engineer. The repository shows substantial work from both contributors, so the case is deliberately explicit about that boundary.

My dated contributions cross layers: replacing loosely shaped controller data with typed view models, decomposing oversized portal controllers, restructuring application services, correcting authorization wiring and password handling, moving realtime behavior toward WebSocket-first delivery, building test and CI coverage, and making a collaborative flowchart work with touch and pointer input.

That breadth is the point of the case. I was not moving between unrelated subjects; I was following the same classroom workflow through every technical boundary it crossed.

04/ProveQuality is part of the classroom workflow

Quality is part of the classroom workflow

The audited repository contains substantial automated test infrastructure. Authored browser tests explicitly exercise phone-sized layouts, both language directions and high zoom. That is evidence of deliberate validation work, not a claim that every test passes today or that every physical device is covered.

The production lesson is simpler: a classroom interaction that works only with a mouse, only left-to-right, or only on a developer laptop is not partially finished. It is a broken teaching tool.

05/FieldLive, private, and still moving

Live, private, and still moving

Arc has a reachable public portal and active deployment configuration. The branch audited for this portfolio is ahead of the shared development branch, so I do not claim that every inspected feature is already running in production.

The product also contains real classroom and learner material. None of that is portfolio content. Names, submissions, recordings, uploads and operational records remain private; the artifact shown here is rebuilt from source structure with deliberately fictional data.

§04/The evidence underneath

Optional depth
System & architecture
Multi-portal
Product surface

Student, instructor and operational flows

Automated suites
Quality system

Repository inventory, not a pass-rate claim

Phone · RTL · zoom
Responsive intent

Authored browser tests; not a device claim

2,026
Repository record

Dated history from January 2026

Technology

  • Laravel 11
  • PHP 8.2
  • TypeScript
  • React
  • Alpine.js
  • Laravel Reverb
  • Vite
  • PHPUnit
  • Laravel Dusk
Decisions & trade-offs
  1. D-01

    2026-05

    Replace loose view data with explicit view models.

    Why
    As portals grew, implicit controller-to-view contracts made changes hard to reason about and easy to break across roles.
    Tradeoff
    More types and mapping code in exchange for visible, testable boundaries.
    Revisit if
    If a simpler boundary can preserve the same clarity without recreating array-shaped contracts.
  2. D-02

    2026-05

    Make authorization a platform boundary, not a controller habit.

    Why
    Student, instructor and administrative surfaces share data while requiring very different authority. Ad-hoc checks do not scale with that overlap.
    Tradeoff
    Policy wiring adds ceremony, but makes the security decision inspectable in one place.
    Revisit if
    When a new role or portal cannot be described by the current policy model.
  3. D-03

    2026-07

    Treat touch support as behavior, not responsive styling.

    Why
    A collaborative flowchart can fit on a phone and still be unusable if its drag, selection and connection model assumes a mouse.
    Tradeoff
    A more complex pointer model and a larger interaction test surface.
    Revisit if
    If the editor adopts a unified interaction engine with equivalent keyboard and touch behavior.
If I rebuilt it today
  1. 01

    Define and preserve a privacy-safe adoption denominator before publishing reach numbers.

  2. 02

    Make deployment parity visible so a branch, a release and the live portal cannot quietly diverge.

  3. 03

    Keep the public reconstruction generated from fictional fixtures, never from blurred production records.