HOW TO BUILD REAL SOFTWARE WITHOUT WRITING A SINGLE LINE OF CODE

Last weekend our team built a working trading platform from scratch. Nobody on the team writes code. Nine hours, start to finish.

This guide covers the exact setup we used. It applies to anything you would pay a developer to build: internal tools, automations, bots, websites, dashboards.

Two tools inside the same app, each doing a completely different job.

Talking directly to a coding AI puts you in the project manager seat. You end up reading its output, catching mistakes, making technical calls. If you are running a business, that is a bad use of your time.

This setup keeps you on the business side the entire time. Two tools split the work between thinking and building.

The shared workspace is a Google Drive folder that acts as Claude's long-term memory. Every Cowork session reads from it when starting and writes to it when done. Decisions get logged. Work gets tracked. Your colleague can pick up exactly where you left off.

You will create the folder, connect Cowork to it, and have Claude generate the files it needs to operate as a team workspace.

Next, connect Cowork to the folder. Open the Claude desktop app and go to Cowork mode. When it asks you to select a folder, navigate to the Google Drive folder on your computer and select the shared folder you just created.

Now have Claude create the instruction files. In the Cowork chat, paste this prompt:

Create the following files in this folder:

1. A file called CLAUDE.md with these instructions:
- This is a shared workspace used by multiple people. Any person may open a Cowork session at any time. Treat every file as potentially created or edited by someone else.
- Anything important that comes up in conversation (decisions, ideas, context, reasoning, open questions) must be saved to a file. Conversations disappear when a chat ends. Files are the only shared memory between sessions.
- At the start of every session: read _project-log.md and _open-items.md, then brief the user on the current status.
- At the end of every session where meaningful work was done: update _project-log.md with who was working, what was done, what decisions were made, and what needs to happen next. Update _open-items.md with any new items or resolved items.
- When the user makes a decision or states a preference, save it to _decisions.md in the relevant subfolder with a date.
- Keep the root folder clean. Work goes in subfolders organized by project or topic.
- Use clear, lowercase folder names with hyphens (like marketing-plan or client-research).
- Before creating a new subfolder, check if a relevant one already exists.
- Never overwrite a file without reading it first.
- The users of this workspace may be non-technical. Keep language simple and clear.

2. A file called _project-log.md that starts with a header "Project log" and today's date as the first entry saying the shared workspace was created.

3. A file called _open-items.md that starts with a header "Open items" and is empty below that.

Confirm when all three files are created.

Claude creates the three files. You should see it confirm that CLAUDE.md, _project-log.md, and _open-items.md were all created.

Test it. Open a fresh Cowork chat, select the same shared folder, and type:

Read the CLAUDE.md file and summarize what it says. Then check the project log and tell me the current status of the workspace.

Claude should describe the workspace rules from the CLAUDE.md file and mention that the workspace was just created. If it does, the shared workspace is ready.

Open Cowork in the desktop app. Describe what you want in plain language. What the thing should do, who it is for, how it fits into your business.

Cowork asks clarifying questions until the scope is clear. Once you are aligned, say:

Cowork produces a spec, which is a detailed set of instructions that tells Claude Code exactly what to build, how to structure it, and what to do when it is finished. Cowork writes this. You do not touch it.

Copy the full spec.

Go back to Cowork. Paste the handback along with any thoughts you have:

Cowork reads everything, reviews the actual code, and figures out what happens next. If something needs fixing, it writes a revision spec. If the current piece is solid, it moves on and writes the spec for the next feature.

Either way you get a new spec to paste. Back to step 5.