Day 1
What Base44 is best at
Understand the sweet spot: internal tools, CRMs, trackers, portals — apps that are mostly data plus workflow.
Concepts
- · You describe the app; Base44 generates the interface, database and backend together
- · Built-in database, user accounts and hosting mean no separate services to configure
- · Best fit: internal operations tools, dashboards, intake forms, lightweight client portals
- · Weaker fit: heavily custom consumer front-ends and pixel-exact marketing sites
Exercise
Write down one process at work that currently lives in a spreadsheet and email chain. Build the first version of it as a Base44 app in a single prompt.
Try this prompt
Build an internal app for [team] to manage [process]. Track [main record] with fields for [fields]. Staff need to [action 1] and [action 2], and managers need to see [overview].
Mastery signal: You can say in one sentence which of your work problems Base44 is the right tool for — and one it isn't.
Day 2
Entities: getting your data model right
Fix the data model early, because everything downstream — views, permissions, reports — depends on it.
Concepts
- · Entities are your tables; fields have types that affect how the UI renders them
- · Relationships between entities (a task belongs to a project, a project belongs to a client)
- · Status and category fields drive filters, boards and dashboards later
- · Renaming and restructuring is cheap now and expensive after you have real records
Exercise
List every field your process actually needs on paper first. Then prompt Base44 to reshape the entities to match, including relationships.
Try this prompt
Restructure the data model: [Entity A] should have fields [list], and each one links to a [Entity B]. Add a status field with the values [list]. Update the existing screens to match.
Mastery signal: You can draw your app's entities and their relationships from memory.
Day 3
Screens, views and workflow
Shape the interface around how people actually work, not around your table structure.
Concepts
- · List, board, calendar and detail views suit different jobs
- · Filters and saved views beat asking users to search every time
- · Forms should ask only for what's needed at that step
- · One clear primary action per screen keeps the app usable for non-technical staff
Exercise
Walk through the process as the person who'll use it daily. Add or change one view per friction point you hit.
Try this prompt
Add a board view of [entity] grouped by status, with filters for [field] and [field]. Make [primary action] the obvious main button on that screen.
Mastery signal: Someone can complete the core task without you narrating what to click.
Day 4
Users, roles and permissions
Make sure people see exactly the records they should — and nothing more.
Concepts
- · Built-in authentication handles sign-up and login for you
- · Roles (admin, manager, staff) drive what's visible and editable
- · Record-level rules: users see their own records, managers see the team's
- · Test permissions with real second accounts, never by assuming
Exercise
Create a manager role and a staff role. Sign in as each and confirm the boundaries hold in both directions.
Try this prompt
Add roles: admin, manager and staff. Staff can only see and edit [records] they created. Managers can see everything for their team. Admins can see everything and manage users.
Mastery signal: You logged in as a staff account and could not reach data you shouldn't see.
Day 5
Integrations and automations
Connect the app to the rest of your stack so it stops being an island.
Concepts
- · Built-in integrations for email, file uploads, and AI-powered fields
- · Automations: send a notification, update a field, or generate a summary when something changes
- · External services via API when there's no built-in option
- · Keep credentials in the secure secrets area — never in a prompt or a visible field
Exercise
Add one automation that saves a real human step — an email on status change, or an auto-generated summary field.
Try this prompt
When a [record] changes status to [status], send an email to [role] with the record details. Also add an AI-generated one-line summary field on each [record].
Mastery signal: At least one manual step in your process has disappeared entirely.
Day 6
Publishing and onboarding real users
Get it in front of colleagues and survive first contact.
Concepts
- · Publishing makes the app reachable; invited users sign in with their own accounts
- · Custom domains on paid plans give it a credible internal address
- · Seed a little real data before you invite anyone — empty apps feel broken
- · Watch the first session in silence and take notes instead of helping
Exercise
Invite two colleagues, seed ten realistic records, and log every question they asked in the first ten minutes.
Try this prompt
Add a short onboarding screen for first-time users explaining what this app is for and the three things they'll do most often.
Mastery signal: A colleague used the app unaided and their feedback was about the process, not the interface.
Day 7
Credits, maintenance and knowing the limits
Keep the app alive and affordable after the initial build.
Concepts
- · Message-based credit usage: planning before prompting is the main saving
- · Batch small refinements rather than sending them one at a time
- · Export or back up important data regularly
- · Honest limits: very high traffic, complex custom logic, or strict compliance needs will eventually outgrow it
Exercise
Write a one-page maintenance note: who owns the app, what to do when it breaks, and what data gets backed up.
Try this prompt
Review this app and list what's fragile or missing before more people rely on it — prioritised, with the smallest fix for each.
Mastery signal: Someone other than you could keep the app running for a month using your notes.