Imaginationmaxxing, Mercenary Mindset, and Thoughtclouding: Three Traps of the Weekend Founder

I just had the kickoff meeting with a friend I’m attempting to build an app with.

I came up with this idea a while back and did some initial research, then had to shelve it as other things took over. I mentioned it to this friend, and he actually pushed me to expand on it and start building — but I knew I couldn’t take on a new project at the time. So he waited, occasionally sending texts like “listen, I’m game if you’re game,” followed by “don’t worry, I won’t steal your idea!”

The kickoff meeting itself went well. We talked a bit about the product, but since I still haven’t done proper market research or a viability check, most of the conversation ended up being about project management. It was spontaneous — we just started comparing notes on mistakes and pain points from our past attempts at building things with other people.

Turns out we’re aligned on commitment, on how we track output, on what counts as an MVP. That conversation is what prompted this post: three specific traps I think most new “founders” fall into.

I say “founders” in quotes because I’m not talking about Y Combinator territory — I mean a small crew starting something on the side, a few hours a week after a 9-to-5, that might actually grow into something. A lot of the people doing this are young, or have simply never had to self-govern before. There’s no employer telling them how to organize or delegate. They’re figuring that part out for the first time, usually while also trying to ship something.

I’ve hit all three of these traps myself. Writing them down now, partly as a reminder for future me and M. as we get going.

1. Imaginationmaxxing

Remember Snoop Dogg’s Gin and Juice? That laid-back hook about cruising around with money on his mind.

I heard that song as a kid with no idea what half of it meant and still found it irresistibly catchy. I also liked making up scenarios as a kid. Imagination and visual thinking were never a problem for me — I enjoyed both the possibilities and the imaginary realities themselves. This isn’t a post about my childhood, bear with me — that same habit of imagining possibilities doesn’t go away. It’s exactly what takes over once a side project starts moving. Here is how it goes.

Once an idea starts brewing and the first few tasks get checked off, there’s a new energy in the air.

The conversations shift: will we need more people? Should we get a workspace? How do we price this?

Keep working, keep adding to the board, and the questions escalate: do we need a web app too? Should we go global? What do we give our MILLIONTH USER???

Staying motivated and inspired matters, but somewhere in there you need self-control, because this tips very easily into maladaptive daydreaming — especially where money’s involved. Everyone needs it, so naturally it dominates the fantasy. And let’s be honest: most side projects start as a way to earn more, not to make the world a better place.

Real life problem: We hadn’t even published the app to the stores yet, and while we were actively working on every part of it, we’d also slipped into a shared fantasy. In our heads, we’d already paid off our mortgages, bought new cars, quit our 9-to-5s. The app did eventually ship but none of the things we imagined ended up happening.

2. Mercenary Mindset

Working at a startup teaches you to flinch at very specific sentences. For me, one of them is:

You’re at a startup, so you need to wear multiple hats.

Well, pour me some tea and call me Mad! It’s true that your role will end up covering far more than you expected, and you’ll need to work around a lot of moving parts. But on your own side project, it’s worth being honest with your team and keeping work domains as separate as you reasonably can. Each person should be doing mostly what they’re actually good at.

Real life problem: we were a team of two developers and one person handling everything else. Instead of splitting the work along those lines, everyone decided to be scrappy and “startup-y” and do a bit of everything.

The result: someone with zero interest in development spent hours fighting to get a Flutter build working on their machine, someone who’d always struggled with details left a trail of typos, hardcoded text, and badly wrapped images across the main site, and the one true introvert on the team got stuck doing outreach and user interviews.

Here’s a cleaner version of that same dynamic:

Tom is a senior full-stack developer, strong on both back end and front end, with zero interest in design. He’s also excellent with people — he finds everyone easy to talk to and knows folks across a lot of different circles.

Mark is also a senior developer, primarily backend. He picked up a minor in modern art in college and spent a chunk of it doing graffiti. He’s a natural storyteller who could sell you your own family history.

Ivan is a mid-level full-stack developer and an introvert who doesn’t love being around unfamiliar people. What he’s genuinely great at is building organizational systems and roadmaps, following up on what was discussed — in person or on Slack — and he knows his way around Figma with a decent eye for it. He’s basically the project manager nobody officially assigned. 🙂

Tom	Mark	Ivan
Great with people	Great at selling	Not a people person
Full-stack senior, prefers backend	Backend senior	Full-stack, mid-level
Not visually inclined	Artsy	Knows design and tooling

Expecting all three to spend their time the same way, when their strengths point in three different directions, wastes what makes each of them good. In an ideal world each of them covers exactly a third of what’s needed, but in practice those thirds overlap. Still, if the goal is to maximize output and the odds of actually shipping, the work should be split around what each person does effectively — not just efficiently.

So in this case:

1. Tom handles customer success and development, focused on the back end.
2. Mark handles pitching and sales, helps Tom with backend work or architecture, and owns the visual identity and mockups.
3. Ivan focuses on the front end and task management.

Sometimes two people will have nearly identical strengths, and sometimes a job to be done won’t have an obvious owner yet. That’s fine — that’s where trial and error, volunteering, and iterating come in. That’s when you get scrappy. Not at the very start, before the initial split even happens.

Fix for Mercenary Mindset:

• Talk openly. List each person’s actual strengths and weaknesses.
• List the jobs that need doing and the roles they map to — developer, architect, sales, account management, project manager, product owner, whatever applies.
• Match people to roles deliberately, instead of defaulting to “everyone does everything.”

3. Thoughtclouding

Remember how cartoons show characters thinking with little bubbles floating above their heads? As a kid I genuinely believed we all had those, and I’d scan the room whenever someone looked lost in thought, waiting for the bubble to appear. It never did. Years later I found out I have ADHD, and honestly, I’m relieved I don’t also have to deal with the visual clutter of a hundred thought bubbles floating around every room I walk into.

Real life problem: I write everything down. Not out of some deep sense of responsibility — mostly because if I don’t, I forget. If a meeting doesn’t have a calendar invite, it isn’t happening. But I was side-hustling with people who loved to talk and never wrote anything down. We’d discuss what needed to get done, and I’d get the “yeah, don’t worry, I’ll fix that” or “I’ll handle it later.” Three days later, we’d have the exact same conversation about the exact same issue. There was never one shared backlog — everyone kept things in their own private thought bubble, and those bubbles just quietly popped or evaporated.

Fix for Thoughtclouding:

• Keep one shared backlog and one source of truth for documentation — product requirements, roadmap, whatever it is — in a single tool, whether that’s Notion, Linear, or something else.
• Don’t accept verbal promises as commitments.
• Track what’s been done and what’s still open, in writing, somewhere everyone can see it.

Bottom line

None of these traps are about lack of talent or lack of effort. They’re about the fact that most people doing this for the first time have never had to set their own rules before — no employer defining scope, no manager assigning tasks, no HR process forcing a shared doc.

You build that structure yourself, or you don’t have it. Imaginationmaxxing, mercenary mindset, and thoughtclouding are what fills the gap when you don’t. Same gap I filled by inventing two of those three words. 😉