Clear answers, no hope-peddling

Yes — most of the people I work with started from exactly there. A doctor, an architect, a musician, a teacher, a consultant, a produce wholesaler. I have worked with people from more than twelve non-software professions, and what they had in common was not knowing code while knowing their own work very well.

Two concrete cases. Aytaç Keskinege, a doctor of 55, built full CRM systems for two separate businesses of his own. Cüneyd Yuzak told me in our first session that he had heard the word agent but only knew it from James Bond films; nine days later his company's CRM was live.

None of this is about learning to code. The AI writes the software; you describe what the work actually needs — and you know your own field better than any developer does.

You are right, and jargon is often just how people who know something make themselves feel important. In the sessions you meet each concept at the moment you need it, in your own words. There is no glossary to memorise.

The two simplest examples: an agent is a program that can carry out work step by step on its own, and deploying means putting your site at an address anyone on the internet can reach. That is the whole of it.

No. You do not need to buy anything before the first session, and most people start exactly there.

Go to claude.ai and try signing in with your email: if you already have an account it opens, and if not you create one in a minute. In the first session we look at your account together and choose the plan that fits the work you actually want to do.

Not a problem — you learn it in the first session. GitHub is where your code is stored and where every change is recorded. Think of it as Google Drive plus a change history, for code: if something goes wrong you can go back to an earlier state.

We do the whole setup together. You do not need an account before we start.

No — but "I will know nothing and let it do everything" is not it either. The goal, in the phrase a participant found for it himself, is to become the software boss. A boss does not know how each screw is turned; they specify the work and inspect the result.

That is exactly what I teach: what to ask for, how to check what came back, and when to stop it and step in.

You do not have to know the right question — it is the first thing I teach. The practical pattern is this: "I want to do this piece of work. Ask me questions." Getting the AI to ask the questions is far easier than inventing them yourself.

The second pattern is "I am a beginner — you do this step." Those two sentences are what most people memorise in their first week, and they are the two that earn their keep.

Let me be plain: no. And you do not need to.

The goal is not to become a developer but to become the software boss — the person who directs the AI, inspects the result and runs the system. The AI does the typing; you are on the deciding and checking side.

In most cases yes. Some company machines need administrator rights before anything can be installed, and that can run into your IT department — we have hit this for real.

In the first session we look at your machine and pick the best route. Where permissions are locked down there is always a plan B.

The chain is simpler than the names suggest: Claude writes the code, GitHub stores it and records every change, Cloudflare or Vercel publishes your site to the world, and services like Supabase hold your users and your data.

You do not learn this from a diagram. You learn it building your own project in the first sessions, one link at a time, with your own hands — and by the end you know what each piece is for.

Yes. We can work on organising a portfolio, on presenting your projects, or on finding out what AI can do inside the software you already use every day.

With a composer we built and published his portfolio site, and between sessions he started making his own changes. In the same work the AI was connected to his music software — so this is not limited to websites; it can run inside the tool you already work in.

The scope follows your own goal. The first thing we talk about is the work you want to do and the material you already have.

Pick one single job you want a result from, together with the examples you already have. Then get three things clear: who it is for, what information is missing, and what a good result would look like.

A generic answer usually comes from a generic question. In one-to-one work we take those questions through your own project — and in most sessions the first task is not getting the AI to make something, but getting it to ask you the right question.

The honest answer has two halves. Your work lives on your own computer and in accounts opened in your own name — GitHub, Supabase and so on — and you own those. The prompts you send to the AI are processed on the provider's servers, under the terms written in that provider's own agreement.

My rule in the sessions is firm: no real customer data, no passwords and no identity documents go anywhere near the development environment. Everything is done with demo data. If you are bound by a corporate confidentiality policy, talk to your IT team before we start.

No AI company can guarantee you otherwise, and that is the honest answer. Providers' data-use terms sit in their own agreements and change from time to time.

So here is the practical rule: if an idea is too valuable to share with anyone, do not type it into any cloud tool — not the AI, not any online service. Real protection comes from contracts and, where it matters, from registration. If you have a serious intellectual-property concern, I will point you to a lawyer rather than reassure you myself.

Legal responsibility always belongs to whoever publishes and operates the system. The AI is a tool, like your accounting software. I do not give legal advice — but there are two principles I apply in every session.

The first: no real personal data during development, everything built on demo data. The second: before anything goes live we go through access, identity and data-privacy settings together.

If you work in a regulated field — health, law, finance — we shape the architecture around the regime you actually fall under, whether that is GDPR in Europe, KVKK in Turkey or something else where you operate. The final compliance decision is one to make with your own lawyer.

Like any software, your system can technically be copied. That is just as true of the off-the-shelf software you might have bought instead.

Practical protection comes in three layers: your code repository stays private, access to the system is limited by role, and where it matters contracts do the rest. We build the first two together; for the third you should get legal help.

Plainly: no system is a hundred percent secure, and you should be suspicious of anyone who promises that. Code an AI wrote needs review like any other code.

The principle I work on is to look at your own system through the eyes of someone standing outside it. If you can see a hole, assume somebody else can see it too. Everything else follows from that: permissions are granted at the lowest level that works, passwords and keys never go inside the code, and what the AI did gets checked against the logs.

Security is not something you install once. It is a way of looking, and that is what I am trying to hand over.

Supabase is an open-source database service. Your data sits in an account opened in your name, on servers in a region you choose, and you are the sole owner of that account.

My rule is that you stay the owner of the system, always. Every account is opened in your name, your data stays in your account, and nobody — me included — can reach it independently of you. If you work with highly sensitive data we also talk through keeping it on your own server.

No. Repositories can be private, and the rule here is not negotiable: every project repository is private.

I cover this deliberately, because there is a real lesson behind it. In one group cohort a repository had accidentally been left public, and noticing and fixing it together turned into one of the more instructive moments of that workshop. What is open and what is closed gets decided together on day one.

The rule is short: never inside the code, never in a chat window.

Keys live in what is called an environment variable, and when the site goes live they go into the server's own secret settings. We do this together, step by step — and the list of places a key must never go matters at least as much as the place it does go.

Tools like Claude Code do not take consequential action on your machine without your approval; they stop and ask at the critical steps.

What I teach is granting those permissions consciously. We read each request together and understand what is being asked for and why. Control stays with you, and we do not take the shortcut of approving everything automatically.

Authority is granted in stages and fenced in with written rules. That is the base principle I teach.

The rule Emre Omay set for his own system:

"No deleting, no changing — only flagging."

«Silme yok, değiştirme yok — sadece işaretle.»

So you start by giving the AI permission to propose and to flag. Trust grows as you check the results — it is built by inspection, not by blind surrender.

No. The AI has no access to your bank account or your card. Every payment is made in accounts opened in your name, with your own card.

We open the subscriptions together in the session, and I show you where to cancel them when you want to. The tap stays in your hand.

A token is the unit the AI uses when it processes text. Think of the prepaid credit on an old mobile phone. In practice it is far less fiddly than that: on Claude's subscription plans (Pro, Max) you are not counting tokens one by one — you have an allowance that works inside rolling time windows.

I explain those windows and the differences between plans against your real usage, not in the abstract. We see which plan is enough for you in the first week, and I will not push you onto a higher tier you do not need.

Let me be honest: if you are building a serious system, a higher plan may well be needed. In Cüneyd Yuzak's own words:

"Of course we couldn't have done these things if I hadn't moved up to the higher package."

«Bu üst pakete geçmesem bunları yapamıyorduk tabii.»

But put that cost in the right place. The comparison is what a developer charges, not an idle subscription line on your statement. If work a developer would spend days on gets finished inside a session, the subscription has already paid for itself. And if your usage turns out to be low, I will tell you just as plainly to stay on the cheaper plan.

Bespoke software quoted by an agency is a serious line item and delivery is measured in months. I am not going to name a figure: quoting a number without knowing the scope of your work would be peddling hope, which is the one thing I try never to do. The work I do is priced by scope as well — that is why there is no price on this side of the site. We work it out once we both know what the work actually is.

What I can give you instead of a promise is a measurement. Emre Omay's is concrete: a presentation-preparation job that would take someone in his office two or three days took ten minutes with AI. Write the repeating jobs in your own week one under the other and you can do that arithmetic yourself — in the sessions we do it together.

Not for everyone, and I say so openly. It comes down to two things: does your work contain repetitive, done-by-hand, donkey-work tasks, and are you willing to hand them over? If both are yes, you will most likely see a clear gain in time within the first weeks, as most people here do.

But if you are coming with the expectation that AI will make money while you step aside, this is not for you — I do not make that promise. No hope-peddling: this asks for effort, and it returns the effort.

Yes. It gets transferred or pointed from whichever registrar it currently sits at, and we do that together, step by step.

That includes the detail everyone worries about — "will my email break if I move my domain?" — so we work through a checklist to make sure nothing goes dark during the switch. Cüneyd Yuzak's domain was connected to his own live system exactly this way while we were working.

Not usually. Most of what we build runs on its own publishing infrastructure — GitHub Pages, Cloudflare, Vercel — and does not depend on your existing hosting at all.

If you have an existing site, WordPress say, and the change has to happen there, we use routes that need no terminal. In the first session we look at what you already have and choose the path that fits it.

That is the entire point. I do not build it and hand it over; I teach you to build it. After launch, text changes, new pages and small edits are yours.

Filiz Cingi Yurdakul summed it up in three words:

"I pressed it and it did it."

«Bastım ve yaptı.»

If you still depend on me when the work is over, then I did my job badly.

No — we set up an automatic publishing flow (CI/CD): you save the change, and the system checks it and puts it live by itself.

Cüneyd Yuzak's live system works this way, and by his own account the whole operation now runs from it. How much automation a given project needs becomes clear in the sessions, measured against your own work rather than decided in advance.

Not necessary. For most jobs a web application is enough and it opens perfectly well on a phone.

If you want it to feel like a real app — its own icon, full screen — there is a mobile route too, and people I have worked with have produced apps running on their own phones.

Getting into the Play Store or the App Store is a separate process: a developer account, store review and annual fees. The right order is to start on the web and think about the stores only when a real need shows up.

It used to be true. It is not any more. In what is called a "serverless" setup, the visible part of the site is published statically while memberships, forms and databases are handled by secure services behind it.

That gives you systems that are both fast and easy to maintain. The CRMs and booking systems built in these sessions run on exactly this architecture.

Yes, and it is expected: AI works probabilistically. It is not a calculator returning an identical answer every time.

That uncertainty is manageable, and the method is what I teach. Have it plan the work before it does it, set written rules, make it test the result. What matters is not that every output is identical, but that you have a setup which tells you whether the result is correct.

The practical answer: -c (continue) resumes the last conversation where it stopped, and -r (resume) lets you pick an older one and go back into it.

An honest note: these tools change within weeks, so we verify the current form of the commands together in the sessions. What I am trying to leave you with is not memorised commands but how to look it up when something moves.

Technically possible — and deliberately something I leave until later. Moving to multiple agents before you can work healthily with one makes control harder, and this corner of the field is full of overblown promises.

Build your system with a single agent first and learn to inspect it with confidence. Once you are past that, I will show you how to build a team. Saying "no agent teams in this work" is not me underestimating you; it is me getting the order right.

Plainly: I am not one of the people who tell you to build it and you will definitely sell it. I say the same thing in the sessions — no hope-peddling here.

The overwhelming majority of the people I work with built their system for their own business, and that is where the real return sits: work that took days dropping to hours, follow-ups that were done by hand becoming automatic.

Building systems for other people and selling them is possible, but it is a separate business with its own skills — finding clients, running projects. See the value in your own work first and do not rush the rest.

Not a promise — evidence, and all of it named with the client's written permission:

Cüneyd Yuzak's Golden Visa consultancy runs a CRM that is live; by his own account the work of 31 real investors goes through that system. İsmail Bey's produce supply business in Brooklyn now takes its orders through the system he built himself rather than off paper lists. Filiz Cingi Yurdakul runs project tracking and staff hours for the architecture practice she manages alone on a system she built.

These are not "I made money" sentences. Naming a measured revenue figure would not be honest, because nobody measured one. They are systems that are live and that genuinely changed how the work runs. The full case studies are written up in Turkish and have not been translated yet.

I have spent months working with dozens of people from every kind of profession, and my observation is clear: professions are not disappearing, they are changing. In the hands of someone who knows their trade, AI is leverage. In the hands of someone who does not, it is a risk.

Emre Omay, who built an architecture firm over 25 years, has what I think is the healthiest frame of mind about it: "I'm not in panic mode." I say the same thing in every session. AI will not take your place; someone who uses AI well might. Learning instead of panicking is the smartest move available today.

I have seen the opposite. Emre Omay's sentence is the best answer I have:

"Bringing it into my routine work doesn't just speed things up, it makes them enjoyable. And then I become able to do the other things I was putting off out of reluctance."

«Yaptığım rutin şeylere dahil ederek sadece hızlanması değil, keyifli hale geliyor. O zaman üşendiğim, ertelediğim başka şeyleri yapabilir hale geliyorum.»

When the weight comes off, the postponed work gets done. I have not met anyone who got lazier; I have met plenty who were up past midnight with their own project — sometimes it falls to me to say do not get quite that attached.

These tools really do move fast — a screen I show you today can be out of date in six months. So I do not have you memorise menus; I teach method: ask the right question, have it plan, inspect the result.

And you are not left on your own afterwards. I stay in touch with most of the people I have worked with long after the sessions end, and I pass on what genuinely matters when something changes.

The truth: "I had the AI build it." That is not a confession, it is a competence.

You were at the wheel. You described the requirement, you approved the steps, you inspected the result. The AI wrote the code; you made the decisions. You can say it with pride rather than embarrassment — because you did what most people still cannot.