Development system case study

Slideotter – Learning faster than the product converged#

Slideotter is a local, structured workbench for creating and reviewing presentations with language models. I developed it with coding agents between April and June 2026, before beginning Kirjolab. It produced a capable application and reusable rendering and review controls, but did not establish a clear first production use. The case asks how a project can validate its artifacts thoroughly while learning too little about which product people would repeatedly use.

Follow an idea

Revisit a definition, compare examples, or check a common mistake.

Explore concept connections

Explore the connections

Select a topic to read its definition and discover connections beyond this reading.

Read arrows as topic → relationship → topic. Plain lines connect comparisons and associations.

5 concepts · 3 connections

Read the relationships

Decision log records rationale for Trade-off
The log preserves the alternatives, rationale, and consequences that justified a trade-off under the conditions known at the time.
Decision log Project harness accepted context
Decision records preserve accepted project context, while current specifications and executable harness checks must reflect the implemented choice.
Project harness provides evidence for Acceptance criteria
Harness checks provide repeatable evidence for acceptance criteria, while a named owner remains accountable for acceptance.

Try explaining a connection

Hide the labels and choose two connected topics. Write a linking phrase and decide whether the statement needs a direction. Read it as a complete sentence, then compare it with the authored label and explanation. Which assumption makes it hold, and when might it fail?

Explore these topics together →

Case at a glance#

The case uses the 24 June 2026 source snapshot. The table below records the reviewed interval and delivery context.

Table 1. Repository evidence from the reviewed Slideotter snapshot. #
Evidence	Observation
Development interval reviewed	19 April–24 June 2026
Delivery targets explored	Local browser, desktop, and cloud
Public product status at review	Alpha

Validate the rendered artifact#

The project found durable authority boundaries#

The first generator produced PowerPoint files, but two days after the initial commit the project replaced that path with PDF generation. Two days later it began a browser studio, then moved preview, export, and validation to a shared DOM renderer.

The replacement exposed a durable rule: preview and exported output should use the same rendering authority. The architecture keeps structured slide specifications as content, the DOM runtime as rendering authority, and the server as the file-write boundary. Generated changes remain candidates until the author applies them.

Validation treated the artifact as more than source code#

Slide software can typecheck while producing unreadable slides. Slideotter therefore checks geometry, text fit, media, visible-text quality, browser workflows, rendered baselines, and PDF output. Its repository instructions require visual changes to be inspected in the rendered artifact.

Rules for overlap, clipping, margins, and text fit turn named defects into machine-checkable failures. They cannot establish whether a slide communicates well. Rendered inspection and editorial judgment remain separate acceptance steps.

This gives the case its validation lesson: inspect what the author and audience will consume. A successful source build leaves the quality of the presentation unresolved.

Capability breadth arrived before a stable first use#

The first month covered structured slide specifications, multiple model providers, outline and theme generation, variants, deck restructuring, media workflows, presentation mode, PDF and PowerPoint export, an Electron wrapper, and cloud hosting.

These capabilities pursued one broad vision while testing many product assumptions at once. Repeated use had not yet shown which workflow deserved priority. The roadmap subsequently made real studio usage the source of future work, after a large solution surface already existed.

The harness grew with that surface: fixtures, baselines, validators, build paths, and agent instructions all needed maintenance. Making the checks more precise could improve an implementation without resolving whether its workflow was worth expanding.

Packaging and hosting multiplied the system boundaries#

Local filesystem use, a command-line package, a browser studio, a macOS wrapper, and a cloud deployment each introduce different storage, authentication, rendering, and release requirements. Supporting them together broadened the operating model before one delivery path had settled.

At the reviewed point, the cloud setup guide identified production workspace authentication, real queued generation and export, and Durable Object serialization as incomplete. The Electron path also needed production packaging work. A functioning authoring workflow and a dependable delivery path required different evidence.

What transferred to Kirjolab#

Canonical artifacts, explicit approval, rendered validation, and preserved decisions carried into later work. Kirjolab examines the subsequent architectural problem: behavioral checks made correction possible while responsibility boundaries lagged behind feature growth.

Slideotter's distinctive unresolved question was product fit. Its rendering controls could be reused, but they did not identify the smallest presentation workflow worth operating.

What I would do differently#

I would begin with the local browser studio and use real decks to establish one complete authoring loop before adding desktop or cloud delivery. With the shared knowledge-base boundary described in the Kirjolab case, Slideotter would own presentation metadata, outline variants, slide definitions, themes, and approval state while referencing reusable source material.

The first product loop would be:

Select or amend the source material and define the audience, purpose, duration, language, and theme.
Develop outline variants that reuse the base metadata, then approve one before expanding it.
Generate and review the slides, including their layout and rendered output.
Bind approval to a reviewed version; later changes produce a new candidate.

Time to an approved deck, corrections, outline revisions, regeneration, and repeated use would test product value separately from repository checks. Keep the harness focused on provenance, approval state, slide validity, and rendering. New delivery targets should follow evidence that this loop is useful.

What Slideotter teaches#

Slideotter established useful controls for generating and inspecting presentations. Its next product decision needed evidence from repeated authoring and use. Artifact correctness and product convergence require different feedback, even when the same agents help implement both.