Marvel

Open marvelapp.com and sign in to your account. Create a new project by clicking + New Project. Choose whether you want to start from blank screens, upload images/screenshots, or use Marvel's built-in design editor to create screens from scratch. If you have existing designs in Figma, Sketch, or even handwritten sketches photographed on your phone, you can upload those as the background images for your Marvel screens. The most powerful feature of Marvel for FlutterFlow developers is the Hotspot tool. In Marvel's editing view, switch to Prototype mode and draw clickable hotspot areas over buttons, navigation items, and cards on your screens. Link each hotspot to a target screen using the arrow connector. When you preview the prototype on your phone (or share the link with others), tapping a hotspot navigates to the linked screen—simulating real app navigation without any code. Spend time getting the prototype right: show it to at least 5 people who represent your target users. Watch them tap through without guidance. Note where they get confused, what they expect to tap that isn't a hotspot, and what information they ask for that isn't on screen. Each confusion point is a design decision you should make before building in FlutterFlow, because rebuilding UI in FlutterFlow is much faster than rebuilding after user-testing reveals fundamental flow problems. Once you have validated the prototype and made revisions based on feedback, you are ready to use it as a specification for FlutterFlow. Document which screens exist, what navigation links where, and which design decisions are confirmed. This document becomes your FlutterFlow build checklist.

With a validated Marvel prototype in hand, open your FlutterFlow project and begin recreating each validated screen as a real Flutter widget tree. This is the core of the Marvel-to-FlutterFlow workflow—and the key insight is that nothing carries over automatically. Every layout, color, spacing value, font, and interaction must be built by hand in FlutterFlow. To get the exact measurements from Marvel, open a screen in Marvel's editor and look for the Inspect panel or Developer Handoff view (available on some Marvel plans). This shows you exact pixel dimensions, font sizes, hex color codes, and padding values for each element. If your Marvel plan doesn't include the Inspect view, you can reference the visual design and use your eye—or export the screen as an image and use it as a background reference image in FlutterFlow while you build. In FlutterFlow, build each screen top-to-bottom, outside-in: 1. Start with the overall layout (a Column or Stack). 2. Add the app bar / header (use FlutterFlow's AppBar widget). 3. Add the main content area (another Column or ListView for scrolling content). 4. Add individual card components using Container widgets with padding and border-radius. 5. Add Text widgets with font sizes and weights matching your Marvel screen. 6. Add Buttons and Image widgets last. Pay special attention to FlutterFlow's Theme settings (Settings & Integrations → Theme Settings). Set your primary and secondary colors to match the hex colors in your Marvel design. This ensures all default widget colors (AppBar, Button, etc.) automatically match your validated design without manual color-setting on each widget.

One of the most valuable parts of your Marvel prototype is the navigation map—which screen appears when you tap a specific button, card, or menu item. In Marvel, this was defined by hotspots. In FlutterFlow, it is defined by Navigate-To Actions in the Action Flow Editor. For each interactive element in your Marvel prototype that linked to another screen, add a corresponding action in FlutterFlow. Select the button or tappable Container widget in your FlutterFlow screen. Open the Action Flow Editor (click Actions in the right panel, then + Add Action). Choose Navigate → Navigate To and select the target page from the dropdown. If Marvel's hotspot linked back to the previous screen (a 'Back' gesture), use Navigate → Pop (Go Back) in FlutterFlow. If Marvel showed a modal or bottom sheet, use Navigate → Show Snack Bar or a Navigate To page with a Bottom Sheet Page Transition. Create a systematic list from your Marvel prototype: 'Tapping X on Screen A → navigates to Screen B.' Work through every hotspot in Marvel and implement each as a FlutterFlow Navigate-To Action. When you have completed all navigations, test the FlutterFlow app in Run mode—you should be able to tap through the app following the same paths a user tapped through in the Marvel prototype. This parallel between Marvel hotspots and FlutterFlow Actions is the conceptual bridge between the two tools: Marvel defines the intent, FlutterFlow implements the reality. The navigation should feel identical to users who tested both versions.

This step is optional and advanced—most teams using Marvel with FlutterFlow will not need it. It is useful only if your team wants an internal 'design reference' screen inside the FlutterFlow app that lists Marvel project screens by name. To set this up, first get a Marvel access token. Log in to marvelapp.com, go to your Account Settings, and find the Developer section or API access area. Generate an access token. Note that Marvel's REST API documentation and base URL should be verified at Marvel's developer portal—the API endpoints and authentication method may have changed, so treat the Marvel API as optional and flag base_url and rate_limit as 'verify at Marvel's developer docs' before relying on them. In FlutterFlow, click API Calls in the left navigation → + Add → Create API Group. Name it Marvel and set the Base URL to Marvel's API endpoint (verify the current URL in Marvel's API documentation). Add an Authorization header with your access token in the format Marvel's docs specify. Add an API Call to list screens or projects for your team. Test it in the Response & Test tab. If you receive a valid response with project/screen metadata, generate JSON Paths and bind the data to a simple ListView on an admin-only internal screen. If the Marvel API returns CORS errors in FlutterFlow's web build or browser preview, this is expected—route the call through a Firebase Cloud Function proxy if you need web support. For a native mobile-only internal tool, CORS is not an issue.

1// Marvel API Group config (verify base_url and auth format at Marvel's developer docs)
2{
3  "group_name": "Marvel",
4  "base_url": "https://marvelapp.com/api/v1",  // Verify current URL
5  "headers": {
6    "Authorization": "Token YOUR_MARVEL_ACCESS_TOKEN"  // Verify format
7  }
8}
9
10// JSON Paths to try after testing (verify field names in live response):
11// $.results[:].id         → screen/project IDs
12// $.results[:].name       → screen/project names
13// $.results[:].thumbnail  → thumbnail image URL

The final step in the Marvel-to-FlutterFlow workflow is a deliberate parity review: compare every screen you built in FlutterFlow against the corresponding Marvel prototype screen to ensure nothing was lost in translation. Conduct this review screen by screen using a checklist: - Does the layout match (columns, rows, card arrangement)? - Do the colors match the validated palette from Marvel? - Are the font sizes and weights correct? - Is the spacing (padding, margins) consistent with the Marvel design? - Does every interactive element have the correct Navigate-To Action? - Are there any screens in Marvel that you have not yet built in FlutterFlow? If your Marvel plan includes a User Testing or Comments feature, look through the comments left by stakeholders during prototype review and confirm each piece of feedback has been addressed in your FlutterFlow build. Once the parity review is complete, update your FlutterFlow app's Theme Settings with any final color adjustments, typography settings, and border radius values that make the visual design consistent across all screens. Run the app on both iOS and Android simulators/devices to check for layout differences—especially around safe area insets on notched phones. At this point, your validated Marvel prototype has served its purpose: it defined what to build, saved you from building the wrong thing, and gave stakeholders a chance to approve the design before significant development investment. You can continue to update the Marvel prototype for new features in future sprints, repeating the same validate-then-build cycle.