Building with code — without fear
For four chapters you learned the tools: me, the request, flows and the workshop. In this one we build real things with them. By the end you'll have three: a site that's live, your own CRM holding your clients, and FYOS — the personal operating system that knows you and works for you. We'll write code; but I'll be the one writing it, and you'll say what you want and learn to read what comes back.
By the end of this chapter
- You'll recognise a web page's three layers — skeleton, look, behaviour
- You'll know what programming languages are and which one is for what
- You'll have built a page from zero and put it live at a real address
- You'll tell apart where data lives — file, spreadsheet, database
- You'll build your own CRM and connect your site to it
- You'll understand why a key never goes in the browser, and what a proxy is
- You'll see FYOS's four layers and how to build your own version
Contents
01Code fear, and the code you've already written
You've said «I don't know how to code» many times in this course, and every time you went on to the next step anyway. In the workshop chapter you had a file created, had three places changed on a page, read the diffs and saved. Those plus and minus lines were code. You read it, approved it and understood it was right. So you've already started reading code.
In this chapter we take one more step: we won't only change something that exists, we'll build something from zero. The frightening part is always the same: staring at an empty file, not knowing what goes in it. That part is mine. Your part is knowing what you want, seeing the result and being able to say «that bit is wrong».
An honest limit: you won't be a professional developer by the end of this chapter. What you will be is more useful — someone who can say what they want and inspect what comes back. That's eighty percent of the work in software anyway; for the remaining twenty there's either me or a specialist.
Do this now: Write down three things you'd like to build. A page, a list, a calculator, a client book — whatever. In this chapter we'll actually build at least one of them.
02Three words: HTML, CSS, JavaScript
In every chapter three words opened the whole field. Three do it for the web too — and they split the way you'd describe a person: skeleton, appearance, behaviour.
All three count as languages but they're not the same kind. HTML is a markup language: it says «this is a heading, this is a paragraph». CSS is a style language: it says «headings should be gold». Only JavaScript is a real programming language: it decides, repeats and calculates.
Do this now: Right-click an empty spot on this page and choose «view page source». What you see is this site's HTML. You don't have to understand it; just look. It isn't frightening, it's a repeating pattern.
03A site is really a folder
The word site suggests something big. It isn't. A site is a folder with files in it. The browser reads one file from that folder and draws it on screen. The «the folder is my desk» sentence from the workshop chapter applies here word for word.
- ajans-sitethe site itself
- index.htmlhome page — the file opened when you visit the address
- iletisim.htmlsecond page
- cssappearance goes here
- style.css
- jsbehaviour goes here
- main.js
- imgimages
Open that folder on your computer and double-click index.html and the browser opens it. No internet needed. That's the first half of «building a site»: a folder with files in it. The second half is putting that folder somewhere everyone can see — section six.
Do this now: Create a folder called «first-site» on your computer. Leave it empty for now. We'll fill it in section five.
04Programming languages, in human language
A programming language is the written form of telling a computer what to do. Like human languages it has grammar and vocabulary; the difference is that it accepts no ambiguity. You can't say «sort that out at some point»; you say «take this list and for each row do this».
There are hundreds of languages but you don't need all of them. For an agency, almost all of the work falls into three families:
A relief: the choice of language matters far less than you think. You could do the same job in five of them. What matters is saying clearly what you want to do — it's no accident that the rule from the formula chapter applies here unchanged. A badly described job comes out badly in every language.
Do this now: Describe one of the three things from 01 to me and ask: «which language makes sense for this, and why?» Read the reasoning in my answer — see how a language gets chosen, on one example.
05Your first real page, in fifteen minutes
Enough theory. Open the Claude Code you installed in the workshop chapter, go into the «first-site» folder and start talking. The five steps below produce a real page.
- 1Type claude in the folder. Then ask: «Build a one-page site in this folder: a heading, an intro paragraph, three service boxes and contact details. Dark background, plain. Make a plan first.»
- 2Read the plan and correct it. «Four boxes instead of three», «add a phone number too». The plan changes without a file being touched; it gets right before the work starts.
- 3Approve. The files appear: index.html, css/style.css, maybe js/main.js. Ask me to show you each one and skim them — get to know the shape even if you don't understand it.
- 4Open it and look: double-click index.html in the folder. The browser shows the page. For the first time you're looking at something you built.
- 5Change it: «make the heading say this», «change the colour of the boxes», «make the phone bigger». Refresh the browser each time. This loop — ask, look, fix — is the whole job.
If you forget to refresh the browser at the fourth step you won't see your change and you'll say «it didn't work». That's the most common first mistake. Make hitting refresh a habit.
Do this now: Finish the five steps today. The page can be ugly, it doesn't matter. What matters is that what you asked for is sitting in your folder.
06Go live: an address the world can see
The page in your folder is yours alone. Publishing means copying that folder onto a computer everyone can reach. The easiest and free way is GitHub Pages: the git save points from the workshop chapter were for exactly this.
The address arrives as yourname.github.io/project at first, and that is a completely real address — https included. If you want your own domain (agencyname.com) it's connected later; you don't rebuild the pages, only the address changes.
Publishing is the biggest threshold in this chapter and the most avoided step. Don't avoid it. A site that isn't live is an unfinished site; and if you publish on day one you see every change at the real address — the sentence «it worked on my machine» never gets said.
Do this now: Tell me «push this folder to GitHub and publish it with Pages, showing me the steps». I'll stop where you need to create an account; we'll do the rest together. Once you have the address, send it to someone.
07Static or dynamic
The site you published is static: the files sit there ready and everyone is shown the same thing. There are also dynamic sites: the page is produced for you at the moment you open it — a logged-in user, a personal list, live stock. Knowing the difference answers «can we do this» up front.
A brochure site, a portfolio, a blog, a course page. Hosted free, very fast, almost never breaks and has nothing to attack. This entire site is static.
Member login, a basket, a personal dashboard, live data. Needs a server and a database; brings a monthly cost, maintenance and a security responsibility. Don't go there unless you really need to.
Good news: there's a middle road between the two, and it's the one this course prefers. The site stays static; the one or two dynamic jobs you need (saving a form, asking the AI) go to a small proxy. You get as much as you need without carrying everything that's expensive. We'll build the proxy in section twelve.
Do this now: Sort your three ideas from 01 into these two columns. If anything lands in dynamic, write next to it: is it really necessary, or would static plus a small proxy do?
08Where data lives
As soon as you start building something, this is the first question: where will the client list live? There are three tiers, and most people pick a heavier one than they need and struggle. The right answer is usually the lightest.
- File A text or table file in the folder. Perfect for one person, a few hundred rows, data that doesn't change often. service list · prices · content
- Spreadsheet A cloud spreadsheet. You and your team can see and fix it by hand; flows can write to it too. The most practical place to start. clients · jobs · follow-ups
- Database Thousands of records, many people at once, complex queries. Powerful but needs setup and maintenance; this is where SQL comes in. when you grow · dashboards · reports
Do this now: Where do you keep client details right now? Phone contacts, message inbox, a notebook, a spreadsheet? Write it down — in the next section we'll pull that scatter into one place.
09Your own CRM: what it holds, what it does
CRM is three intimidating letters but it spells something simple: customer relationship management. In practice it's one place that answers «who did I talk to, what did I promise, when do I need to get back to them». Ready-made CRMs exist and most of them are ten times what you need; when you build your own you get exactly what you'll use.
- name
- contact
- where from
- status
- what job
- amount
- stage
- whose
- date
- what was said
- who wrote it
- when
- what to do
- done?
Notice: there's no «software» here at all. Four records and the links between them. You could build this as four sheets in a spreadsheet or four tables in a database. First you decide what you'll hold; where to hold it is the second question.
Do this now: Write the fields of these four records for your own work. Which field will actually get used in your business? Delete the ones that won't. A short list is a good CRM.
10Building the CRM: step by step
We start with a cloud spreadsheet as the data tier — the middle tier from section eight. The reason is simple: you can see it and so can your team; and moving to a database later is easy.
- 1Open a new cloud spreadsheet and create four sheets: People, Jobs, Notes, Reminders. Set the columns from the fields you wrote in 09.
- 2Add an id column to each record. The «person id» in the Jobs sheet says which person that job belongs to. That's all a link is; one column.
- 3Enter three clients, three jobs and a few notes by hand. Fill it with real data — a system built on imaginary data trips over the real thing.
- 4Have me write a dashboard: «Read this spreadsheet and make a one-page dashboard showing the clients I need to get back to today.» With the flow from the agent chapter it reads the sheet and shows the page.
- 5Automate the reminder: a flow that messages you today's reminders every morning at nine. The schedule trigger from the agent chapter, connected to a real job here.
Watch the order: data first, then the dashboard, automation last. Everyone who does it backwards — building the shiny dashboard first and thinking about data later — starts over two weeks in. If the data is right, the rest is easy.
Do this now: Finish the first three steps today. Fill the spreadsheet with your real clients. Four and five tomorrow; the spreadsheet works on its own even without a dashboard.
11From form to CRM: connecting the site
Now you have two pieces: a live site and a full CRM. The gap between them is one thing — a form on your site. When someone fills in the form on your site you want the details to land straight in the CRM.
- 1A visitor fills in the form on your site
- 2The form goes to your flow's webhook address
- 3Me: I read the message and classify it
- 4A new person and job row is added to the CRM
- 5A notification to you: «new enquiry, about this»
A static site not being able to save a form isn't a problem: the form sends the details to your flow's address. The site stays static, the work happens in the flow. That's exactly the «middle road» I mentioned in section seven.
Do this now: Have a three-field form added to your site: name, contact, message. Then open a webhook in your flow and connect the form to it. Fill in your own form; watch the new row appear in the CRM.
12A key never goes in the browser: the proxy
You want to put me on the site: a visitor asks something, I answer. The first solution that comes to mind — writing the key into the site's code — is the most dangerous one. Because everything that reaches the browser can be read by everyone. Your key becomes visible and gets spent on your bill.
«Proxy» sounds big; it isn't. It's a hundred-line program that lives on free tiers. This is the internet form of the workshop chapter's «keys don't go in the brain» rule: a key always sits in a vault you control, never on a visitor's computer.
Do this now: Look at all the flows and pages you've built: has a key been written anywhere the browser will see? If you're not sure, ask me — «is there a secret leaking out of this file?»
13Putting a talking box on the site
With the proxy ready, putting me on the site is short work: a text box, a send button and an area that shows the answer. But three decisions are needed to make it work well — and none of them is technical. They're yours.
What it will know
Your services, your price range, how you work, the frequently asked questions. You write these as a text and attach them to every request — the «context» from the formula chapter is exactly what pays off here. And you state its limits so it doesn't invent what it doesn't know.
What it won't do
It won't quote a firm price, won't make promises, won't commit to a date. Those are your job. The box's job is to greet, understand and ask the right question — then bring you in.
When it will call you
When the visitor gets serious: «can I get a price», «when could we start». At that moment the chat turns into an enquiry, lands in the CRM and a notification reaches you. That's the talking box's real job; not chatting, but bringing work in.
One more limit: whatever a visitor types into the box reaches me as data, not as instructions. The hidden-instruction warning from the chapter about me matters far more on a live site — a visitor typing «forget your previous instructions» must not be able to change the box's rules. Keep the constraints in the proxy, not in the browser.
Do this now: Write what the box needs to know on one page: services, how you work, five common questions and their answers. That text becomes the box's brain — the visitor-facing version of the workshop chapter's CLAUDE.md.
14What FYOS is
So far we've built pieces: a site, a CRM, flows, a talking box. FYOS isn't the name of those pieces; it's the name for all of them being reachable from one place. A personal agentic operating system means each of your daily jobs has an agent, and you talk to all of them from a single place.
The FYOS box on the home page is a small demonstration of this. In the real version the satellites are wired to your data: your calendar, your clients, your files. You ask «who's waiting on me this week?»; the core looks at the CRM, looks at the calendar and answers.
Do this now: Split your daily work into six headings. It may or may not look like the six above. What are your six satellites? That's the draft of your FYOS.
15FYOS's four layers
Building your own version means laying four layers in order. Don't break the order; each one rests on the one before.
Data
Your CRM, your files, your calendar. Everything FYOS knows comes from here; a system built on empty data gives empty answers. You already built this layer in section ten.
Hands
Flows and tools: the parts that read, write and send the data. The nodes from the agent chapter and the skills from the workshop chapter live in this layer.
Mind
Me. The layer that understands the question, decides which tool to call and turns the answer into human language. It sits behind the proxy; the key stays there.
Door
Where you do the talking: a page, a messaging app, a phone screen. This is the last layer to build — and the least important. A door can be beautiful, but if there's nothing behind it, it stays empty.
The most expensive mistake in this chapter is starting from the fourth layer. Building a beautiful interface and then saying «now let's connect this to something» is building a house from the roof down. Data, hands, mind, door — that order isn't arbitrary.
Do this now: Mark the four layers for your own situation: which is ready, which is half done, which doesn't exist? Tell me the first empty one; we'll carry on from there.
16Cost, quota, and when not to write code
Everything you built in this chapter has a free tier: site hosting is free, the spreadsheet is free, the flow tool's starter plan is free, the proxy is free up to a hundred thousand requests a day. Money only goes on AI requests, and even there it's little. But there are two traps to know about.
If a ready-made tool covers ninety percent of the job, buy it. Invoicing, accounting, taking payments, calendars — these have mature, cheap tools. Whatever you build, you maintain forever; that isn't free.
When the job is specific to your business, when ready-made tools won't talk to each other, and when you can describe a repeating task. Your CRM, your dashboard and your FYOS are in this column — because none of them comes ready-shaped to how you work.
The second trap is the quota: free tiers have a limit and when you hit it the system stops quietly. That's why your proxy counts a daily allowance and your flows send failure notifications. The «breaking silently» rule from the agent chapter applies here too — set the limit in advance and know when it runs out.
Do this now: Set a monthly spending cap on the AI account you use. It takes five minutes and prevents the bill from one bad night. Then note the free-tier limit of every service you've set up.
17Five common mistakes
1 · Leaving publishing until last
The site that says «I'll publish it once it's finished» never gets published. Publish on day one, while it's ugly. Then see every change at the real address.
2 · Building the interface before the data
A shiny dashboard with no data behind it is an empty box. Build the data first and fill it with real records; a dashboard arrives in a day, data doesn't.
3 · Writing the key into the site
Everything that reaches the browser is public. The key sits in the proxy's vault. This one rule prevents the most expensive mistake in this chapter.
4 · Building your own when a tool exists
Don't set out to write accounting software. Building your own makes sense where the ready-made one falls short. Everything you build, you will look after for life.
5 · Accepting the output without reading it
I write the code but the responsibility is yours. See whether it works, read the diff, try it in the browser. «It's probably fine» slowly rots everything you build.
Do this now: Add these five to your project's CLAUDE.md. Especially 3 — turning that one into a hook is entirely reasonable, as we discussed in the workshop chapter.
18What everyone asks
Can you really build a site without learning to code?
You can, and you will in this chapter. But let me be honest: without ever reading code you can't manage it long term. The thing is, reading is far easier than writing, and you're already learning it by reading diffs. In six months you'll look at a file and say «this bit does that»; you can still leave the writing to me.
Why this, when site builders exist?
For a brochure page a site builder is a good choice and nothing to be ashamed of. The difference here is ownership: a site you build is a folder — it moves, it backs up, it connects to anything you like and has no monthly fee. Also, the CRM, flows and FYOS we build across this course don't fit inside a site builder. We build the site ourselves because it's the door to the real system.
If I break something, can I undo it?
Yes — git from the workshop chapter is exactly for this. Every save point is a place to return to. Even if the live site breaks you say «go back to the previous save point» and it's back to its old state within a minute. That's why I keep insisting you put everything you build into git.
What happens when my CRM grows?
When the spreadsheet starts to feel tight — usually a few thousand rows, or a few people working at once — you move to a database. The move is a day's work and you're not the one doing it: you export the data, have me set up the database, and change the address in your flows. Starting with a database now has no benefit at all; it only makes things harder.
How long does it take to build FYOS from zero?
Honest answer: a first working version in a weekend, a version that genuinely helps in a few months. But you're never holding something half-finished during that time — each layer works on its own. Your CRM is useful from day one; your flows start saving time in the second week. FYOS isn't a finish line, it's a system you keep adding to.
Can I sell what I build to a client?
Yes, and that's what the summit chapter is about. If you've built your own CRM, building the same for a client is three times faster the second time; flows export, the site becomes a template. The most valuable thing an agency can sell is the system it has tried on itself.
Do this now: If you got stuck somewhere while building, ask me — paste the error message or the text on screen exactly as it is. Reading errors is one of the things I'm best at.
19Exercises
1 · Build the page and publish it
Build your one-page site with the five steps in 05, publish it with the five steps in 06. Send the address to a friend.
Goal: to have something on the internet that you built, at your address.
2 · Fill the CRM
Build the four-record spreadsheet and fill it with your real clients. At least ten people, five jobs, ten notes.
Goal: for «who did I talk to» to have an answer in one place, for the first time.
3 · Connect the two
Add a form to your site, connect it to the CRM with a flow, fill in your own form and watch the row appear.
Goal: for what you learned in two separate chapters to merge into one working system for the first time.
4 · Build one satellite
Pick one of the six satellites you wrote in 14 and actually build it. Have it answer one question correctly: «who's waiting on me today?»
Goal: for FYOS to stop being abstract and become a real thing that answers a question.
Do this now: The first this weekend. The second next week. Three and four within the month. Don't break the order; the third can't be built without the first two.
20Test yourself
Answer it yourself first, then open it.
HTML, CSS, JavaScript — in one sentence?
HTML is the skeleton: what's there. CSS is appearance: how it looks. JavaScript is behaviour: what happens. Only the third is a real programming language.
What is a site?
A folder with files in it. The home page is named index.html. The browser reads a file from that folder and draws it on screen.
What does publishing mean?
Putting the folder on a computer everyone can reach. You save with git and push to a repository, turn on Pages; the address goes live with https and updates itself on every push.
The difference between static and dynamic?
In static the files sit ready and everyone gets the same thing; free, fast, doesn't break. In dynamic the page is produced for you when you open it; it needs a server, a database and maintenance. The middle road: a static site plus a small proxy.
Where does data live, and in what order?
File, spreadsheet, database — light to heavy. You only move up a tier when the one below gets tight. Most agencies get to hundreds of clients on a spreadsheet.
A CRM's four records?
Person, job, note, reminder. A person links to jobs; notes and reminders collect under the jobs. More than that becomes fields you never use.
Why does a key never go in the browser?
Everything that reaches the browser can be read by everyone; the key becomes visible and gets spent on your bill. The key sits in the proxy's vault; the proxy also counts the quota and answers only your site.
The real job of the talking box on the site?
Not to chat, but to bring work in: greet, understand, ask the right question, and when the visitor gets serious drop the enquiry into the CRM and call you. Quoting prices and making promises is not its job.
FYOS's four layers and their order?
Data, hands, mind, door. The order matters: even the most beautiful interface stays empty if there's no data behind it. You don't build a house from the roof.
When do you not build it yourself?
When a ready-made tool covers ninety percent of the job. In mature areas like invoicing, accounting, payments and calendars, buy the ready one. Everything you build yourself, you look after for life.
This chapter in one sentence
Open a folder, have a page built in it and publish on day one; keep the data on the lightest tier and fill your own four-record CRM; connect the two with a flow; always leave the key in the proxy's vault — and when you stack these pieces in the order data, hands, mind, door, the thing in your hands is called FYOS.
