Folded Shirts Origin Story

Imran GardeziNovember 2, 20257 min read

I dropped out of law school after two months.

I folded t-shirts at Jack & Jones for five years.

And now? I build software that has been used by millions at companies like Shopify and Brex.

Your non-technical background isn't a weakness. It's your biggest competitive advantage.

The best software isn't built with perfect code. It's built with your expertise and real business context.

The Imposter Feeling

You're successful in your field, but every time software comes up, you feel lost and a little uncomfortable. Every conversation with developers makes you feel stupid or behind.

You scroll through TechCrunch and see 23-year-olds raising millions, and think: "I'm too late." "It's probably already been done." You're afraid to admit how little you know about development. Deep down, you believe tech people have some secret knowledge you'll never have. You worry you're too "non-technical" to compete in a software-driven world.

I know that feeling.

I grew up half-Irish, half-Pakistani in a small town in Ireland. Never really fitting in anywhere. Teachers dismissed me for spending hours in World of Warcraft, not realizing I was coordinating 40-person raids with more leadership structure than most offices. That game taught me resource management, team coordination under pressure, and how to motivate strangers toward a shared objective. Skills that turned out to be far more useful in a career than anything I learned in a lecture hall.

I enrolled in law school because, if I'm honest, it seemed safe and the right route to take. Two months in, I hated it. It felt suffocating. Everyone around me had connections, internships, the right last names. I had none of it. Dropping out felt like a relief and a failure at the same time.

So I folded shirts at Jack & Jones. For five years.

And that voice never left: "You messed up."

Business Context Beats Technical Pedigree

But that moment at Digisoft wasn't the end. It was the beginning.

The false belief that so many people carry is that you need a computer science degree or some secret knowledge to succeed in software. The reality couldn't be more different.

Business context beats technical pedigree every single time.

Every failed software project I've seen had technically perfect code solving the wrong problem. The developers were brilliant. The architecture was sound. But nobody on the team understood the actual business problem well enough to build something users would care about.

Let me tell you my full journey.

Law school felt like the "smart" path. Until I hated it. Dropping out was absolutely brutal. I braced for my dad to lecture me. Instead, he said: "Find a job. Keep yourself busy. We'll try again next year."

So I folded shirts. For five years. Not glamorous. But oddly educational. My wife certainly appreciates my folding skills.

Every day, I rebuilt perfect displays and watched customers wreck them in minutes. Soul destroying. But every hour, I watched what made people stop. What made them buy. What made them walk away. I noticed patterns that no analytics dashboard could capture: the way someone's eyes would linger on a display, the hesitation before they touched a fabric, the specific moment they decided to walk into the store versus keep walking. That five years of watching human behavior became the foundation of everything I build today.

That was my first product lesson: It doesn't matter what you think looks good. It matters what actually works.

I went back to university. Business Information Systems. Safe choice, because I didn't think I was able for Computer Science. Until I touched code. HTML. A few lines. And boom, it worked in a browser. Something I built. Alive on screen. That was it. I was obsessed.

My final project? A health tracking app called Smatra. End to end. Even hacked Fitbit integration at 3am with no guidance. That app got me my first job. Not because it was pretty, but because it worked.

Day one at Digisoft: "Clone the repo." I panicked. Learned all night. By Monday, I was pushing commits like I'd been doing it for years. That became my rhythm: Get hit. Learn fast. Come back sharper.

Digisoft. Motorola. Shopify. Brex.

Here's what I learned across all of those companies: the best shippers weren't the smartest. They were the clearest. They knew what mattered. They could cut through the noise and identify the one thing that would move the needle. At Shopify, the engineers who had the most impact weren't the ones writing the most clever code. They were the ones who understood the merchant's problem deeply enough to build the simplest solution that actually solved it.

And here's the bridge for you: your background is your advantage. You know what customers actually want, because you've served them face to face. You know how to spot bullshit, because experience teaches that. You know what problems are worth solving, because you've run a business. You know how to prioritize when everything feels urgent. You know how to explain ideas simply, because you've had to sell before.

Tech people often build impressive solutions that solve nothing. You build solutions that matter. That's the difference.

That imposter feeling doesn't just stay in your head. It leaks into everything.

In your business? Opportunities slip away because software feels like a foreign language. You overpay for talent because you can't tell good from great. You move slower than competitors who actually "get" tech. And when you try to explain your vision, what gets built never quite hits the mark. The gap between what you see in your head and what shows up on screen feels like a translation failure, and it is. But the failure isn't yours. It's the process.

On your team? They feel the hesitation. You burn money on hires who look good on paper but don't deliver. You hand every decision to "the tech people," forgetting you're the one who actually understands the business. Over time, your technical team starts making product decisions by default because nobody else is stepping up, and those decisions are almost always oriented toward technical elegance rather than business impact.

I still remember my first day at Digisoft. Someone said, "Just clone the repo from GitHub." I had no idea what Git even was. My stomach dropped. I thought: This is it. I'm about to be exposed as a fraud.

That night I went home and told my (now wife) I'd blown it.

When you realize your background is an advantage, everything changes. You stop apologizing for not being technical. You start evaluating tech people like any other vendor: Can they deliver results? You make confident decisions about strategy. You ask better questions, the kind that expose incompetence instantly. You build software that serves your business, not just "best practices."

And you start to feel proud of your unconventional path.

I used to sit in meetings surrounded by ivy league CS grads. At first, I felt like an imposter. But then I realized my questions about business impact were more valuable than technical one-upmanship.

That's the identity shift: from "non-technical founder" to "strategic operator who uses software as a tool."

When you make that shift, the ripple effects are massive.

On your business? You build software that actually serves customers. You hire better technical people because you can tell substance from fluff. You move faster because you're no longer paralyzed by imposter syndrome. You create competitive advantages that pure technologists miss entirely, because your software is shaped by real customer understanding rather than abstract engineering principles.

On your team? They respect you more. Technical hires stay longer because you understand their world enough to back them up. Everyone moves faster because you're not second-guessing everything. Culture improves because confidence flows from the top. When the founder knows what matters and communicates it clearly, the entire team operates with less friction and more purpose.

On your industry? You become the business owner people ask for advice. You prove "traditional" operators can succeed in tech. You show you don't need VC or a Stanford badge. You create jobs and opportunities for people like you.

The tech world isn't just for 23-year-olds with pedigree. It's for anyone who can think strategically.

What to Do Next

If you're sitting there thinking, "I'm not technical enough to build software," hear this: that's exactly why you should.

Your business knowledge, your industry context, your customer understanding. That's worth more than any CS degree. The founders I've worked with who had the deepest industry expertise consistently built better products than the ones who had the strongest technical backgrounds. Why? Because they understood the problem at a visceral level. They'd lived it. They'd felt it. And that understanding translated into software that felt intuitive to the people who would actually use it.

You don't need to learn to code. You need to learn to think strategically about software. And you need someone who can translate vision into reality.

That's what I do.

I've spent over a decade in the trenches building software at scale. Now I help business owners turn what already works into software that scales.

Book a Strategy Session. Link in description.

In 90 minutes, I'll show you how your background is an advantage, and what to do with it.

Stop trying to become someone else.

Start leveraging who you already are.

Key Takeaways

Technical skills can be learned, but business context cannot be taught. The best software comes from understanding people, not just code. Your "weird" path, whether that's retail, law, finance, or any non-technical field, gives you perspectives that pure technologists miss entirely. Those perspectives are what make the difference between software that technically works and software that people actually want to use.
The best software builders understand both sides. They're not pure technologists, and they're not pure business people. They're the ones who understand the business problem deeply enough to translate it into clear requirements that developers can execute. You don't need to write code. You need to think clearly about what your users need and communicate it in a way that eliminates ambiguity.
Imposter syndrome in tech is a misdiagnosis. The feeling that you're "not technical enough" isn't a signal that you're lacking something. It's a signal that the tech industry has conditioned you to undervalue what you bring to the table. Your customer insight, your ability to prioritize, your instinct for what matters. These are the exact skills that most development teams are missing.
Your unconventional background is a strategic differentiator. Founders who come from non-technical backgrounds build products shaped by real customer understanding rather than abstract engineering principles. They ask questions that tech-only people never think to ask, and those questions prevent the most expensive mistakes in software development.
The identity shift from "non-technical founder" to "strategic operator" changes everything downstream. When you stop apologizing for not being technical and start leading with business insight, your team operates with more clarity, your hires get better, your product decisions improve, and your confidence compounds. This shift is not about learning a programming language. It's about recognizing that the skills you already have are the ones that matter most.

Frequently Asked Questions

Can I build a successful software product without a technical background?

Absolutely. In fact, many of the most successful software products were built by founders who came from non-technical fields. What matters most is not your ability to write code, but your ability to understand the problem you're solving at a deep level. If you've spent years serving customers in your industry, you already have the most important ingredient: context. The technical execution can be hired for. The business insight cannot. Your job is to validate the problem, define what success looks like, and find the right technical partner to translate your vision into reality.

How do I evaluate developers if I don't understand code?

Evaluate them the same way you'd evaluate any vendor: by results. Can they explain what they're building in plain language? Can they connect their technical decisions to your business goals? Do they ship on time, and does what they ship actually solve the problem? You don't need to review code to assess competence. Ask them to walk you through their approach, watch whether they ask clarifying questions about the business problem, and pay attention to whether they push back when something doesn't make sense. The best developers want clear requirements. If they never push back or ask questions, that's a red flag.

Is it too late to get into tech if I'm over 30 or 40?

Not at all. The narrative that tech is a young person's game is a myth perpetuated by a small slice of the industry. The reality is that business experience becomes more valuable, not less, as you get older. You've spent years learning what customers want, how markets move, and how businesses operate. Those are exactly the skills that most tech startups are desperate for. I dropped out of law school, folded shirts for five years, and went back to university as a mature student. Every company I've worked at since then valued my business perspective as much as my technical ability, and often more.

What should I do first if I have a software idea but no technical skills?

Start by validating the problem, not the solution. Talk to 10-20 people who experience the problem you want to solve. Don't pitch your idea. Instead, listen to how they describe their pain, what workarounds they've built, and what they've already tried. If you hear the same frustrations from multiple people, you have a validated problem. From there, sketch out the simplest version of a solution (even on paper) and show it to those same people. Their reactions will tell you what to build first. Only then should you engage a developer, and when you do, you'll be handing them validated requirements instead of vague ideas.

How do I overcome imposter syndrome when working with technical teams?

Recognize that imposter syndrome in tech is almost always a misdiagnosis. You're not feeling inadequate because you lack something. You're feeling inadequate because the tech industry has a cultural habit of making non-technical people feel small. The fix isn't learning to code. The fix is learning to ask the right questions: "What user problem does this solve?" "What happens if we don't build this?" "How will we know if this feature is successful?" These questions are far more valuable than any technical jargon. Once you start asking them consistently, you'll notice that the technical people in the room start deferring to your judgment on what matters, because you're the one who actually understands the customer.