Designed it in Figma Make or Base44? Here’s how it becomes a real app.

A prototype made in Figma Make or Base44 is the best brief a developer can receive — better than a document, better than a call — if it was built to be one. The screens are real, the flows are decided, and every argument about layout has already happened. What it is not, yet, is the product: the thing that has to keep working when a hundred people use it at once, half of them on their phones, some of them trying to see data that isn’t theirs.

This guide is the workflow I use with clients who prototype first: how to prompt these tools so what you get is buildable, how to know when the prototype is actually finished, and exactly what to hand over so the real app matches what you designed.

What the prototype is — and what it isn’t

What you have after a good session in Figma Make or Base44:

• Every screen, in the right order, looking the way you want.
• The flows: what a user taps, where they land, what they see next.
• The decisions: which fields exist, what the empty state says, what the primary button does.
• In Base44’s case, a working database and login behind those screens, so it genuinely runs.

What a real product needs underneath that:

• A data model designed for the actual business — not whatever shape the first prompt produced.
• Permissions enforced on the server, so a user can’t reach another user’s records by editing a URL.
• Integrations with real accounts — payments, email, maps, calendars — including what happens when they fail.
• Every unhappy path: empty lists, slow networks, expired sessions, double-clicks, bad input.
• Ownership: a repository you control, a deployment you can repeat, hosting you can move.

How the hand-off works

1. 01

   You prototype every screen and flow

   Not just the happy path. The signup, the empty dashboard, the error when a payment fails, the settings page nobody enjoys designing.

2. 02

   You walk each flow and mark what is real

   Start to finish, as a user would. Note where the data is faked, where a button does nothing, where a role can see too much.

3. 03

   You hand it over with a short note

   The link, edit access, the list of flows, the data, the roles, the integrations, and what is real versus mocked. The checklist below is that note.

4. 04

   I audit the prototype

   I map the screens to a data model, the roles to permissions, the integrations to real accounts, and write down every gap — before building anything.

5. 05

   I build the real app, keeping your design

   Same screens, same flows, same words. Underneath: a proper backend, permissions on the server, integrations wired to real accounts, every state handled.

6. 06

   You test it against the prototype, then we ship

   Your prototype becomes the acceptance test. If a screen doesn’t match, that is a bug. You keep the repository, the hosting and the accounts.

How to write prompts that produce a buildable prototype

The tools are good. The difference between a prototype that becomes an app in two weeks and one that becomes a rebuild is almost entirely in how it was prompted. Eight rules.

1. One screen, or one flow, per prompt

Ask for the whole app in one go and you get a plausible average of every app the model has seen. Ask for one screen with its states, then the next, and each one gets full attention — and you can review each one before the next prompt builds on it.

2. Describe the user and the job, not the pixels

3. Name the data

4. Spell out the states

Every screen has at least five: empty, loading, error, success, and no permission. Prototypes built from happy-path prompts have one. Ask for all of them by name.

5. Say who can do what

Roles are the most expensive thing to add late. Name them in the first prompt that touches data: owner, staff, customer — and for each screen, who can see it and who can change things on it.

6. Reference screens you already have

“Same layout as the Orders screen, but for invoices” keeps the prototype consistent and stops the tool reinventing your navigation on every prompt.

7. Say what must not change

8. Use realistic data, including the awkward cases

Ask for sample data with long names, a customer with zero orders, an overdue invoice, a name with an apostrophe. The prototype will show you where the design breaks before a developer has to.

Prompt templates you can paste

Fill in the brackets. Keep each one to a single screen or flow.

Screen: [name]
Who uses it: [role], [how often], on [device]
Job to be done: [one sentence]
Shows: [field, field, field] sorted by [field]
Actions: [primary action] (who can do it: [roles]); [secondary actions]
States: empty ("[message]" + [action]), loading, error (message + retry), no permission
Consistent with: [existing screen]
Do not change: [anything already approved]

Flow: [name], e.g. "Book an appointment"
Starts: [screen + trigger]
Steps: 1) [screen: what the user does] 2) [...] 3) [...]
Ends: [screen + what the user sees as confirmation]
Data created or changed: [entity: fields]
What can go wrong at each step, and what the user sees: [step: failure → message]
Who can run this flow: [roles]

Change: [one specific change] on [screen]
Keep exactly as is: [list the things you have already approved]
Show me only the changed part when you are done.

Figma Make and Base44: what each is good for

They overlap, and plenty of people use both — the workflow above is the same. Where they differ, in practice:

• Figma Make starts from design. If you already have a Figma file, it can carry your visual language into a working prototype, and it is the stronger tool for getting look, feel and interaction exactly right. Treat its output as the definitive front-end reference.
• Base44 starts from the app. It gives you a database, login and hosting out of the box, so the prototype genuinely runs and you can put it in front of a few real people early. Treat its data and permissions as a first draft to be reviewed, not as the final backend.

Either way, the thing you hand to a developer is the same: screens, flows, data, roles, and an honest list of what is real.

Before you say “it’s done”: walk every flow

Sit down as a first-time user, on a phone, and go through each flow from start to finish. Tick each line only if it is true.

• Every flow has a start screen, every step, and an end screen with a confirmation
• Every list has an empty state, a loading state and an error state I have actually seen
• Every form shows what happens on bad input, and after success
• Every role has been tried: I know what a customer cannot see or do
• Every button does something, or is marked as ‘not built yet’ in my notes
• The data on screen is the real shape: real field names, realistic values, awkward cases included
• I have written down every place where something is faked, hard-coded or missing

What to hand over

This is the note that turns a week of guessing into a day of building. It fits on one page.

• The prototype link, with edit access (and the Figma file, if there is one)
• A list of every screen, in the order a user meets them
• A list of every flow: name, where it starts, where it ends
• For each entity, the fields — and which are required, and who can see each
• The roles, and for each one what they can see and change
• The integrations you need: payments, email, SMS, maps, calendar — with which provider, if you have chosen
• What is real and what is faked in the prototype (the notes from the walk-through above)
• Must-have for launch versus nice-to-have afterwards
• Devices: web only, mobile web, native app, or all three
• A launch date, real or aspirational, and anything it depends on

Mistakes to avoid

1. Prompting the whole app at once. You get an average app. Screen by screen, you get yours.
2. Designing only the happy path. The unhappy paths are where users actually decide whether to trust the product, and they are where the developer will have to invent your decisions if you have not made them.
3. Treating a running prototype as launched software. It runs; that does not mean it is safe, or that you own it.
4. Handing over a link with no notes. Every gap you know about and don’t write down costs a round-trip later.
5. Changing the design after the build starts without saying so. The prototype is the acceptance test. If it moves, the build has to move with it — say so early and it is cheap.

When to bring in an engineer

When the prototype walk-through above is done and you can see the gaps — that is the right moment, not before. You will get a clearer quote, a faster build, and an app that looks exactly like the thing you designed, because the design was finished before the engineering began.