Ruthless.

Novice · Understand your app · 6 min read

Understand your AI-built app: start with a map

Bring a small, safe description of your project to GetRuthless and learn what its main parts do before changing anything.

← All guidesNovice guidesBy Ruthless AI team

Beginner course · Lesson 1 of 6

Keep this guide beside your Ruthless chat. Copy one prompt, add the example it asks for and paste it into “Message Ruthless”. Nothing is sent until you choose to send it.

Open Ruthless in another tab ↗See all six lessons

The short answer

Start by asking GetRuthless to explain a small set of project information that you provide. It cannot see your building tool, project folder or private app by default. Your first useful result is a checked map of the app, with unknown parts clearly marked.

What you will learn

An AI building tool can produce a working app before you understand the pieces. This course helps you catch up without requiring a terminal, programming vocabulary or a fresh rebuild. We will follow one imaginary notes app: a person signs in, writes a note, saves it and reads their own notes later. You can follow the same steps with your own project.

A frontend is the part someone sees and uses: the sign-in screen, note editor and Save button. A backend does work away from that screen, such as checking who may save a note. A database stores information so it can be read later. Some projects combine these responsibilities or use a service for several of them. These jobs need not occupy separate folders.

Get information from your building tool safely

Open the tool where you built the app. Look for its project file explorer, README, project summary or an export view. A README is a document that often explains how a project works. You do not need to understand every file. Start with the visible top-level file and folder names and the README text. If the tool hides files, ask its chat for a read-only summary of the screens, storage, sign-in system and deployment setup.

Use this request in your building tool: “Describe this project for a beginner. List its screens, main folders, where data is stored and how sign-in works. Explain only; do not change files. Omit all credentials and private user data.” Review what comes back. Remove passwords, API keys, connection strings, access tokens, real notes and personal details before sharing. File names are often enough for a first pass; a secret configuration file is not needed.

Ask GetRuthless for a map, not an edit

Visit getruthless.io, sign in if needed and open chat. The model menu is labelled Choose model; select an available model. Paste the prompt below into Message Ruthless, followed by your reviewed summary. Read the complete message before pressing Send. Hosted chat explains your supplied material, not unseen files.

A good answer connects each visible action to an evidenced part of the project. It should say “unknown” when a folder name is insufficient. Do not let a confident description turn a guess about your database into a fact.

Try this prompt
Explain my app to a beginner. Do not change or propose rewriting files yet. I will provide a redacted project summary and file names. Map the visible screens, frontend, backend, storage and sign-in responsibilities. For every claim, name the supplied evidence or mark it as an inference. List missing information as questions, without asking for secrets. Then explain what probably happens when a user saves one item. My app information:
[Paste reviewed summary and file names here.]

Example: a notes app map

Example output: “The supplied README says this app stores notes in a database. The file NotesPage appears to display the editor and list. The saveNote function appears to send note text to a backend. I cannot yet tell how the backend checks ownership because that code was not supplied.” This is useful because it separates a document-backed fact, a tentative interpretation and a specific gap.

Check the answer beside your file explorer and README. Can you find the named screen? Does the document really name the storage system? If a file is missing, reply with the correction. Ask for one short file or function to inspect next, then review and redact it before pasting it. Never paste an entire project just to make an answer sound more certain.

Your first checkpoint

Write three sentences in your own words: what the user can do, what must survive closing the app, and what the map still cannot explain. Quiz: is a Save button proof that data reaches a database? No: it proves only that there is a visible control. The next lesson traces what that control actually does.

Keep a small learning note containing the checked map and its unknowns. In lesson two, bring that note plus the code behind one button, if available. That gives the next conversation reliable context without carrying every earlier message forward.

Common questions

Can I give GetRuthless my app address instead of files?

An address can explain which app you mean, but it does not grant access to its source, private pages or local development environment. Provide reviewed text or redacted source and state what you observed yourself.

What if my builder will not show the code?

Use its read-only project summary and describe the screens you can see. Ask GetRuthless to mark conclusions as tentative. You can still learn the responsibilities, but cannot verify hidden implementation details from a summary alone.

Sources & further reading

  1. GetRuthless chat
  2. GetRuthless privacy information

The example prompts and workflows are GetRuthless guidance. Source references support the concepts explained; they are not an endorsement of GetRuthless.

Put the guide into practice.

Open Ruthless and choose an available standard or abliterated model suited to your task. Copy a prompt above, add the context it asks for and check the result. You can compare models in the same workspace; see current pricing before sending requests.