The Head of a Marketer, Engineer, and App Developer

I need to get something out of the way before this article goes any further.

I am not a good developer.

I’m serious. A real developer would look at my code and wince. My folder structures are questionable. I Google things that probably should be obvious. I’ve spent entire nights debugging problems that turned out to be a missing comma. I am not writing this article from the perspective of someone who’s mastered three disciplines. I’m writing it from the perspective of someone who’s mediocre at two of them and pretty good at one.

But here’s the thing I’ve learned — and this is really the only point of this entire article: you don’t need to be great at everything. You just need to be willing to be bad at the things you’re not great at.

That willingness changed everything for me. And I think it might be the most underrated skill a founder can develop.

The Three Heads

Here’s how my brain works on any given day.

The marketer is the one I trust. I’ve been doing this since I was 10, even before I had the vocabulary for it. This is where my instincts live. Who’s the audience? What do they care about? What’s the first thing they’ll see, and will it make them stay or leave? The marketer is always asking: does this land?

The engineer is the one I was trained in. I study Automotive Engineering at McMaster. It didn’t teach me to code, but it taught me something more foundational: how to think in systems. Inputs, outputs, dependencies, feedback loops. The engineer is always asking: does this hold?

The developer is the one I’m still figuring out. I taught myself to build software because the problem demanded it, not because I had any natural ability. The developer asks the simplest question: does this ship?

Three voices. One of them confident, one of them trained, one of them faking it half the time. And somehow, that combination works better than I expected.

Why “Bad At It” Still Matters

Let me tell you a story that explains this.

When I was building Vantage, there was a moment where I needed the results from Module 2 to carry into Module 4. The marketer brain knew exactly why this mattered — if a founder defines their audience in one step and then the competitive analysis doesn’t reference that audience, the whole experience feels disconnected. The engineering brain understood it as a data flow problem — state needs to persist across modules.

But the developer brain? The developer brain had no idea how to actually do that.

So I fumbled through it. I tried three approaches that didn’t work. I read documentation I barely understood. I asked for help. I wrote ugly code that eventually did what it needed to do. A real developer would have solved it in an hour. It took me most of a weekend.

But here’s what a real developer probably wouldn’t have done: they wouldn’t have known why the data needed to flow that way. They wouldn’t have felt, in their gut, that a disconnected experience would make a founder feel like the tool didn’t understand them. They would have built a technically cleaner solution to a problem they didn’t fully feel.

The worst version of something built by someone who understands the problem deeply is often better than the best version built by someone who doesn’t.

That’s not me defending bad code. My code is sometimes bad and I’m working on it. But it’s me saying that understanding the problem is the part that matters most, and the execution catches up over time.

The Real Advantage Isn’t Talent. It’s Translation.

When I started Olunix, I had a specific vision for how the positioning roaster should work. Not just what it should do — how it should feel. I wanted a founder to paste their URL, get a score and a brutally honest roast, and have the result be something they’d actually screenshot and send to their co-founder.

If I’d hired a developer to build that, I would have written a spec. The spec would have described the scoring, the output format, the share flow. And the developer would have built exactly what I described. But they wouldn’t have known that the roast line needs to sting just enough to be funny but not so much that it feels mean. They wouldn’t have known that the score breakdown needs to be visual enough to screenshot. They wouldn’t have known that the fix suggestions need to be specific enough that a founder could actually rewrite their headline in five minutes.

Those aren’t technical requirements. They’re marketing instincts that need to be expressed in code. And the only way to express them in code is to write the code yourself — even if you write it badly.

The real advantage of having multiple perspectives in one head isn’t that you’re good at everything. It’s that you don’t need a translator. The gap between what you mean and what gets built shrinks to zero, because you’re the one building it. The trade-off is that the build quality is lower than a specialist’s. But the intent fidelity is higher. And for early-stage products, intent fidelity matters more.

What I Actually Think About All Day

People ask what my day looks like. Here’s the honest version.

I wake up thinking about marketing. What’s the next article about? What’s the positioning angle for the thing we’re launching next? Is the homepage copy still working or has it gone stale?

By mid-morning I’m in code. Fixing something that broke. Adding a feature. Staring at an error message I don’t understand, pasting it into a search bar, reading three Stack Overflow answers, understanding one of them, and trying it. Sometimes it works. Sometimes I break something else.

By afternoon the engineer brain kicks in. I step back from the code and the copy and ask: does any of this connect? Is the system coherent? If a founder starts with the audit and works through to the playbook, does the experience feel like one continuous thing, or does it feel like seven disconnected tools duct-taped together?

And then at night I’m back to marketing. Writing. Planning. Thinking about the next move.

None of this is graceful. There’s no smooth handoff between modes. Some days the marketer brain refuses to turn off and I can’t focus on code. Some days I’m deep in a technical problem and the marketing falls behind. Some days I feel like I’m bad at all three simultaneously.

But here’s the thing — bad at all three is still more useful than great at one when you’re building alone.

The Lesson Nobody Taught Me

School doesn’t prepare you for this. Engineering school taught me to solve defined problems with defined tools. Marketing taught itself to me over years of doing it. And software development? I learned that the way everyone learns things they weren’t supposed to learn — by needing to, and refusing to let the gap in my ability be the reason the thing didn’t get built.

If there’s a takeaway here, especially for other founders who are building something as a student or doing it solo or doing it with no budget, it’s this:

You don’t need permission to be bad at the thing your project needs.

Your startup needs a website and you’re not a designer? Design it anyway. It’ll be ugly. That’s fine. Your product needs code and you’re not a developer? Write it anyway. It’ll be messy. That’s fine. Your launch needs marketing and you’re not a marketer? Market it anyway. It’ll be awkward. That’s fine.

The gap between zero and one isn’t talent. I’ve written about this before. It’s the willingness to be bad at something important for long enough that you start getting less bad. That’s the whole secret.

What I’d Do Differently

If I’m being honest, I’d tell my past self to worry less about which hat he’s wearing and more about whether the thing he’s building actually helps someone.

I spent too long early on trying to figure out my identity. Am I a marketer who codes? An engineer who does marketing? A founder? A consultant? A developer? What’s my title? What’s my lane?

The answer, it turns out, is that the lane doesn’t matter. The problem matters. And if the problem requires you to think like a marketer in the morning, an engineer in the afternoon, and a developer at night — then that’s what you do. You don’t need a title for it. You don’t need to be great at all of it. You just need to care enough about the problem to keep showing up, even in the modes where you feel like a fraud.

I still feel like a fraud when I’m writing code. Probably always will. But the thing got built. And it works. And founders use it. And that matters more than whether the code is pretty.

Care about the problem more than your identity. The skills follow the obsession.

If you’re juggling multiple hats right now and feeling like you’re not good enough at any of them — that’s not a sign that you’re failing. That’s a sign that you’re building something real. The people who feel comfortable are the ones who stayed in their lane. The ones who feel stretched are the ones who are actually growing.

Keep going. Get less bad. Ship the thing.

- MM