Internal Assessment · Published Openly
Is Synapse a Product? An Honest Internal Assessment
Is Synapse a product?
An honest read of what was built, whether the one big engineering bet paid off, and the market it would have to survive. Written for myself, published because the interesting parts are the uncomfortable ones.
"The engineering is genuinely excellent and the product does not exist yet. Both are true, and they are not in tension."
Synapse is the platform serving you this page — prose lessons with runnable code, judged practice problems, and step-through visualisations of your own code executing. I built it as a learning exercise, with a working reference implementation as the oracle, and it succeeded completely at that.
But the things that make software a product — someone can find it, someone comes back, someone pays — were never in scope, so they were never built. This is the assessment I wrote for myself about that gap. I'm publishing it because the flattering parts are boring and the uncomfortable parts are the ones worth reading.
Four Numbers That Frame Everything
Every honest assessment starts with counting rather than feeling. These four numbers set up every argument that follows.
757,000 Words of Prose
442 lessons across 7 books. Years of writing that no amount of engineering substitutes for — and the single hardest thing here to replicate.
30 Judged Problems
In the entire corpus; 29 of them in one book. LeetCode has roughly 3,500. This is not a gap that can be closed by trying harder.
2 of 11 Languages Traced
The visualiser — the one genuinely differentiated feature — follows execution in Python and Java only. That's 18% of the languages the sandbox runs.
442 Indexable Page Titles
This was 1 — a single hardcoded title across every lesson, making all 442 identical in a search result. The rebuild below fixed it structurally.
Did Rebuilding the Read Path Pay Off?
The reader originally shipped as a client-rendered WebAssembly application: about 20,000 lines of Rust compiled to a bundle that had to download, compile and boot before a single word of prose appeared. Measured on production, content was readable at 1.25 s on broadband and 7.2 s on a mid-range phone over slow 3G — for lessons whose actual text is around 2 KiB.
That is an absurd trade, and the workload table made it indefensible: reads are ~99% of all traffic. The architecture of the read path had to answer to that number. So it was rebuilt — server-rendered pages, with the editor, diagrams and visualiser hydrating as lazy per-feature islands only on pages that use them.
Here is what actually changed, measured on the live site rather than modelled:
2.4× Faster — Broadband
1.25 s → 0.52 s to first content. Median of three runs. The model predicted ~3×; the model was an upper bound.
3.9× Faster — Mid-Range Phone
7.2 s → 1.86 s on throttled 3G with a 4× CPU penalty. The slowest path saw the biggest absolute win, which is the right way round.
~93% Less JavaScript
641 KiB gzipped of WebAssembly that blocked all prose → ~47 KiB of eager JS per page. Everything heavy is now lazy and optional.
| Measure | Before (WASM client) | After (server-rendered) | Change |
|---|---|---|---|
| First content — broadband | 1.25 s | 0.52 s | 2.4× faster |
| First content — phone / slow 3G | 7.2 s | 1.86 s | 3.9× faster |
| Blocking JS before prose | 641 KiB gz | ~47 KiB gz | ~93% less |
| Prose arrives as | Output of a compiler, after boot | HTML in the first response | Structural |
| Distinct page titles | 1 (hardcoded) | 442, server-rendered | Indexable |
| Works without JavaScript | No — blank page | Yes — reading is plain HTML | Resilient |
The delivered 2.4× / 3.9× lands slightly under the modelled 3× / 5×, and that is worth stating plainly rather than rounding up. But the model was always the ceiling, and the structural change is the real headline: time-to-content is no longer a function of how fast a compiler boots. A per-page JavaScript budget now fails the build if any island ever goes eager again, so the win cannot quietly erode.
It also closed a product gap for free. Server rendering made per-page metadata real — every lesson emits its own title, description, social card and canonical URL, with a sitemap and robots file generated from the same in-memory index. That was a ranked backlog item; it arrived as a side effect.
💡 What the migration is, and what it isn't: it is an enabler, not a mover. It made the read path fast and findable — the preconditions a product needs before growth is even measurable. It did not, and could not, change the market realities below, deepen the corpus, or create a revenue mechanism. The right technical bet, executed and verified in production, on a project whose product verdict is unchanged.
Everything Works. Nothing Compounds.
The gaps here are not bugs or half-finished features — every shipped surface works. They are whole categories of product machinery that were never in scope, which is exactly why none of them ever appeared in a backlog as unfinished business. You do not notice the absence of a growth loop when you never planned one.
✅ Built, and built well
- ✅Architecture enforced by CI, not by review discipline — a conventions gate that fails in seconds, before any toolchain installs
- ✅Cross-language port fidelity pinned by golden differential tests
- ✅A Java in-sandbox recompile tracer with trace-stable heap identity — genuinely weeks of specialist work
- ✅A real sandbox container in CI, not a stub; database integration tests with prove-it-ran guards
- ✅A server-rendered read path with a per-page JS budget, and a headless browser suite that fails the build if a widget stops mounting
❌ Still out of scope
- ❌No organic acquisition channel — indexing is now possible, but nobody is driving traffic
- ❌No product analytics beyond an anonymous lesson-view counter
- ❌No billing, plans or quotas anywhere in the codebase
- ❌Single-tenant, git-push authoring; production is architecturally invite-only
- ❌No spaced repetition or long-horizon learning loop — progress is remembered, never scheduled
The Category Is Contracting, and Investors Have Named It
Nothing in the rebuild touches this section. It is included unchanged because it remains the binding constraint on any product decision, and because it is the part I would most like to be wrong about.
Crunchbase News reported in late 2025 that investors are keen on healthcare education and AI-enabled K-12, while "coding academies and teaching platforms" face headwinds. That is this category, named explicitly.
| Period | Global edtech venture funding | Note |
|---|---|---|
| 2021 | $16.7B | The peak |
| 2024 | $2.8B | ~83% below peak |
| 2025 | $2.8B | Flat — no recovery |
| H1 2026 | $1.0B | −26% YoY against the equivalent H1 2025 |
Company formation tells the same story: roughly 10,500 edtech launches in 2020, down to 645 in 2025. And the structural evidence is unambiguous. Skillsoft laid off Codecademy's entire curriculum team. 2U filed Chapter 11 on the back of a 40% drop in bootcamp enrollments. Chegg is down roughly 99% from its peak and cut 45% of staff. Coursera and Udemy announced a defensive merger for cost synergies. Stack Overflow questions fell about 76% from their peak — developers simply stopped going to websites to learn things.
Two counter-signals, stated honestly, because a one-sided case is a useless one: AI content demand is booming, and LeetCode traffic grew 19% month-over-month in mid-2026. Interview prep is holding up. Demand is rotating from "learn to code" toward "learn to use AI."
⚠️ Python Tutor is the most important datapoint here. Philip Guo has run the closest analog to my visualiser since 2010 — now 25M+ users. In his UIST 2021 paper he writes that he could not secure long-term funding and sustained it by "sneaking it into" a conventional academic career, and observes that despite billions in venture and big-tech money, no company has built its own code visualization tool. That is simultaneously the strongest differentiation argument available to me and the strongest evidence the capability has never supported a business.
🎓 Runestone Academy needs an answer. Open-source, self-hostable, prose-first interactive textbooks with embedded runnable code and trace visualisation — grant-supported, running since 2011. That is close to a feature-for-feature match minus the AI coach and the diagrams. "Ours is nicer" is not an answer to fifteen years of funded open source, though "ours is 4× faster on a phone and every lesson is indexable" is at least a sharper one than it was a week ago.
Where Synapse Actually Sits
The one genuine differentiator is tracing the learner's own code inside a prose lesson — shared only with Python Tutor and Runestone's CodeLens, which is Python Tutor embedded.
| Player | Traces your own code | Prose + execution | Judged problems | Commercial outcome |
|---|---|---|---|---|
| Synapse | Yes · 2 langs | Yes | 30 | No revenue mechanism |
| Python Tutor | Yes | No | — | 25M users, never monetized |
| Runestone | Yes | Yes | Parsons etc. | Grant-funded |
| Educative | No | Yes, + AI tutor | Some | ~$14.6M raised, none since 2021 |
| Exercism | No | Yes | Many | 2M users, couldn't make payroll |
| freeCodeCamp | No | Yes | Many | Donations; sets the price floor at zero |
| LeetCode | No | No | ~3,500 | Growing 19% MoM |
| AlgoExpert | No | No | Many | $1.9M ARR, 14 people |
Revenue figures circulating for several of these contradict each other by up to 10× across sources, so they are omitted rather than guessed.
The Backlog — Ranked by Leverage, Now Largely Shipped
Order carried real information here: item 1 was first because nothing below it could be prioritised until it existed. Four of the five have since been built. The ranking is preserved so the reasoning stays legible.
Measurement — you cannot prioritise what you cannot see
There was no way to answer "does anyone read this, and what?" Every item below it was a guess until that changed. The cheap version needed no third party, no client JavaScript and no cookie banner, because every lesson view already flows through one endpoint I own. An append-only row keyed on the lesson path. No user id, no IP address.
Discoverability — delivered by the rebuild
442 identical titles made every page indistinguishable in search, and social preview cards do not run JavaScript at all. The original plan was server-side meta injection as a string substitution; the rebuild did the deeper thing instead, so the fix is structural rather than a patch.
A reason to come back
The instinct was a progress table behind a login — the wrong first move, since the reader is anonymous and an invite-only account reaches almost nobody. Instead: local read/complete state, "continue where you left off", completion ticks. All anonymous, all client-side.
A browser smoke suite — the biggest rigour gap
For a product whose entire value is interactive widgets, every "verified live" note was a human in a browser tab, and the existing gates structurally could not catch a widget that silently stopped mounting. Now ten specs run against a production-shaped serve, plus the per-page JS budget. It caught real regressions during the rebuild.
Deepen the 30 problems — emphatically not more of them
Problem volume is the most commoditized axis in this market and it cannot be won. Thirty problems where you can watch your own code build the data structure is a better story than three hundred generic ones, and it plays to the one asset nobody else has. This is the only item still open — and it is a content bet, not an engineering one.
What Not to Build — the Expensive Instincts
Deciding what not to do is the higher-leverage half of a roadmap, and every line here is something I have actively wanted to build at some point.
| The instinct | Why it's wrong, for now |
|---|---|
| More tracer languages | Each is multi-week work, and the corpus is already 99% Python and Java — the marginal value against existing content is near zero. Build a third only when a real reader asks for it. |
| Multi-tenancy, a CMS, an authoring UI | Only pays off if there will be other authors. There won't be, unless the positioning changes first. |
| Scaling past one replica | The current concurrency budget is correct for current load. The rebuild made reads edge-cacheable and origin-light, which pushes that trigger further out, not closer. Know the trigger; don't pre-solve it. |
| An investor deck | Not as a consumer learn-to-code product. The category is named as out of favour, the closest analogs are dead or unfunded, and there is no traction to show. A faster site does not change this. |
What This Project Actually Is
Worth saying plainly, because the list above is unrelenting and could be read as a verdict on the work rather than on its scope.
Synapse is an exceptional portfolio artifact and a genuinely good personal learning platform. As a demonstration of engineering judgement it is stronger than most production systems I have worked in: the architecture is enforced by CI rather than by review discipline, port fidelity is pinned by cross-language differential tests, and every significant decision is documented with the reasoning that produced it. The in-sandbox recompile tracer, and the read-path rebuild that made the site multiples faster while it stayed live in production, are both the kind of work that gets someone hired.
It is not a business, it was never built to be one, and the backlog above has now been executed — which means, for the first time, the project can tell me whether anyone is reading it. That was the entire point of doing those items: not to make it a product, but to make the question answerable.
🌱 The closing thought: the rebuild removed the last excuse the read path had for being slow and invisible. What it cannot do — what no amount of engineering can do — is change the answer the market section keeps giving. I would rather know that clearly than discover it slowly.