Skip to content
Creaitercreate your vision with ai
Sign inRegister
All example projects

Web app

Shift notes

Log shifts and see your own week at a glance

A web app that lets you log a shift in under ten seconds and see the coming week at a glance.

Worked teaching examples: these three projects were written for the course along the documented seven-day rules. They are not real user projects, there is no running app, no live link and no store listing. The evidence here is the decisions, not a screenshot.

What it was built for

People who work shifts usually keep the plan as a photo on their phone or on a piece of paper. The question "am I working Saturday?" then costs a search every single time. The app answers exactly that one question fast — it does not replace an employer's roster.

The core loop in four steps

  1. 1Open — the current week is right there
  2. 2Log a shift — day, start, end
  3. 3See the week — what is coming, how many hours
  4. 4Plan the next week — page forward and log

Deliberately left out

Shrinking the scope is the real work of day 1. These points would have made the project bigger without making the core loop better.

  • No team or department roster — as soon as several people see the same plan you need accounts, permissions and conflict resolution. That is a different product.
  • No calendar or PDF export — useful, but it does not make "am I working Saturday?" faster to answer.
  • No pay or bonus calculation — it depends on collective agreement, country and contract. Calculated wrongly is worse than not calculated at all.
  • No reminders or notifications — they require permissions and a running service and do not belong in a first version.
  • No account and no sync — the data stays in the browser. That rules out switching devices and was the deliberate price for seven days.

Release goal

Publicly reachable web app on its own address. No store, no installation, no account.

The seven build days

For each day you see separately what was visible afterwards and what decision sat behind it. Where something did not work at first, that is here too.

  1. 1Day 1 — Your scope is set

    What was built
    A one-page spec: target user, the core problem in one sentence, the core loop in four steps, five non-goals and the release goal "publicly reachable web app".
    Why this way
    The web app was deliberately chosen as the release goal instead of the app store. That puts the entire route to publication in your own hands — no account check, no review, no waiting window. For a seven-day result that is the difference between "done" and "submitted and now waiting".

  2. 2Day 2 — A real build runs

    What was built
    A running project with two views — week and logging — and navigation reachable with a thumb. The data lives locally in the browser.
    Why this way
    Local browser storage was used instead of a database. It is the decision with the largest time saving in the whole project: no server, no account, no sign-in, no data protection questions about stored personal data. The price is written down as a non-goal.

  3. 3Day 3 — Your core loop works

    What was built
    The complete flow: log a shift, it appears in the week, the weekly hours update, the next week is reachable.
    Why this way
    The week view came before the logging form. Build the form first and you test against an empty surface, noticing only late whether the display holds up at all.
    What did not work at first
    The first test data was "shift 1" to "shift 5", all eight hours long. The week looked perfect. With real data — a split shift, a night shift crossing midnight — the display broke immediately. The night shift across midnight then became an explicit test case.

  4. 4Day 4 — Your app survives bad days too

    What was built
    Four states: empty week with a way in, invalid input with a reason, a return after weeks that lands on the current week, and checked text scaling.
    Why this way
    The empty state got the most text in the whole project. It is the first screen every new user sees — saving effort there means saving effort at the one place everybody sees.
    What did not work at first
    Returning initially landed on the last viewed week. Anyone who did not open the app for four weeks saw an old week and took it for the current one. Jumping to the running week was the fix.

  5. 5Day 5 — Operations, legal and cost limits are set

    What was built
    Privacy policy, imprint and a support address. One line in the app explains that the data never leaves the browser.
    Why this way
    There is no paid path and therefore no cost limit. That was written down explicitly rather than simply omitted — "no external costs" is a result of the architecture, not a forgotten task. Skip the note and in four weeks you go hunting for the missing limit.

  6. 6Day 6 — A real release candidate

    What was built
    A publishable state, tested in two browsers and on a real phone, not only in a narrowed desktop window.
    Why this way
    Testing on real hardware was carried out even for a web app. A narrow desktop window has no on-screen keyboard covering half the surface — which is exactly where the logging form failed on the first real attempt.

  7. 7Day 7 — Your decision is documented

    What was built
    A record with every release gate and a yes or no behind it, plus a V1.1 list with four items.
    Why this way
    It shipped. The deciding factor was not completeness but that the core loop ran through fully on real hardware with no data loss. The missing calendar export is the first item on the V1.1 list — with the sentence explaining why it did not belong in V1.

Take it and remix it

The remix takes the idea, core loop, non-goals and release goal as your starting point — not the solution. The seven build days stay identical; you skip no step and no check.

Prompt for your AI tool

If you would rather start right away instead of going through the path: this prompt describes the project completely enough for an AI tool to begin.

I am building a small web app: Shift notes — log shifts and see my own week at a glance.

Core loop in four steps:
1. Open — the current week is right there
2. Log a shift — day, start, end
3. See the week — what is coming, how many hours
4. Plan the next week

Explicitly NOT in version 1: team/department roster, calendar or PDF export, pay and bonus calculation, reminders, account and sync.

Release goal: publicly reachable web app, data stays locally in the browser.

Help me get started:
1. Ask me about anything you need to know for the first step.
2. Propose the smallest data structure that carries this core loop.
3. Name the three test cases most likely to break this app.

Do not change the scope without asking me.