Overengineered hobbies.
Shipped.

Finished is the hard part.

Every product on this page — including this website — I built end to end by directing LLMs. I decide what's worth building at all, what earns a place in v1 and what defers, and what it runs on; the models write the first cut, then we prune and polish until v1 is genuinely finished — and I take it through store review and everything after. One person, full product lifecycle. The judgment is the job.

5Products owned end to end

1Live on Google Play

2In store review

ANIMESH SARKAR

overengineeredhobbies@gmail.com

01 — The work REV B

SHIPPED & SHIPPING

Production applications taken all the way through packaging, signing and store submission.

BUILD 01

PELLUCID

macOS · Windows · iOS In review

A distraction-free writing environment whose interface fades out of the writer's way — and syncs their manuscript without ever holding it hostage.

Pellucid — editor — 6 SHOTS — CLICK TO ENLARGE

Pellucid — research notes — 6 SHOTS — CLICK TO ENLARGE

Problem: Writing apps interrupt flow with chrome, and cloud sync usually means surrendering your files to a proprietary store.
Approach: A translucent “Whisper UI” that recedes while typing, over plain Markdown on disk. Versioned Google Drive sync using only the drive.file scope — the app can touch nothing it didn't create.
Outcome: Submitted to the Mac App Store; iOS and iPad builds green with keyboard-first interaction and OAuth via ASWebAuthenticationSession.

BUILD 02

KALKRA

macOS · iOS · Windows In review

A mental-arithmetic trainer that reads how fast you actually solve, and re-tunes its difficulty in real time.

Kalkra — gameplay — 6 SHOTS — CLICK TO ENLARGE

Kalkra — dashboard — 6 SHOTS — CLICK TO ENLARGE

Problem: Fixed-difficulty drill apps are either boring or discouraging, because they never learn the player's actual ceiling.
Approach: A calibration engine that measures solve latency per operation type and adjusts live. Fully offline and single-player — no accounts, no network, no telemetry in store builds.
Outcome: Submitted to both the Mac and iOS App Stores, with a truthful “Data Not Collected” privacy declaration on every storefront.

BUILD 03

GASTROTATOR

Android Live on Google Play

Turns a twelve-minute cooking video into a structured, editable recipe with nutritional estimates — the most technically involved thing here, and the one you can install right now.

Gastrotator — recipe detail — 5 SHOTS — CLICK TO ENLARGE

Gastrotator — library — 5 SHOTS — CLICK TO ENLARGE

Problem: The recipe in a cooking video is buried in twelve minutes of talking, in no fixed order, with quantities stated casually or not at all. Transcribing one by hand costs more than cooking from it.
Approach: A pipeline: pull the transcript, have Gemini extract ingredients, quantities and ordered steps, normalise units to SI, then estimate calories and weights. The hard part isn't the model call — it's forcing non-deterministic output into a schema stable enough to store, edit and trust.
Outcome: Shipped and live on Google Play. Less visually polished than the other two; considerably more complex underneath.

BUILD 04

AULOS

Windows · macOS Research — not for stores

The bedrock. At ~44,000 lines it is very nearly as much code as all three shipped apps combined — and the reason they were quick to build.

Problem: Music, podcasts and audiobooks each want different controls, different resume behaviour and a different sense of progress — yet players usually force one model onto all three. Separately: I needed somewhere to work out architecture properly, without a release date attached.
Approach: A pure-Dart domain layer with the data layer behind it, and strategy-pattern playback so the UI reconfigures itself per media type rather than branching everywhere. Native thread-safety guarding for Windows, and async disposal protection throughout.
Outcome: Deliberately never submitted anywhere. The layering, playback abstraction and resilience patterns proven here are reused across the store apps — they ship fast because this one didn't have to.

BUILD 05

OVERENGINEEREDHOBBIES.DEV

Web Live — you're in it

This page. A portfolio that is itself a build — generated from a database, no frameworks, deployed to the edge.

The Work, drafting-paper theme — THIS PAGE, THREE THEMES — CLICK TO ENLARGE

The Method, blueprint theme — THIS PAGE, THREE THEMES — CLICK TO ENLARGE

Problem: A portfolio that lists projects flatly says nothing about judgment — and hand-maintained project pages rot the moment the work moves on.
Approach: Project data lives in SQLite; Python templates generate the static pages. No framework, no build chain, no client-side rendering. Theming is CSS custom properties, so a new palette is fifteen lines.
Outcome: Live on Cloudflare. The smallest build here by far — included because the structure of this page is itself the argument.

02 — Method REV B

HOW A PRODUCT GETS BUILT

The same seven stages every time, across three products. AI does most of the typing; the decisions are mine.

Principle
01

Software is measured by how well it performs, not how beautifully it was written. Process is earned, not default. Components everything else depends on carry five-stage quality gates and self-updating indexes; the ones that quietly do their job carry almost nothing — until they have to. Rigour applied before a thing has justified its existence is just cost.

Principle
02

Why we are building it — and what it has to do — is settled before a single line of code is written. Four of the seven stages happen before implementation begins. The two where AI writes the most are the two that need the tightest direction, which is why judgment concentrates exactly where no tool can help.

DECIDE STAGES 01–04 · NO CODE YET

Where a product is won or lost. Everything after this is execution.

Is it worth building at allAI: none

The kill decision. Most ideas do not survive it, and the ones that don't survive save the most time.

In practice Gastrotator v2 is designed but unbuilt. The features that would justify it depend on on-device intelligence, and that has not reached the market penetration to make building it worthwhile yet. Not cancelled — waiting on a condition outside my control.

ToolingNo tooling — this stage is thinkingLLMs used as a very fast, very wide search engine. Nothing to automate: the output is a yes or a no.

What the product actually isAI: sounding board

Deciding the shape — and cutting whole feature areas when they stop serving the product.

In practice Pellucid began as two apps in one, with GitHub in between as a black box: an author and an editor working on the same project, the editor raising feedback the author would pick up. The editor view was cut: I have no real insight into what an editor needs, and guessing would have produced a worse tool than none at all. GitHub became Google Drive, because durability mattered less than the destination being somewhere the intended user already understands.

ToolingSkill for architecture and feature discoverySTAGES 02–03One pass that defines what the product is, what it must run on, and what there is to prioritise — so stages 02 and 03 share a single source of understanding. Undergoing polishing and pruning before it gets its public repo.

What it runs onAI: research

Architecture follows the product, never the reverse. The stack is chosen to satisfy what stage 02 defined — reach, compliance limits, and what the intended users already understand — not the other way round.

In practice Every app is Flutter, because every app is meant to be multiplatform — and the playable demos on this site are those same builds compiled for web, so showing them cost no rewrite. This site is not Flutter: a static page gains nothing from it. The tooling splits the same way, by purpose rather than preference — Python where it parses code and drives files, JavaScript where the ecosystem is the better fit. And some tooling is not a program at all: where the job is to direct an agent rather than run a process, it ships as a Skill instead.

ToolingSkill for architecture and feature discoverySTAGES 02–03The same discovery pass surfaces the platform and compliance constraints the stack has to satisfy. Judgment still makes the call; prior lessons come from the memory layer below.

What earns v1, what gets deferredAI: sounding board

A release train rather than a wish list: each version gets a coherent story, and everything else waits its turn.

In practice

Kalkra: multiplayer was built, then cut from v1. It stays out until there is evidence anyone wants it.
Gastrotator: bring-your-own Gemini key was a late addition to v1, added precisely so the hobby project could be shared with other people. It is not a service I want to be paid for, and carrying inference costs for everyone would have made it one.
Pellucid: desktop first, iPad second, two-way sync in 1.2, iCloud in 1.3. Deferred deliberately, not forgotten.
Aulos: the inverse. It never reaches v1 on purpose. Staying a living codebase is the point, because that is what the framework has to be proven against.

ToolingConcinnityIdeas captured into lanes, then ranked head-to-head on an Elo model. Every comparison is stored with rationale and before/after ratings and published as an immutable ranking run, so a scope decision can be replayed months later instead of re-argued. Pending: the discovery pass from stages 02–03 should record its output straight into Concinnity — that hand-off is not built yet.

BUILD STAGES 05–06 · AI DOES THE TYPING

Speed first, then judgment. The two stages are deliberately opposite in temperament.

Let AI runAI: lead

Everything above exists to make this stage possible. Stages 01 to 04 do not produce a document; they produce an executable brief — a sequenced plan, scoped so agents can be handed disjoint pieces, every feature carrying both its objective and the reason it exists, against an architecture already decided. Given that, the agent can genuinely be let loose.

In practice For anything headed to a storefront, the stage starts before the code: the gates go up first — static analysis, a size ratchet, structural rules, hermetic tests, coverage — so test-driven development is enforced deterministically from the first token, rather than depending on an agent choosing to be disciplined. Small experiments skip this entirely; process is earned, not default.

Work then fans out rather than queues: a lead model decomposing the brief and dispatching each piece to the cheapest model that can carry it, or a provider's swarm mode where one exists. File-level fences keep parallel agents off each other's work.

This is the only stage I am genuinely hands-off for — my involvement is granting permissions. What comes back is not snippets or a scaffold but one working codebase. With the gates in place it cannot arrive any other way — running is not a hope, it is the precondition of getting through. Which makes it complete enough to argue with. That is precisely what stage 06 needs. You cannot give specific, directed feedback on something you have only imagined.

This is the stage where the model earns its keep.

Tooling

KarstAgents get a knowledge graph instead of grep: tree-sitter parsing into SQLite, hybrid semantic and lexical search, kept current by a pre-commit hook that re-indexes changed files.

LoreHands the agent lessons already paid for elsewhere, so a mistake made once in one project is not made again in another.

ContextHistorySupplies the accumulated project context, so a fresh agent session begins with the history rather than re-deriving it from the code.

Prune and polish, togetherAI: pair

The longest stage, and the one that cannot be delegated. The gates guarantee the code runs; nothing guarantees it is worth using. This is where the product acquires the quality that justified building it — the part no brief can specify, no test can assert, and an agent has no way to know is missing, because everything it was asked for is present and working.

In practice Pellucid looked like Notepad until this stage. Every widget was in place and everything worked — a text box with a crowd of controls around it. But the entire premise of the app was to get out of the writer's way, and none of that existed yet. The Whisper UI — chrome that recedes as you type and returns when you reach for it — was built here, in the pass after the code already ran.

Stage 05 produced a text editor. Stage 06 produced Pellucid.

The same pass cuts what the first cut over-built. Agents are generous with abstraction and features; most of what gets removed here was never asked for. And it is where defects surface that no gate catches — the ones visible only in how the thing behaves, not in whether it passes.

This page is in that pass now. Stage 05 produced a structure that worked; everything since has been deciding what stays, what gets added, what is cut, and how it should look — sections collapsed into tabs, single screenshots replaced by piles you can fan out, examples swapped for better ones, whole paragraphs deleted for saying too little. You are reading the output of the stage you are reading about.

Tooling

KarstThe same graph makes pruning safe — dependents and dependencies resolve in milliseconds, and a background scanner flags dangerous patterns as they land.

LoreThe direction reverses: what this pass teaches gets written back, so the next project inherits the finding instead of paying for it again.

ContextHistoryRecords what changed and why, so the reasoning behind a decision outlives the session it was made in.

SHIP STAGE 07 · AND EVERYTHING AFTER

The stage most side projects never reach, and the one that decides whether any of it counted.

Submission, review, and beyondAI: assistant

A storefront wants far more than a binary. Screenshots at exact per-device sizes for every form factor, an icon set, a name, subtitle, description, keywords and release notes each under a different character limit; privacy, support and marketing URLs; a data-collection declaration answered item by item; an age-rating questionnaire; export-compliance answers — on top of signing, entitlements and sandboxing being exactly right. Miss any one of them and nothing ships.

In practice Almost none of it is invented at submission time. The reasoning from stages 01 and 02 becomes the description and the release notes. The scope decisions from 03 and 04 are what make the privacy declaration truthful rather than hopeful — Kalkra can answer “Data Not Collected” because multiplayer and telemetry were cut, not because the form was filled in optimistically. The tooling then checks that everything the target store requires is present, and in the shape that store wants, before anything is uploaded.

Then the review itself, which is a negotiation as much as a checklist. An automated scan once flagged an entitlement as unused. It wasn't — I answered with evidence rather than rebuilding, which kept the release date instead of restarting the clock.

Toolingstore-launch-kitThe checklist made executable — a deterministic answer to whether every asset a given storefront demands actually exists, at the right dimensions and within the right limits. Built because assembling one submission by hand cost weeks.

Orchestration

The one layer that belongs to no single stage, because it runs the rest.

MCEPTION

The service manager the rest plug into. Discovers servers from a directory contract, validates their manifests, probes health and starts/stops them — across three lifecycle shapes (command-per-client, daemon, external) over stdio or streamable HTTP, behind a single meta MCP endpoint with a manager API and a local dashboard. It also serves authoring guidelines to agents writing new servers, so the next one is consistent by construction. The hard rule: every child server stays independently usable, never rewritten behind a proxy.

02.1 — Components REV B

WHERE THE PARTS LIVE

None of these was built first and then found a use. Each one exists because a stage asked for something the stage before it couldn't supply — the method came first, and the parts accumulated behind it. What each does is described at the stage it serves, above; this is the shape they make together.

The memory layer runs in both directions. Lore and ContextHistory feed a fresh agent session in 05, then take back what the prune-and-polish pass in 06 teaches, so the next project starts further along than this one did.

Component	Stages	Built because
Discovery Skill	02–03	Product shape and stack were being decided twice, from two different understandings	Not released — in polishing
Concinnity	04	A scope decision that isn't recorded gets re-argued three months later	repo →
Karst	05–06	Agents were reading a codebase with grep	repo →
Lore	05–06	The same mistake was being paid for in a second project	repo →
ContextHistory	05–06	Every new session re-derived the project's history from the code	repo →
store-launch-kit	07	Assembling one submission by hand cost weeks	Private
MCePtion	all	Six tools, six lifecycles, no single way to run them	repo →

Overengineered hobbies.Shipped.