Skip to main content

mini: Build

mini Build is in closed beta. You assign a ticket and optionally a Figma file. mini writes native code in your existing codebase, deploys to a real device, iterates until the implementation is correct, and opens a pull request.

How it works

1. Ticket

Connect your project management tool β€” Linear, Jira, Notion β€” or paste a task description directly. mini reads the ticket to understand what needs to be built, where it lives in the codebase, and what the expected outcome is.

2. Figma (optional)

Attach a design file if you have one. mini uses it as the visual spec, comparing its implementation against the design and iterating until the UI matches. If there is no Figma file, it works from the ticket description alone.

3. Build

mini writes code in your actual repository β€” not a sandbox, not a copy. It reads your project structure, dependencies, and existing patterns before writing anything. It generates native code for whichever framework you are using: Swift, Kotlin, Flutter, or React Native.

4. Test

After writing code, mini builds the app and deploys it to a real iOS or Android device in the cloud. It opens the app, navigates to the relevant screen, and verifies the implementation works β€” checking layout, interactions, and behavior. If something is wrong, it goes back to step 3 and fixes it. This loop continues until the feature works correctly on a real device. Not a simulator. Not a screenshot. A physical device running the same hardware your users have.

5. PR

When the implementation passes on device, mini opens a pull request. The PR is scoped to the ticket β€” no unrelated changes. Your engineers review it, request changes, or merge it through your existing workflow.

What it works with

Frameworks: Swift, Kotlin, Flutter, React Native. Existing codebases: mini is built for production codebases, not greenfield projects. It handles large, complex repositories including legacy Objective-C codebases and monorepos. Tickets: Linear, Jira, Notion, or direct input. Designs: Figma. Optional β€” useful when you have pixel-perfect specs, not required for every ticket. Code review: Pull requests go to GitHub. Your existing review process is unchanged.

Scope and limitations

mini works best on well-scoped implementation tickets: feature screens, UI components, cross-platform parity work, and bug fixes with a clear expected outcome. It is not designed for architectural decisions, technology selection, or system-level refactors β€” that work stays with your team. The scope of any individual ticket affects reliability. A ticket with clear requirements and a well-defined β€œdone” state will produce better results than a vague or open-ended task.

Real device testing

mini runs physical iOS and Android devices in the cloud β€” the same hardware your users have. It deploys the app, launches it, and interacts with it directly: tapping buttons, scrolling, navigating between screens, entering text. Emulators do not catch the full class of mobile bugs. Touch behavior, rendering on specific chipsets, performance under memory pressure β€” these surface on real hardware and are often invisible in a simulator. mini tests on actual devices for this reason. Your team does not need a device lab. Devices are cloud-managed by Minitap, or you can deploy on your own infrastructure β€” on-prem is available.

Get access

mini Build is in closed beta. Request access β†’