You don't need to be a developer to start

A week ago I launched playitsmart.nl. But for a while now I've been getting two kinds of questions, from friends who see what I'm doing and from developers I talk to. People who say "wow, how do you do that", and experienced developers who say "fun, but you can't build a complex automated system without experience".

Both are partly right. Both are partly wrong.

In this post I want to tell you how I think anyone can start, even if you can't write a single line of code. And why the sceptics about complex systems have a point, but not the way they think.

What I do myself

I write zero lines of code. Literally none. All code in this project comes from AI, I steer where needed and I review what comes out.

My role is to think about what I want, ask questions, and check whether it's correct. Not type.

Before you think "yeah, you probably have a technical background": correct, I've worked in technical ICT environments since the very start of my working life. I co-founded a data and analytics company, sold it. But I didn't program myself there. I understood things at the conceptual and architecture level. I could think through architecture and oversee the consequences of choices. Not type the lines of code, but determine the direction.

Today that conceptual understanding is enough to start. AI fills in the rest.

The biggest barrier: daring to ask

The most important thing I've learned: ask questions as if you know nothing.

Literally. Write as a prompt: "I'm a beginner, I can barely write code, explain things constantly". In Claude Project you can even fix that in the project description, then Claude remembers it in every conversation.

What happens then? Claude explains in understandable language. With examples. With trade-offs. Not in jargon, but in language that fits what you can absorb.

And if you still don't get it? Ask again. Ask for another example. Ask why he proposes this and not something else. That takes more time than an experienced developer would spend on it, but it works.

Take screenshots when you get stuck

A very practical tip: just take screenshots of whatever you don't understand on your screen.

Say you need to do a DNS setup in Vercel or Cloudflare. Or you need to create an API key somewhere. Or find a setting in an interface you don't know. Take a screenshot, paste it in the chat, and ask your question.

Claude can read images. He sees what you see. Based on that, he explains step by step what to do, which button to click, which option fits what you're trying to achieve.

Bonus: also ask for explanation, not just the action. "What does this setting actually do?" Because it's fun to learn new things while you're at it. Not just "click here", but "click here because this controls X and prevents Y". Then your understanding grows along with what you build.

Where the sceptics are half right

A few developers in my circle said: "fun, but building a complex automated trading system without being able to program yourself? That won't work."

They're partly right. As your project gets more complex, it goes slower. In the first two weeks it flew. A complete website, blog, sitemap, RSS, OG image, live in four days. In a few hours a day.

But now we're moving to the real heart of the system, the Python code that fetches data, calculates factors, generates signals, and places orders, I know that's going to go slower. More iterations, more reviews, more troubleshooting.

They're also partly wrong. Because it can be done, it just takes longer. And even at that slower pace, it still goes at least ten times faster than before, when you'd need a team of four developers for what I'm now doing alone.

It's not all-or-nothing. It's a slider. The more complex your project, the more patience you need. But it doesn't become impossible.

Three tips for those who want to start

One: position yourself as a beginner

In the Claude Project description, write literally: "I'm a beginner. Explain everything. Don't ask me to install things without saying why. Always give me two or three options with pros and cons, not one answer."

Claude adapts his answers accordingly. Without that instruction you more often get answers that assume technical background knowledge.

Two: ask follow-up questions

For every decision AI proposes, ask: "what are alternatives? Why exactly this choice?" That forces AI to weigh instead of blurting out the first thing.

In my previous blog post (When Claude gets it wrong) there's a concrete example where I did this with a hosting choice. The second answer was significantly better than the first, just because I pushed back.

Three: step by step, not everything at once

Beginning goes fast. The bigger your project, the more you notice doing four things simultaneously doesn't work. One at a time. Register domain. Done. Choose hosting. Done. Build first page. Done. Then the next step.

I underestimated that myself in week one. Was doing four things at once and ran into problems that had nothing to do with AI. Local Git misconfigured, shell environment fighting me. Nothing AI is needed to fix, but also nothing AI helps you with if you try to skip ahead.

What I can do, what AI can't

Honestly: AI isn't everything. I have to set the direction myself. I have to feel when something is off. I have to keep playing the critical reviewer role.

But that's exactly what a non-developer can do. You know what you want to build. You feel when something isn't logical. You can ask questions. You can decide.

The rest, typing code, knowing syntax, solving obscure errors, AI does that.

The question that remains

I believe anyone with an idea who is willing to ask questions can start. Not deliver a production system tomorrow, but start. And after a few weeks have something to show.

The biggest blocker is not technique. It's daring to start despite not knowing everything. And that goes equally for people who say "I can't code" as for sceptical developers who say "complex building can't be done without experience".

Ask your question. Ask again. Take screenshots when you get stuck. Build step by step. And give it time.