Fei Studio User Guide - Welcome

Last updated: June 29, 2026

Tell Fei Studio what you want. It already knows your app.

It reads your codebase components and flows before writing a single line. This guide shows your team how to work with it - no new expertise required.

Where it fits

Fei Studio sits in the gap between idea and code

Fei Studio slots into the moments your team already has. Here's what that looks like in practice:

Before sprint planning

You have rough tickets and customer feedback. Run them through Fei Studio to sharpen vague ideas into buildable specs - before planning kicks off, not after.

Mid-sprint request

Something comes in that needs to ship this week. Describe it in Fei Studio, review the result, send to dev. Your engineer gets a groomed PR instead of a Slack thread.

After a customer call

You heard something that needs to change. Open Fei Studio, describe the problem, iterate on the fix. You don't have to wait for the next sprint or the next design cycle.

Validating a design

You have a Figma frame or a mockup. Drop the link, tell Fei Studio what's new vs. what already exists in your app, and see it built in your actual codebase.

Fei Studio doesn't replace your designer, your ticket system, or your engineer. It eliminates the wait between idea and code.

The mental model

Talk to Fei Studio like a colleague

Think of it as a sharp new engineer who has read your entire codebase - your components, patterns, and conventions - but who has never met your users.

They know how your app is built. You supply the what and the why.

When planning

Talk to Fei Studio the way you'd talk to a PM or Designer. Think out loud. Describe the problem, the opportunity, the user need. It helps you figure out what to build.

When building

Talk to Fei Studio the way you'd talk to a dev. Describe what to build, where it goes, and how you'll know it's right. It handles the implementation.

Reviewing what Fei Studio built

Always in this order - variants first, then the live preview:

  1. Check variants first - Fei Studio builds all the states: loading, empty, error, success. You can't reach all of them from the live preview. Open the variants panel to see everything before you click through.

  2. Then review the live preview - Click through the app the way a user would. You're judging behavior and look, not code.

Your first change

Start small, see the loop

You don't need to read the whole guide before trying Fei Studio. Start with something small - a question, a copy fix, a single state. The goal of your first task is just to see how the loop feels.

  1. Ask a codebase question first
    "How does our login flow work?" - risk-free, no code written. You'll see immediately that Fei Studio knows your repo.

  2. Pick something small and visible
    A copy fix, a button state, an empty state. Something you can judge in thirty seconds.

  3. Send a short request
    What you're trying to achieve and where it lives. Three lines is plenty for a first task.
    💡 You don't need to wait. While Fei Studio is building, start your next task or switch to another one in progress. It will notify you when something is ready for review.

  4. Review what Fei built
    Check variants for all the states, then open the live preview. Give one round of feedback if needed.

  5. Send to Dev
    When the preview looks right, use Send to Dev. Fei Studio creates a groomed PR for your engineer to review - once they merge it, the change is live.

  6. Then scale up
    A real feature from your backlog, a Figma frame, or a full ticket - the same approach, just more of it.

Before you start: Build or Plan?

Before sending a request, ask yourself: do I know what done looks like?

Use Build when:

  • You know what the user should be able to do

  • You can describe the outcome and how you'll judge it

  • You know where it lives

  • You can describe the edge cases

Use Plan when:

  • You're still thinking it through

  • You have a problem or direction, but not a clear definition of done

  • You're not sure which screen it belongs on

  • You haven't thought through edge cases yet

💡 Rule of thumb: If you can't describe what 'done' looks like, start with Plan mode. Let Fei Studio help you think it through - then build from the spec it produces.

Day to day

Some tasks you can do in Fei Studio

Build a new component or screen (PM, Designer)

Build a [component name] for [where it appears].
States to handle: loading / empty / error / success
Reference: Figma link or screenshot
Track: key interactions to instrument

Ship a full feature (PM)

Goal: users should be able to [outcome].
Where: [page / flow], after [existing step].
Constraints: UX shape / scope / tradeoff.
Acceptance: [edge case 1], [edge case 2], works on mobile.
Track: key user actions and error states to instrument.

Fix something that's broken (PM, QA)

Bug: what's wrong.
Repro: step 1 → step 2 → wrong result.
Expected: correct behavior.
Trace the root cause and fix it without changing unrelated behavior.

Instrument a feature (PM)

Add tracking for [feature / user action].
Fire events for: key action 1, key action 2, and key error / edge case.
Follow our existing analytics pattern in similar feature or file.
Goal: answer the question "what we want to measure."

Ask how something works (Anyone)

How does [feature / rule] actually work in our app?
Walk me through the flow with references to the real code.
Example: "How is a user's discount eligibility calculated at checkout?"

Turn a rough idea into a spec (PM, Plan mode)

Here's a rough ticket: [paste].
Review it against our actual codebase. Flag missing edge cases, ambiguous logic, and anything that conflicts with how the app works today.
Return a complete spec I can hand back to you to build.

Improve a KPI (PM, Plan mode)

I want to improve [metric].
Current state: [what's happening now - number, funnel step, or user behavior].
Hypothesis: [what you think is driving it].
Constraints: [scope, what's off-limits].
Help me figure out what to build to move this number. Return options with tradeoffs.

Starting points

There's no single right way to start

Text works. So does a Figma link, a screenshot, a ticket, or a bug description. Fei Studio understands all of them - mix and match depending on what you have.

  • Text or plain description
    The most flexible starting point. Just describe what you want in plain language - goal, context, and what done looks like.

    • Example: "On the checkout page, let users save a payment method and reuse it next time. Empty state: 'No saved cards yet' with an add button. Flag expired cards in red. Works on mobile. Track save and delete events."

  • Figma file
    Drop the frame link. Call out anything that's a genuinely new pattern - everything else Fei Studio will match to what already exists in your codebase.

    • Example: "Build this screen from Figma: [link]. The header reuses our existing PageHeader. The pricing card is a new pattern - build it to match our Card styling."

  • PRD, ticket, or bug report
    Paste a Linear, Jira, or Notion doc as-is. Add a one-line goal and acceptance criteria so Fei Studio knows what done means. Works for bug reports too.

    • Example: "Implement this ticket: [paste]. Done = a user with no orders sees the new empty state; users with orders see the existing list unchanged."

  • Screenshot
    A competitor, an old mockup, or a whiteboard. Tell Fei Studio what to copy and what to adapt to your stack.

    • Example: "Recreate the filter bar in this screenshot in our app. Match the layout, but use our colors and our existing Button and Dropdown components."

  • Bug or broken behavior
    Describe what's wrong and how to reproduce it. Attach a screenshot if you have one. Fei Studio traces the root cause across the repo.

    • Example: "The cart total doesn't update when a coupon is removed. Repro: add coupon, remove it - total stays discounted. Expected: total reverts. Screenshot attached."

  • Ticketing issue (Coming soon)
    Paste a Jira, Linear, or Notion issue link and Fei Studio fetches it directly - no copying and pasting. Connect your ticketing system once and it can pull the full context, or help you explore your backlog for your next task.

Writing the request

What makes a great request

Think of these as helpful additions, not a template to fill out word-for-word. A short request is fine for small changes - Fei Studio asks when it needs more. The more you include, the fewer round-trips.

  • Goal - What you're trying to achieve.
    Describe it in terms of what users will be able to do. "Users can save a payment method and reuse it at checkout" rather than "add a save endpoint."

  • Context - Where it lives and why it matters.
    The page, the flow, or the trigger. Skip the stack - it already knows it.

  • Constraints - Deliberate choices that change what Fei Studio builds.
    Things it can't infer - UX shape, scope, tradeoffs. "No modal - keep it inline." "This is for the free plan only, don't touch anything behind the paywall." "No new network requests - use data already loaded on the page." "Mobile layout takes priority - desktop is just a wider version."

  • Acceptance - How you'll know it worked.
    The visible behavior, edge cases, and key user actions to track. "Empty state shows 'No saved cards yet.' Expired cards flag in red. Works on mobile. Track save and delete events."

  • Reference - Anything to anchor on.
    A Figma link, a screenshot, a similar existing screen, or a ticket.

Can't describe the acceptance? Switch to Plan mode first. If you don't know what done looks like, you have a planning task, not a build task.

Iteration

When the result isn't quite right

Fei Studio is built for back-and-forth. The review-feedback-adjust loop is expected, not a sign something went wrong. It notifies you when a task is ready - you don't need to watch it run.

  1. Start with variants
    Check all the states Fei Studio built - loading, empty, error, success. Variants show everything; the live preview only shows the happy path.

  2. Give feedback like a design review
    Be specific and visual - either by typing ("The save button should be primary orange, not gray") or by selecting elements directly and editing them in Fei Studio's select or edit mode.

  3. One change at a time when it's tricky
    For a stubborn detail, ask for one adjustment and re-check rather than stacking five changes into one request.

  4. Final review: open the live preview
    Click through the app the way a user would. When everything looks right, you're ready to send to dev.

  5. Send to Dev
    Fei Studio creates a groomed PR for your engineer to review. When your team leaves PR comments, it learns from them - it gets sharper every sprint.

Quick reference

Do this. Skip that.

Do:

  • Describe what you're trying to achieve

  • State your acceptance criteria

  • Include analytics events you want tracked

  • Point at existing patterns ("like our Settings page")

  • Attach references - Figma, screenshots, tickets

  • Check both variants and the live preview

  • Start with Plan mode when the task isn't clear yet

Don't:

  • Explain your stack

  • Dictate file paths

  • Bundle five features into one request

  • Paste code you don't need to

  • Skip the "done" definition

  • Treat the live preview as final without checking variants and iterating

"The best request is the one you actually send."

Start small, describe the outcome, and let Fei Studio do the rest. Every task makes the next one sharper.

Need help? Your Customer Success contact is one message away: Support@AutonomyAI.io