Rungset

Long-term work falls apart in a familiar way. The outcome is written down in one place, the checkpoints live in another, the tasks that would actually move the work forward are somewhere else, and the weekly review never makes it back to the plan. The next action becomes detached from the reason the work exists.

A notes app can hold the thinking. A task list can hold the actions. Neither keeps the hierarchy visible at the same time: the goal that sets direction, the milestones that mark progress, the tasks that make the work concrete, and a check-in that records what changed. Without that loop, planning and doing drift apart, and the review has nothing reliable to return to.

The product also had to be an account, not a browser tab. Goals, milestones, tasks, notes, and check-ins needed to persist for the signed-in person, stay out of other people's workspaces, and remain available from the hosted app whether it was opened in a browser or from Android.

The working rhythm is goal, milestone, task, completion, check-in, review, and adjustment. Each record has a job, and the relationships between them are part of the product rather than a loose tagging convention.

A goal holds the outcome: a title, category, status, progress, timeframe, and an optional due date. Milestones belong to one goal and mark the checkpoints along the way. Tasks are the actionable work. A task has a title and a priority, and it can carry a due date, a category, recurrence, reminder settings, and a completion history. If a task points at a goal or a milestone, both have to belong to the signed-in user, and the milestone has to belong to that goal.

Notes are Markdown. They can be categorized and pinned so context stays next to the work it supports. A check-in records a date, mood, energy, accomplishments, challenges, the goals it relates to, and optional notes. The dashboard summarizes goal and category progress. Settings cover a JSON export of the workspace and a reset of workspace data.

That is the loop the beta is willing to support. An analytics dashboard, calendar sync with Google, Outlook, or Apple, an iOS app, AI recommendations, note attachments, sharing, collaboration, and external reminder delivery are not shipping features. Reminder settings in the app currently guide due and overdue work inside the product. They are not a scheduled notification service.

I kept one product surface. The Next.js application is the interface, the API, and the place where authorization happens. The marketing site can change its explanation of the product without being tied to the authenticated workspace. Android does not reimplement goals, tasks, offline caching, or sync.

The Android project is intentionally small. It packages the hosted progressive web app as a Trusted Web Activity. It provides the launcher, splash and icons, deep-link handling, browser fallback, and the Play Store build. Application id com.rungset.app launches https://app.rungset.com/. Until the site's Digital Asset Links statement matches the installed signing certificate, the app falls back to a Custom Tab instead of pretending the verification succeeded.

The beta stays narrow on purpose. A weekly planning loop that a person can actually use was more important than presenting calendar sync, analytics, or an iOS client as if they were already part of the product. The docs list both the current features and the capabilities that are not available yet, and the case study uses that same boundary.

The app is a Next.js App Router application in TypeScript, deployed to Cloudflare Workers through OpenNext. Drizzle ORM maps the workspace onto Cloudflare D1. Better Auth owns the session, email and password sign-in, and Google or GitHub sign-in when those providers are configured. Authentication routes live under /api/auth. Workspace routes live under /api.

Those workspace routes are the application's JSON boundary, not a versioned public API. Every workspace read and write requires a session. The server derives the user from that session. A user id supplied by the client is ignored for ownership, so a request cannot ask the API to read or change someone else's goals, milestones, tasks, notes, or check-ins. Related writes are checked the same way: a milestone must belong to the current user and to the goal it is attached to.

Dates that are date-only use YYYY-MM-DD. Write bodies are limited to 2 MB and validated at the route. Errors return a short JSON message, with details when validation fails. The statuses in use are 400 for an invalid request, 401 when no one is signed in, 404 when a record is missing or not accessible, 413 when the payload is too large, and 500 for an unexpected server failure.

The client keeps an offline cache and synchronizes changes through those authenticated routes. D1 remains the authority for the hosted workspace, which is also what the Android app uses. Export is one download of the signed-in user's workspace: profile, goals, milestones, tasks, task occurrences, notes, and check-ins. Schema changes are forward-only migrations, applied to D1 with Wrangler.

The public site is a separate Next.js application. It describes the current product and points to the app, the documentation, the source, and Google Play. It does not share the app's session or database.

The interesting choices were about keeping one workspace honest: in the database, at the API, offline, on Android, and in what the beta refuses to claim.

The beta includes goals, milestones, tasks, Markdown notes, check-ins, a dashboard of goal and category progress, email and social sign-in, JSON export, workspace reset, an offline cache, self-hosting, and the Android wrapper around the hosted app.

It does not include an analytics product, external calendar sync, an iOS app, AI recommendations, collaborative editing, note attachments, or a service that delivers reminders outside the app. Those items stay out of the interface, the docs, and this case study until they exist. The marketing site says the same thing, so the public description and the software do not diverge.

Rungset is a web-first product with a hosted beta, a public site, documentation of the current behavior, and a Google Play app that uses the hosted workspace. The source is available under AGPLv3, with forward-only D1 migrations, a JSON export, and a local setup path.

The repository is checked with lint, typechecking, application tests, migration checks, and Playwright end-to-end tests. A local build is evidence about the source. It is not, by itself, proof that a live deployment is healthy. Production still depends on the Worker, the D1 migrations, and the configured secrets.

What I can point to is the product boundary I wanted: one workspace for goals, milestones, tasks, notes, and weekly check-ins, available in the browser and on Android, with the data model, the API, and the public description all referring to the same thing.