I’m Not a Developer. I Still Run Tech Projects. Here’s How.

Let me say this upfront:
I can’t write a single line of production-ready code.

And yet, I’ve led teams building real products. I’ve shipped web platforms, launched integrations, and built systems that work across multiple platforms — without ever opening a code editor.

So how?

The short answer: I think like a founder, not a developer.

The long answer? That’s what this article is about.

Whether you’re a non-technical entrepreneur, a first-time founder, or someone leading a product team from the outside, this is how I run tech projects — without touching code.

1. I Don’t Pretend to Know What I Don’t Know

This is where most people mess up.

They try to impress developers by throwing around terms they saw on Twitter — like “microservices” or “GraphQL” — without really understanding what they mean.

I do the opposite.

I stay in my lane. I ask questions. I make developers feel like experts — not like they’re explaining stuff to a boss who secretly resents them.

That creates trust. And trust gets things done.

2. I Focus on Outcomes, Not Code

When I start a project, I don’t ask:
“What should we build with?”

I ask:

What’s the problem we’re solving?
What’s the simplest version of the solution that works?
How will we measure success?

That’s the real job of a founder — to hold the outcome in focus while the team figures out the best way to get there.

Whether it’s Vue.js, React, or something else, I leave the stack to the experts. My job is to make sure the end result moves the business forward.

3. I Document Like a Maniac

This might sound boring, but it’s a game changer.

Before I bring in any developer or designer, I sit down and write a mini-product brief. Nothing fancy — just raw notes that clarify:

The user journey
Key features (must-have vs. nice-to-have)
Basic wireframes or screenshots
Expected integrations (Stripe, Directus, whatever)
Success criteria
Timeline or milestones

If it’s something visual, I use tools like Figma (even the free version works), or I just sketch on paper and take a photo.

Clarity beats perfection. Every time.

4. I Speak Developer-ish

Over time, I’ve learned to speak “dev” just enough to not get lost.

I don’t need to know how to write an API — but I do understand what it is, how REST differs from GraphQL, or how frontend and backend work together.

If a developer says, “This part will be async and handled via a queue,” I don’t go blank.

That kind of shared vocabulary builds momentum — because it means fewer misunderstandings, faster decisions, and less back-and-forth.

5. I Build Teams That Talk to Each Other

This might sound obvious, but you’d be surprised how many projects die because one person was waiting on another… for two weeks.

So I make sure:

Devs are in the same Slack channel as designers
Tasks live in Notion or Trello, not in someone’s head
We do short, structured standups (even async)
No one works in a silo

If I notice someone’s stuck or unsure, I step in — not to micromanage, but to unblock.

Sometimes, that means helping with a Stripe dashboard. Sometimes it means rewriting unclear copy. Whatever moves us forward.

6. I Use the Right Tools (No-Code & Low-Code)

When I want to test an idea, I don’t start with a developer. I start with:

Airtable for databases
Zapier or Make for automation
Framer or Typedream for landing pages
Directus CMS for structured content (like on sovrano.org)
Notion for docs and planning

This saves dev time and shows that I respect their bandwidth — which in turn makes them more likely to go all-in when we actually need their help.

7. I Work With Tech Partners Who Get It

Right now, I’m building several things — from Web3 apps (like BLM Swap) to e-commerce projects — and I always choose devs and agencies who:

Ask questions
Offer better solutions
Are willing to push back if something’s dumb (that’s a feature, not a bug)

I don’t hire “yes men.” I hire people who think.

8. I Stay Close to the Why

At every stage, I keep coming back to the question:

Why are we building this?

Because features are seductive. And scope creep is real.
But no one cares how fancy your backend is if it doesn’t solve a real problem.

That’s why I constantly remind my team:

“We’re not building for ourselves. We’re building for the customer.”

9. I’m OK With Not Being Technical

I used to feel insecure about not being a developer. Like I didn’t “deserve” to build things unless I could code them myself.

Now? I don’t care.

Because I know how to:

Create value
Communicate clearly
Make decisions under pressure
Rally a team around a vision

And that’s what a founder is supposed to do.

Final Thought: You Don’t Need to Code to Lead

The world’s best builders aren’t always the best programmers.
They’re the ones who:

Know what matters
Attract great talent
Create momentum
Deliver real outcomes

So no — I’m not a developer.
But I am a builder.
And that’s more than enough.

🖋️ Written by Bardia Rahmany — founder of My Parking in Sweden AB, builder of systems, observer of inefficiencies, and full-time executor of bold ideas.

🧠 Want help structuring your next tech project as a non-coder? Reach out here.