System study · Dormant
DotCode
A browser code editor with a community around it — HTML, CSS and JavaScript edited side by side against a live preview, and a REST API behind projects, posts, comments and search.
- verifiedDotCode — 180 source files, 17,408 lines, read and counted
- Role
- Sole author — all 1,556 commits
- Period
- 2024-06 — 2025-01
- React
- Redux
- CodeMirror
- Express
- MongoDB
- JWT
The artifact
Fig. 1

Two products, wired together
DotCode is two products wired together. One is an editor that runs in the browser: HTML, CSS and JavaScript in separate documents, a live preview beside them on a draggable split, and an export that writes the files out individually or zips the set. The other is somewhere to put what you make — projects, posts, comments, profiles and a search across them.That pairing is the whole shape of the thing, and it is visible in the source before anyone explains it: the application has four page areas — editor, community, profile, home — and the API answers on six route groups behind them. What is not visible in the source is why it was started or why it stopped, and neither is invented here.
- verifiedDotCode — 180 source files, 17,408 lines, read and counted
Who built it
- Engineering role
- Sole author
- verifiedDotCode — 1,423 commits across two repositories, one author
- Measured contribution
- 1,556 of 1,556 commits (100%)all three repositories — 1,156 commits on the application, 267 on the API and 133 on the deployment build, over seven months
- verifiedDotCode — 1,423 commits across two repositories, one author
- Team
- Sole author. The audited history carries two author names, which are one person under two git identities rather than a second contributor.
- verifiedDotCode — 1,423 commits across two repositories, one author
How the two halves are built
The editor is built on CodeMirror 6 rather than a textarea: the language packages for JavaScript, HTML and CSS, the search extension and the one-dark theme are all direct dependencies, wrapped through the React binding. Around it sit a resizable split pane, GSAP for movement, and an export path that uses JSZip and file-saver to hand back either loose files or a single archive. State runs through Redux Toolkit with redux-saga alongside it, which is a heavier choice than a five-month project usually reaches for and is the clearest signal in the source of what it was aiming at.The API is the conventional layered Express build, done properly rather than improvised. A generic handler factory supplies the repeated operations — create, read, update, delete, list, list-mine, search, like and unlike — parameterised by model, so the four models do not each carry a hand-written copy. Query behaviour is one class with filter, sort, field-limiting and pagination. Errors travel through a catch-async wrapper, a typed application error and one global handler, so a controller never formats its own failure response.Authentication is JSON Web Tokens issued server-side and returned in an HTTP-only cookie, with passwords hashed by bcrypt and cross-origin requests restricted to a single configured origin with credentials enabled. Four Mongoose models carry it: user, project, post and comment. All of this is read from the source; none of it was exercised, and the case study claims nothing about how any of it behaved.
- verifiedDotCode — 180 source files, 17,408 lines, read and counted
In-browser editor
CodeMirror 6 with language, search and theme packages, a split preview, and export to files or a zip.
- verifiedDotCode — 180 source files, 17,408 lines, read and counted
REST API
Express and Mongoose, generic handler factory, one query-features class, centralised error handling, cookie-borne JWT auth.
- verifiedDotCode — 180 source files, 17,408 lines, read and counted
Application and API
- Fig. 2

The two halves as the source describes them. The connector is dashed because it is declared in configuration and was never exercised here, and the finding beneath is about this machine rather than about the design.source · DotCode — application and API, drawndiagram — drawn from a source audit, not a capture
The product
Step through the sequence — every step is also readable in order without doing so.
- 01 — THE EDITORproduct screenDOTCODE — THE EDITORreserved · 16/10
- 02 — LIVE PREVIEW AND SPLIT PANEproduct screenDOTCODE — LIVE PREVIEW AND SPLIT PANEreserved · 16/10
- 03 — COMMUNITY AND PROFILEproduct screenDOTCODE — COMMUNITY AND PROFILEreserved · 16/10
What the repositories show
- Commits
- 1,556 commits
- verifiedDotCode — 1,423 commits across two repositories, one author
- Active span
- 7 months
- verifiedDotCode — a third repository, the deployment build
- Source
- 17,408 lines
- verifiedDotCode — 180 source files, 17,408 lines, read and counted
- API surface
- 6 route groups
- verifiedDotCode — 180 source files, 17,408 lines, read and counted
Evidence
7 sources · how each was obtained
- verifiedDotCode — application and API working copiesrepository · attests existence · captured 2026-08-19two local clones, each with a full .git directory and a configured remoteLocal working copies on this machine. Strong evidence that the work exists; no evidence about any canonical remote, and none about whether anything is still deployed.
- verifiedDotCode — 1,423 commits across two repositories, one authorcommit-history · attests existence · captured 2026-08-19git log over both clones: 1,156 commits on the application from 2024-06-10 to 2024-11-04, and 267 on the API from 2024-10-08 to 2024-11-01; 1,422 authored as sgc93 and 1 as Smachew Gedefaw C.The two author names are one person under two git identities, not a second contributor. These two repositories stop on 2024-11-04; the deployment repository carries the work on to 2025-01-19.
- verifiedDotCode — 180 source files, 17,408 lines, read and countedrepository · attests structure · captured 2026-08-19154 files and 15,850 lines in the application, 26 files and 1,558 lines in the API, excluding node_modules and build output; dependency manifests, route table, models, controllers and editor utilities read directlyProves how the code is written and what it is built from. It says nothing about what happens when it runs, and nothing here ran it.
- verifiedDotCode — a third repository, the deployment buildcommit-history · attests existence · captured 2026-08-19git log: 133 commits from 2024-11-01 to 2025-01-19, one author under two git identities; the working copy holds the client and the API together as a single deployable, 182 files and 18,311 lines, with a vercel configurationLargely the same product as the other two repositories rather than new code, so its line count is not additive with theirs. What it changes is the date the work stopped: 2025-01-19, not 2024-11-04.
- provisionalDotCode — the three remotes declared by the local clonesexternal-reference · attests existence · captured 2026-08-19git remote get-url origin across the three working copies: sgc93/dotcode, sgc93/dotcode-api and sgc93/dot-deployRead from local git configuration; none of these URLs was fetched from this machine, so whether they resolve is unconfirmed. The previous portfolio recorded only the deployment repository for this project, which is why it appeared to name the wrong one.
- verifiedDotCode — one capture of the client running locallyFig. 1screenshot-set · attests existence · captured 2026-08-21the client run on localhost and captured at 1440x900; the landing page renders without the API, so this frame needed no server and no dataOnly the landing page. The API will not start on this machine: a transitive dependency of its token library reads a Buffer helper that Node removed after version 21, and it throws before the server binds. Without it the editor opens its shell but loads no project, and the community view has nothing to show — so those three slots stay reserved rather than being filled with an empty application. The only database export available holds ten real user records, which is a second reason not to photograph the community view.
- provisionalDotCode — application and API, drawnFig. 2diagram · attests structure · drawn 2026-08-21drawn from ev.dotcode.source-audit; the connector between the two halves is dashed because it is declared in the client's configuration and was never exercised hereAn illustration, not a capture. It depicts the shape the source audit established, and it is provisional because a person drew it and nobody can re-run drawing. It is not evidence that the system behaves as drawn. The band beneath it records the runtime incompatibility found while attempting capture, kept visually separate because it is an environment finding rather than part of the design.
Links
Still open
What this case study does not yet cover, and what would close it.
Awaiting a written account
- The constraints this was built under were not recorded.
Never measured
- No outcome was measured while this project was active.
Awaiting first-person reflection
- What this project taught has not been written up yet.
- The alternatives that were considered were not recorded.
- A first-hand account of this work has not been written yet.
- The reasoning behind the engineering decisions has not been written up yet.