Scrumble Project Retrospective (June–August 2025)

Opening

I left my last job in mid-April and spent about a month traveling Italy with Ellie. By the end of the trip I came home a little tired, but a few months later I find myself wishing we’d stayed two more weeks. It was the first long trip of my life taken after quitting a job, and since I wasn’t returning to a company anyway, maybe in some sense the trip never really ended. Or maybe I’d circled back to that moment five years ago, the one where Ellie and I were running my own business right up to the bitter end.

Setting that aside, if I wanted to start working for myself again, I needed to build something with my own hands. I’d been away from code for a long stretch, so I figured the right move was to pick a small project and use it as a re-entry point. That’s what I came home with: a plan to do one side project during the gap before the real business prep, and Ellie and I started in earnest at the end of May.

I’m splitting this retro into two parts: a general project retro (this one) and a tech retro covering full-stack development and working with an LLM (next one).

What Scrumble Was Trying to Be

Scrumble grew out of the daily-scrum meetings I’d been running since my Todait days and at every company after that. I’d actually wanted to build it last year while still employed. At that company we used Confluence for our daily meeting notes, and as the team grew and split, the format got painful in specific ways:

• Whoever wrote, kept writing. Whoever didn’t, never did.
• Past entries were almost impossible to scan. (Confluence supports a DataTable, but the UX is rough; it feels like typing values into a database or a spreadsheet.)
• We had over 30 people stuffed into a single note, and you couldn’t take any of it in at a glance.

The problem with that note, as I came to see it, wasn’t unique to Confluence. Whether the team is small or large, whether you’re using old-school Evernote, Dropbox Paper, Notion, or Confluence, the moment the note loses its tight connection to the actual work, its usefulness drops off a cliff. Eventually the casual condition-check and daily-life sharing stops working too, and the note’s role as a team communication channel withers.

For team members, the goal is to keep team communication alive without forcing constant coffee chats or meetings. But I felt that pure check-in scores or vibe scores weren’t enough on their own to justify the habit. So one of our targets was to make it easy to write the day’s work to-dos in the same place.

We weren’t trying to replace Slack-style chat tools or Jira/Asana-style PM tools. The product wasn’t positioned that way. The plan was to integrate with those tools as much as possible.

To restate the project goals:

• Main: build a daily-scrum service we’d actually use ourselves (MVP)
• Sub: give the team enough time to adapt and practice (work skills, collaboration) before the real development project

(The very first PRD draft)

Project Setup

Where We Worked

I trust systems more than enthusiasm, and environment more than talent. (That’s relative; I’m not saying talent and enthusiasm don’t matter.) When I take on any kind of work, I care a lot about making the work able to happen: getting every stakeholder’s economy aligned, keeping the cost and time low. Doing all of that from home created a different set of constraints, and I’m still figuring out how to handle them.

Most of the work happened at home.

Home

From a system-and-environment angle, home isn’t optimal. Our place doesn’t have a ton of rooms either. But Ellie still remembers the years of writing checks for several hundred thousand won every month for an office that sat mostly empty when we ran our previous company. So in cost terms, home was the obvious choice for now.

Two monitors and an M4 Max. The kind of place where you can also cook your own meals.

That said, after three months of working this way, I think we’ll need to lock in some revenue and get an actual office in the longer run.

Daily Life

It’s a side project, but a full-time side project, which meant the risk of staying inside the apartment all day. So we built a strict daily schedule. I started treating the gym trip with Ellie as our morning commute and built the work cycle around it. The first month, I mostly held to it. By the second month, as we entered the late stage of the project, the cycle broke and I was working at random hours. To make this concrete:

When the routine held: 10 p.m. bedtime, 5:30 a.m. wake-up, morning workout, then “into the office.” Almost a model life — if you can call it that. At the end of the project: 4 a.m. bedtime, noon wake-up, lunch, then starting work around 2 p.m. That kind of damage.

By the end, both of us were worn down enough that we took a workation just to wrap things up.

I barely worked from home during COVID, so I didn’t really know what working from home was like. I’m learning now, in my body.

Communication

It’s been just Ellie and me on side projects (even when I had a day job), but this time we also had a remote team member: George, a backend intern. And even with two people, you can’t keep all the records offline. Slack, Notion, Jira, Confluence, plus tools I’d used before like Linear and Asana. There are a lot of options.

We had to keep costs down, and small teams that touch a bit of everything end up locked into massive subscription stacks. I’d actually settled on Slack + Notion + Linear despite all that, until Ellie brought a super-app called ClickUp into the mix and we picked it.

ClickUp is, literally, Slack + Notion + Linear. Channel chat for communication, Markdown docs, project management: three categories of tool for the price of one SaaS subscription.

When I looked it up, it seems Koreans don’t really use it. Given how much Korean teams love all-in-one products, the lack of marketing here is honestly surprising.

After using it, you can see clearly that each of its three pieces is about 10% behind Slack, Notion, and Linear individually. But when those three pieces are integrated tightly inside one tool, the value adds up to a lot. We’ve been getting a lot of mileage out of it. Flip the framing and it’s kind of impressive: each function works at maybe 90% of the standalone, and anyone who’s built software knows how hard it is to make all of it actually function together.

Anyway, communication tooling: solved cleanly with ClickUp.

• $30/seat down to $10/seat
• Slack-style channel chat and Notion-style docs both supported well
  • The 10% gap I mentioned shows up only when you go deep on each one. Day to day, it’s fine.
• Project management gives you the intuitive subset of features you actually need

First MVP Feature Goals

The first MVP target was:

• Authentication
• Space management
• Check-in / check-out writing
• To-do list writing
• Feed page
• Real-time comments and reactions
• Real-time notification page

We pretty much hit those. But midway through, we decided this wasn’t enough and we needed to add more, and that decision cost us about a week.

• An MVP that should’ve shipped in 8 weeks ended up taking 12.

Looking back, the first feature set did get fully built, and the original goals of the project were roughly met:

• Main: build a daily-scrum service we’d actually use ourselves (MVP)
• Sub: give the team enough time to adapt and practice (work skills, collaboration) before the real development project

Of course, if you subtract the bad decisions, the dead-end detours, and the days I just didn’t work, you’d probably knock about three weeks off the total.

The detail comes in the retro below.

Retro

Keep

Daily Dog Fooding

Daily dog fooding will probably be a core principle in future projects too. Because we were building something we’d actually use, I wasn’t just trying to get it done; I kept thinking about how to make it better. At my last company, the makers couldn’t really be the users, which capped how far we could push that. Using the product every day surfaced everything from simple bugs to improvement ideas to the next pieces I needed to build. When you don’t have customers yet, dog fooding is the best instrument a maker has.

Hands-On From Scratch

I’ll go deeper in the tech retro, but: Golang (Fiber + Entgo) + Redis + PostgreSQL on the backend, Next.js on the frontend, full-stack, end to end, all by hand. I broke a sweat getting my hands back on the code I’d let go cold for years, but with $200/month and my friend Claude Code, I got to a place where I can do hands-on project development on my own.

Joy

It’s been hard to remember when, at my last company, I last felt joy in making something on a project. Set aside whether I use the product. I just enjoyed coding every day. From the time we adopted DDD at that company, I’d basically taken my hands off the code, but on this project I got to do everything I wanted, from initial DDD/Clean Architecture layer design to CQRS to event-driven patterns. Frontend isn’t my main turf, but tweaking styles one by one and watching the thing come together, I felt both the joy and the pain of that. It wasn’t quite Linus Torvalds’s Just for Fun, but rediscovering the joy of building something with my own hands, in this stretch, mattered a lot.

Mentoring

I love teaching, but back when I was wrestling with what good teaching even meant, I quit both the lecturing and the mentoring. That’s the hard part of education: not teaching, but teaching well. I wanted to help George keep going as a developer, and that’s why I brought him into the project. He’s still pretty much an entry-level backend developer, but he can now build a basic API on his own. There were moments along the way when I got short with him or showed how impatient I could be. Every time, my own bottom shows through and I’m embarrassed by it. But George stuck with this all the way through while holding a part-time job, and that effort is exactly why I wanted to teach him as much as I could.

Mentoring is still hard. Each person’s level is different, and what they need to hear is different. The thing is, dev skills and the rest are just tools. What trips most people up is how to work, how to work with others, how to talk about it. To get real S-tier (highest-caliber) teamwork, good mentoring is less about praising what was done well and more about pulling out the harder, less comfortable conversations.

Obviously, when I get emotional, I help nothing. People talk easily about how AI will replace teachers because AI is improving. But AI is a tool. To get a good answer, you need a good question. Beginners can’t ask good questions yet. They don’t yet have a high tolerance for failure. Helping someone surface those gaps and push past them is, for me as a mentor, genuinely hard work, and I want to keep studying it, including the playing-coach skills of running alongside them.

Problem

Lack of Communication

This is the biggest problem I felt running a duo project. Ellie’s direction as product designer and my direction as product manager (before I’m a developer) didn’t always line up, but even though we sat next to each other every day, we didn’t hold regular check-ins or talk enough. We were each so deep in our own deliverables that we’d sit in the same room for ten-plus hours without exchanging a word, me coding, Ellie designing. And because I could implement everything myself, I’d also just push small things through, or change the spec on my own judgment without enough back-and-forth before implementing. We did a real retro afterward and put a daily meeting on the calendar, but the biggest problem of running the Scrumble project was that we weren’t doing Scrumble.

Spec Creep

The first MVP was, frankly, the bare minimum that worked, missing the differentiating integrations we’d talked about (the LLM-driven report, the third-party hookups). Each of us had features we wanted to add, and without a clear conversation about whether to push those into the MVP, the schedule started ballooning. The root cause of an MVP that could’ve shipped in two months stretching to nearly three was that we never had a real conversation about that bar, and just went heads-down on our own pieces.

No Real Deadline

It wasn’t that there was no deadline at all. But this isn’t a public-launch project, and definitely not one we started for commercial reasons, so the two problems above piled on. Just one more week. One more week. And the schedule slowly drifted. Most failed side projects probably look like this. Most teams get the project to 90%, but the last 10% (the launch prep, the must-have features you kept pushing) actually takes as much energy as the previous 90%. It isn’t fun work. So in retrospect, that’s probably part of why I kept arguing for adding more features.

Pain Equal to the Joy

Tools like Claude Code and Cursor, riding the vibe-coding wave, are sold like one click and you can build software without knowing how to code. But unless your service is trivial, code still has to be touched by a human. As the feature surface grows, fixing A breaks B all the time. AI that misreads context creates duplicate logic, ignores the architecture layers, or invents its own pattern. Plenty of failure modes.

Backend I’d kept partially current, but frontend I hadn’t touched in ages, and every piece was a slog. Layout and styling issues, real-time handling, plenty of stuff Claude Code couldn’t one-shot. After feeding it more context and pushing it for a while, I’d often end up fixing the code by hand and resolving the issue immediately. So the joy of writing code came with a matching weight of frustration. The same was true for the simple-but-tedious setup work I was avoiding, like adopting tiptap and a few other must-have features I still haven’t built.

Bad Calls, Not Enough Thought

Because we have the structure of a SaaS that creates a workspace by default, there’s a split between user-level auth (logging into the service) and member-level auth (being a member inside a workspace). To move fast early on, I skipped that detail and just used user-auth the way I always had. As the service was nearly wrapping up, I realized how badly that choice had aged. We migrated the entire API design and auth scheme to be member-based, and that work alone, including verification and testing, took maybe three or four days. If you add the days I avoided it because I didn’t want to do it, it was over a week.

I’d also planned to bring in tiptap from the start but stopped because it felt like overkill at the time. Early in the project, complexity was low and the migration would have been quick. Trying to do it now feels daunting.

I picked Entgo as the Golang ORM mostly out of habit, but a lot of its advantages get neutralized when you have a clean architecture layer with clear boundaries. (More on this in the tech retro.)

Honestly, even if I’d been off the keyboard for a while, I made a fair number of calls that suggest my instincts had dulled, and I’m getting cheerfully beaten up for them at release time. It hurts.

Routine Issues

As I mentioned in the daily-life section, the routine I’d tried to hold broke down, and at one point both of us hit a wall, physically and mentally. As an emergency move we picked a workation, which turned out to be the right call. We came back somewhat reset, but I haven’t yet returned to the discipline I had at the start, and I need to reset again. Late in the project, the daily Scrumble entries and weekly retro reports were 80% complaints about how hard it was to hold the routine.

The courage to start again is harder than the courage to start the first time. Model life, take two. Let’s begin.

Try

Communication

A lot of these problems actually got solved when Ellie and I went for a walk and talked them through. So regular check-ins matter, and so does just talking more, period. Ellie’s reshaping the space we work in (our living room) to be more conducive to talking, and I’m setting up daily and weekly meetings so the next project never gets the note “communication was lacking.” Better too much than too little.

If You’re Not Embarrassed, You Shipped Too Late

If you are not embarrassed by the first version of your product, you’ve launched too late. Reid Hoffman (LinkedIn co-founder)

At some point, trying not to be embarrassed, I drifted off the original MVP and started arguing for an over-spec’d technical scope. It’s a thing I’m building for myself. I can keep refining it after it ships. In one of our retros Ellie said something that mattered: We were burning time trying to design for an unknown audience, and the moment I started thinking of “Tony as customer #1,” the work moved fast.

So we decided to release at this level and wrap up, to clear the deck for serious business prep and the next project. The next one will wrap much faster.

Immersion

A routine is one tool for immersion. But what I mean here isn’t only about working hours. There are very few times in life when time itself has been this abundant for me, and now that it is, I’m a little careless with it. By careless I mean not fully present, not fully immersed in the hour I’m in. If I keep wasting days like that, all that’s left is regret. Every day, I try to snap back. When I’m playing, I want to be fully in the play. I don’t want most of the day spent doing other work (company work) while my mind chases happiness elsewhere. I want to be in the present hour the way I originally meant to be. It’s a skill that needs practice. I’ll work harder at it. Work when you work, rest when you rest. That gets especially hard in this kind of setup, where I work at home and time is mine.

Lessons Learned

• A perfect MVP is a contradiction. Ship early, even if it’s embarrassing.
• Duo project = over-communicate. Even ten hours together, talking is non-negotiable.
• If it breaks, try again. A broken routine isn’t a reason to quit; just stand back up.
• AI is not magic. In the end, a human has to understand the code.
• Dog fooding is the answer. Be customer #1 yourself.

Closing

It was a side project, but full-time. Some days I sat for 20 hours straight coding. Some days I didn’t touch the keyboard for three days running. For years I’d spent every summer commuting in early to a building, working through to a late commute home, and this summer (already an unusually hot one) I worked from home and felt the full weight of it.

I’d wanted to build Scrumble for years at the last company, and I love that I’m using it every single day now. We’re a long way from the feature milestone we set, but I’ll keep updating it gradually as we move on to other product work.

Three months in, the truth is that committing my own hours to building made all my bad habits and weak spots visible. I could see clearly how much, at the last company, I’d been borrowing other people’s hands to solve things. The flip side: I’ve been thrown into an environment where I have to handle all of it myself, which is also where the fastest growth happens. The company was comfortable, but growth needs the courage to face everything yourself.

There are good days and bad days, and one regret is that I kept putting off writing or organizing notes until I was getting around to it like this. I logged the project daily, but I wonder if writing even a regular journal would have helped. Record more often. Look back more often.

I started this side project while preparing to start a company, and at some point it became the main thing. Hands loose, warm-up done. Time to apply what this project taught me to the next one, and not repeat the same mistakes.

Process matters and outcomes matter, but if you don’t actually finish, none of it adds up to value. Beyond the action items I wrote in the Try section, I’m going to keep facing myself head-on. And I’ll work harder so I don’t lose the joy.

“A warrior does not give up what he loves, he finds the love in what he does.” “A warrior is not about perfection or victory or invulnerability. He’s about absolute vulnerability.”

• Peaceful Warrior

(My desk during the workation)

(A check-out note inside Scrumble during the workation)

To be continued in the tech retro

• Previous retro
  • Four-year IHFB retrospective
• Next retro
  • Scrumble Tech Retrospective (subtitle: the failure of full-stack development and vibe coding. Golang and Next.js): 0. Opening