Duck CEO

Duck CEO is finally a small, complete product. It has one page, one boss, and one career. You clock in, the duck assigns you work, and you either complete it or disappoint him while he keeps score. The final build includes a task pool that mixes useful and ridiculous assignments, individual deadlines for each task, a patience system with moods ranging from Pleased to Terminated, a performance log, persistent progress through local storage, and a firing screen complete with a humiliating rehire button. I also kept the visual language consistent with the printed office memo aesthetic and the repository small enough to understand, build, and run without unnecessary complexity. The real goal was never to build another productivity suite. It was to make a simple system where the player actually feels judged by a fictional duck. The timers, mood changes, performance log, animations, and termination screen all exist to make that feeling stronger. If someone finishes the game feeling slightly guilty for disappointing a mallard, then the systems have done their job. For now, the duck is monitoring output, the pond is outside, and your employment is entirely dependent on whether you do what you were told.

Devlog 9: Keeping the Game Small on PurposeSince Duck CEO is intentionally a small, focused game, I wanted the codebase to reflect that same philosophy. The project only really needs a handful of surfaces: the boss panel, assignment cards, performance log, fired notice, and the controls that connect everything together. Adding more components, packages, and styling would not make the duck any funnier. It would only make the project harder to understand, slower to install, and more difficult to maintain. This phase became an exercise in subtraction. I replaced the idea of using a large component library with a single reusable Button primitive and kept dependencies limited to what the application actually needs, including React, TanStack, Tailwind, and a few small utility packages. I also reorganized the file structure around the actual game, with files for the duck, routes, styles, and portrait instead of a collection of generic or unused components. Keeping the CSS focused was another priority so the visual style could remain lightweight while still maintaining the printed office memo aesthetic. The goal was not minimalism just for the sake of having fewer files. It was about ownership and making the project easy for someone else to understand. If a stranger opens the repository, they should be able to immediately find the parts that make Duck CEO work. After removing the unnecessary pieces, everything important still worked exactly as before. Patience still drops, tasks still expire, the duck still judges you, and the ridiculous tasks still get their appropriate deadlines. That was the proof that the extra complexity was never carrying the experience. The duck was.

Once the core loop, boss system, and deadlines were working, the next step was giving the project a clear identity. I wanted Duck CEO to feel like a real website that someone could open, share, and take seriously for at least five seconds before realizing that their manager is a mallard. This meant treating every part of the interface as part of the experience rather than leaving behind generic framework or template content.
I updated the page title and description so everything consistently identifies the project as Duck CEO. I also rewrote the Open Graph information so that when the site is shared, the preview immediately communicates the idea of a tiny productivity game where a disappointed duck keeps score. The README was rewritten to explain what the project is, how to run it, and how to build it, while the header, footer, 404 page, and error states were all given the same dry sense of humor. Even small details, such as the footer disclaimer that “This duck is not a licensed manager,” help make the world feel consistent.
This was also the stage where the project became much closer to something I could actually ship. The application can be run locally with npm run dev and built for production with npm run build and npm start. The technical stack provides the delivery system, but the product itself is still Duck CEO. My final test was simple: close the editor, open the browser, and ask whether it looks like Duck CEO or just a prototype that happens to contain a duck. After this pass, it finally felt like the former.

Playtesting revealed an important problem with the original timing system: every task was given roughly the same 45-second deadline. While this seemed simple at first, it quickly became clear that different tasks required very different amounts of time. A task like “Put your phone face down” could easily be completed within that window, while something like “Eat something that isn’t beige” could require much more time. When the timing became impossible rather than challenging, the humor started to feel frustrating instead of funny. The duck could be demanding, but he still needed to give the player a reasonable chance to succeed. To fix this, I changed tasks from simple strings into individual definitions with their own lifetimes. Quick obedience tasks receive around 30-45 seconds, desk-sized tasks receive around 60-75 seconds, tasks that require leaving the desk get around 90 seconds, and tasks that require actually going somewhere or doing something more involved can receive up to three minutes. When a task is issued, its deadline is now calculated using its specific lifetime rather than relying on one universal timer. I also updated the progress bar so that it uses each task’s total duration, making the level of urgency accurate regardless of how long the task has to be completed. This ended up being one of the most important design improvements in the project. The underlying pressure system stayed exactly the same, but the pacing became much more natural. The player can still feel the constant pressure of having a demanding boss without feeling like they are being set up to fail. It was a good reminder that even a deliberately unfair character needs fair rules underneath the joke, the duck can be unreasonable, but the game itself shouldn’t be.

After the core structure and mechanics were working, I shifted my attention toward how the application actually feels when the duck is judging the player. I wanted the visual style to reinforce the workplace satire rather than look like a typical productivity application. I settled on a visual language built around paper textures, ink-like elements, monochrome labels, bold display headlines, and duck-yellow accents. Instead of the soft colors and polished appearance often associated with modern productivity apps, I wanted it to feel like a printed office memo that had somehow become interactive. I also gave animations a very specific purpose rather than adding motion everywhere. The duck waddles when he is idle to make him feel alive, shakes when the player ignores work to show frustration, and uses a slam-in animation when new paperwork arrives on the desk. These three animations were enough to give the interface personality without making it feel like a toy. I also added more aggressive visual styling to urgent tasks when their deadlines get close, allowing the interface to communicate increasing pressure through color and countdowns without needing additional instructions. Overall, this phase was about making the satire immediately understandable. Every visual decision needed to support the idea that the player is sitting at a desk while being watched by an increasingly impatient boss. The goal was that someone could open the application for only a few seconds and immediately understand the relationship: the duck is in charge, paperwork is coming, and ignoring it is probably a bad idea.

At this stage of development, I wanted to make the boss feel like an actual character rather than just a system that tracks tasks. A timer or task list can tell you what needs to be done, but a boss needs a face, a personality, and a way to react to your performance. I started by making the duck the visual centerpiece of the executive panel, giving him a suit and an animated idle waddle so he still feels alive even when nothing is happening. I also added a shake animation whenever work is ignored, making the boss’s reactions much more immediate.   I then connected the duck’s mood directly to the user’s patience level. As patience decreases, his titles change from Pleased and Neutral to Concerned, Disappointed, Final Warning, and eventually Terminated. I also added DONE and IGNORED counters along with a patience bar that becomes increasingly threatening as trust disappears. These elements turn what could have been simple statistics into visible signs of how the player’s relationship with the boss is changing. Finally, I redesigned the surrounding interface to feel less like a traditional productivity dashboard and more like an internal workplace memo. Assignments are presented like work slips, while the performance record reads like an increasingly concerning employee file. If the player is eventually fired, the termination screen includes an ignored-task roast, formal firing language, and an embarrassing option to reapply for the job. These changes helped establish the central joke of the project: completing tasks is no longer just about checking boxes. The duck is watching, judging, and remembering.

One of the most important improvements I made during this stage of development was adding persistence. At first, saving data seemed like a simple technical requirement, but I quickly realized it was actually a major part of the experience. Without persistence, the application would feel like a temporary demo where users could simply refresh the page to escape their consequences. By saving progress, the world feels more continuous and the user’s actions actually matter.
The implementation itself was straightforward: application state is serialized whenever changes occur, stored locally in the browser, and restored whenever the user returns. If the stored data becomes corrupted or unavailable, the system safely falls back to creating a fresh profile instead of breaking. This approach keeps the experience reliable while allowing the user’s career, patience, and ignored tasks to continue across sessions.
Adding persistence also pushed me to rethink the structure of my data. I needed the state to be simple, predictable, and easy to save and restore. If a piece of data was difficult to serialize, it was usually a sign that the architecture was becoming unnecessarily complicated. The final design keeps the underlying systems clean and lets the personality of the project come from the writing, reactions, and interactions rather than overly complex code. The result is an experience that feels less like a small browser project and more like a job the user has accidentally committed to.

After establishing the foundation of the project, I focused on creating the core loop that makes the fantasy actually work. The goal was to build a simple but effective system where every action has a consequence. On each tick, open tasks slowly move closer to their deadlines, expired tasks reduce patience, increase the ignored task count, and add disappointment messages to the activity log. Completing tasks has the opposite effect by restoring some patience and creating positive feedback through praise messages.
One of the biggest design decisions was keeping the mechanics intentionally minimal. It would have been easy to add features like streaks, levels, rewards, or cosmetics, but those additions would have distracted from the main idea. The humor comes from the simple cycle of receiving work, deciding how to handle it, and being judged by the system. I also added limits to task generation so new tasks appear at a controlled pace instead of overwhelming the user with endless responsibilities.
I also had to solve the challenge of maintaining progress between sessions. Since data is stored in the browser, the application needed to properly load saved state without creating conflicts between server rendering and client-side data. I added a loading state before hydration so the user’s progress could load smoothly and the experience could continue across refreshes. This process showed me that a strong experience does not always require complex mechanics, the most important part is making sure every system supports the intended feeling. If the loop creates a small amount of funny stress and makes the user want to respond, then the design is working.

Once the writing felt solid, I translated the joke into state.

The whole game lives in one object: patience, completed, ignored, open tasks, a performance log, last issue time, fired flag, start time. That object is your career. Completing a task is not “checking a box” it is surviving another review cycle. Ignoring one is not missing a reminder, it is giving the duck evidence.

Early rules I wrote down before coding:

Pressure should accumulate slowly, not spike randomly
Success should feel cold, not celebratory
Failure should feel administrative, not dramatic
Getting fired should be inevitable if you treat it like a joke

This phase was systems design disguised as comedy. Patience is the health bar. Tasks are tickets. The log is your permanent record. The duck is not a mascot. He is the win/lose condition.

Duck CEO did not start as a framework decision. It started as a sentence: you work for a duck, and the duck is keeping score.

I wanted a productivity game that felt like corporate satire, not a joke app with emoji and badges. The duck had to sound like middle management: understated, judgmental, slightly bureaucratic. If the writing failed, the timers and UI would not save it.

So phase one was content only:

Assignment copy that sits between self-care and absurdity (“Drink water.” / “Eat something that isn’t beige.” / “Do not think about the duck.”)

Praise that barely approves you (“Acceptable.” / “You may keep your desk.”)

Disappointment that escalates without yelling (“The duck says nothing. That’s worse.” / “The duck has scheduled a meeting. No agenda.”)

This log is about locking tone before mechanics. The game is basically a delivery system for that voice. Get the voice wrong and you have a fancy todo list. Get it right and a mallard in a suit feels like HR.