I think Katherine Mora just explained why almost every product I’ve ever built felt like it was held together with duct tape and prayers.
“You can do two things,” she told me during our conversation in London. “You can go and build in the quick and dirty way or in the scalable foundation way.”
I’ve done both. Usually without knowing which one I was doing. And that’s exactly the problem.
Katherine’s a fractional CTO who spent 16 years in corporate consulting before starting her own company three years ago. She works with startups across data, search, and AI—and she sees the same pattern constantly: founders get six weeks into a “two-week sprint,” budgets are blown, and no one can figure out what went wrong.
Here’s where it clicked for me
When Katherine said “quick and dirty,” I tensed up. It sounded like an insult. Like admitting you’re building something sloppy.
But that’s not what she means at all.
“Quick and dirty means you can just go and use all the AI tools—even using a development team—building something fast just to test and start getting traction,” she explained.
It’s experimental. It’s the sellotape-and-hope approach that gets something live so you can test whether people actually want it. And here’s what I hadn’t understood: that’s not a failure of planning. That’s the entire point.
The Generalist World website? Quick and dirty for years. I literally described it to Katherine as “sellotape holding it together.” I felt embarrassed about that. Like I should have done it properly from the start.
Her answer stopped me: “Quick and dirty doesn’t mean that it’s bad all the time. It’s more like what are your expectations?”
The trap I keep falling into
Then I asked her what she sees founders get wrong. Her answer felt personal.
“Sometimes they get so excited because of AI—it looks like you can do things so quickly,” she said. “They start adding more features and more features on something that maybe people didn’t want. Then they’re like, ‘the team is not moving fast enough.'”
I’ve done this. Built features no one asked for because they seemed possible. Then gotten frustrated when the site felt slow or buggy. The problem wasn’t speed. It was that I didn’t have clarity about what I was actually building.
Was I testing whether the community wanted this feature? Or was I building something that needed to scale with us?
Katherine makes her clients declare their approach upfront. Are we building quick and dirty to test? Then everyone knows this might need rebuilding later. Are we building for scale? Then everyone knows this takes longer and costs more.
“As long as you have that clarity, that saves a lot of effort and energy and headaches for technical people and nontechnical people,” she said.
When sellotape stops working
Wait, this is the interesting part. Katherine doesn’t say quick and dirty is wrong. She says it works until it doesn’t.
“As you start growing, you need a good foundation,” she told me. “Same with a house—if you don’t have a good foundation, your house is going to fall apart after you keep adding floors or bedrooms.”
The shift point? Traction. When customers are actually using your product and you’re starting to scale, that’s when architectural decisions matter. That’s when your sellotape solution becomes a liability.
We’re going through this right now with Generalist World. Finally getting the website rebuilt by someone who thinks about UI and UX properly. Because we’re past the testing phase. We know people want this. Now we need it to work reliably.
But Katherine sees founders make two opposite mistakes. Some never graduate from quick and dirty—patching problems forever. Others go to the extreme: “They want everything to be perfect and then they don’t end up releasing anything.”
I asked her how to know which approach you need. Her answer was simpler than I expected: Are you testing or scaling?
If you’re not sure? You’re probably still testing.
Why non-technical people have the advantage
This surprised me. Katherine’s spent 20 years in tech, but she thinks non-technical founders have a superpower.
“If you’re working in an industry with a specific problem, you see it. You know what people are doing day-to-day in human resources or customer service. You know what’s failing,” she said. “The superpower for us on the tech side is we can build anything. But we don’t know what those problems are.”
Tools like Lovable, Cursor, and other AI coding platforms are changing this. Non-technical people can finally build without depending on someone else. They know the actual problem. Now they can test solutions fast.
But—and this is what Katherine kept emphasizing—you still need that clarity. Are you building a throwaway version to experiment? Or building something that needs to scale and be secure?
“If you connect those two dots, you’re going to be innovating a lot,” she said.
The generalist advantage
Katherine described herself as feeling “out of place” throughout her consulting career. She did data engineering but wasn’t a “full full data engineer.” She had consulting skills but was doing technical work. She stayed at one company for 11 years partly because she was “too scared” to leave—afraid of losing skills she’d worked hard to acquire.
Then she found the generalist framework. “It helped me rephrase. That’s also why I started my own company.”
Here’s what I’m taking from this: generalists understand the quick-and-dirty versus scalable-foundation distinction intuitively because we’ve lived it. We know when to go deep and when to stay nimble. We know the difference between expertise and over-engineering.
Katherine can walk into a startup with a vague idea and help them understand what they’re actually building. She translates between technical and non-technical teams. She spots when founders are adding features nobody wants because she’s seen that pattern across a dozen industries.
That breadth isn’t a bug. It’s exactly what makes her valuable as a fractional CTO.
What I’m doing differently now
Before your next build, ask yourself: Are we testing or scaling?
If you’re testing—embrace the experiment. Use AI tools. Build something that might break. Learn fast. And stop feeling bad about the sellotape.
If you’re scaling—invest in the foundation. Bring in someone who’s built for growth before. Accept that good architecture takes time.
Katherine’s framework isn’t just about technology. It’s about being honest with yourself about where you actually are—and building accordingly.
I’m stealing this immediately. Not just for Generalist World, but for how I think about every project. The guilt I’ve been carrying about “not doing it properly” was misplaced. Quick and dirty wasn’t the problem. Not knowing I was doing quick and dirty was the problem.
Now I know. And that changes everything.
Listen to the full conversation with Katherine Mora on the Generalist World podcast.
Katherine Mora is a fractional CTO and tech advisor working with startups and SMBs. She’s also chapter lead for Latinas in Tech London. Originally from Costa Rica, she spent 16 years in corporate consulting before founding her own company. She’s a founding member of the Generalist World community. Connect with her through Generalist World.
