Approaches Compared

Context

Why the approach you take matters

Studios approaching a mobile port often have a few options in front of them: do it internally with existing development resources, hire a generalist contractor, or work with someone who focuses specifically on arcade-to-mobile transitions. Each path involves different trade-offs.

This page isn't meant to argue that one path is always right. It's meant to lay out the meaningful differences clearly, so you can make a more informed decision about which approach suits your situation.

Side by side

Traditional approach vs. a considered one

Area	Common approach	Carryover's approach
Initial assessment	Work begins without formal review; issues surface during build	Dedicated feasibility review before any build work starts
Touch controls	Standard overlay applied; no deep consideration of the game's original input model	Remapped with the original control logic in mind; tested in a playable build
Scope transparency	Scope tends to expand; costs and timelines shift during the project	Fixed scope and fixed price per service; no surprises post-start
Problem discovery	Problems found late in development, where they're expensive to address	Problems surfaced early, where they're easier to decide about
Release prep	Store submission handled by developer without specialist input	Dedicated polish pass with performance review and store checklist
Documentation	Sparse; handover relies on tribal knowledge	Documented outputs at each stage; useful after the project ends

Distinctive elements

What a focused approach actually changes

The review stage

Most porting projects skip a formal assessment. Ours starts with one. It's the stage where the most consequential decisions get made — and most of the risk gets priced in or ruled out.

Scope per service

Each of our three services has a defined scope and a fixed price. You aren't paying for time and uncertainty — you're paying for a specific, described output.

Care for the original

We start from a position of wanting to preserve what the game is, not normalize it for mobile conventions. That starting point tends to produce ports that still feel like the game.

Outcomes

How different approaches tend to resolve

Without upfront review

Control issues found late, after build work is done
Pacing problems that weren't anticipated for short sessions
Budget overruns as scope expands to address surprises
Store rejections from checklist gaps during submission

With a structured approach

Key complications identified before the build phase
Touch controls tested in a real playable output
Fixed pricing with no scope creep mid-project
Store prep handled with a proper checklist before submit

Investment

What you're paying for, and what it replaces

The upfront cost of a feasibility review ($240) is small compared to the cost of mid-build rework when a port direction turns out to be problematic. A review is effectively a risk-reduction purchase before any significant development spending begins.

Similarly, a Polish Pass ($360) before submission is cheaper than a store rejection that delays launch — and cheaper still than performance complaints after release that require a patch cycle to address.

Feasibility Review

$240

A clear picture before committing to build work. Usually worth multiples of its cost in avoided rework.

Touch Adaptation Build

$700

Full control remap, layout work, and a playable test build. The core of the porting work.

Mobile Polish Pass

$360

Performance notes, text guidance, and store prep checklist. A careful second look before release.

The experience

What working with us actually looks like

1

You send a message

Tell us about your game — what it is, what platform it's on, and what you're hoping to achieve. No form to fill out, no intake questionnaire. Just a note.

2

We review and respond

We read it and give you an honest first impression — usually within a couple of days. If the project isn't a fit for what we do, we'll say so. No obligation either way.

3

Work proceeds on a clear basis

If you'd like to move forward, we agree on which service fits, confirm the scope and price, and begin. Deliverables are defined in advance. Nothing is vague.

4

You receive documented output

Every service ends with a clear deliverable — a report, a build, a checklist. Something you can share with your team and refer back to later.

Long-term

How results hold up over time

Rushed ports tend to accumulate debt

When control issues, performance problems, or store compliance gaps aren't addressed early, they become ongoing maintenance. Players notice; the ratings reflect it; fixing things post-release costs more than it would have pre-release.

The pressure to ship quickly is real, and we're not dismissing it. But a project that ships clean tends to stay clean — and that's worth something over time.

What a careful port carries forward

Documentation that helps future developers understand decisions made
Performance foundations that hold under OS updates
Controls that players don't have to consciously adapt to
A store presence that doesn't require reactive patching

Common questions

Things worth addressing directly

"Can't an in-house developer handle this?"

Often yes — but it depends on whether they have time, whether mobile is in their regular working context, and whether the studio wants to absorb that scope. Our services are most useful when a team wants specialist input without redirecting existing developer attention.

"Isn't the feasibility review just preliminary — does it actually change anything?"

It tends to change quite a bit. Studios sometimes discover the port they planned is more complex than expected. Others find it's simpler. In both cases, having a clear assessment before committing to a build changes the decisions that follow.

"Is a Polish Pass really necessary if the build already feels stable?"

Not always, but the store prep checklist and performance review catch things that are easy to miss from inside the project. A second pass by someone not embedded in the build often surfaces small issues that seem minor until a reviewer flags them.

A summary

Why a considered approach tends to work better

Risk is reduced early

A feasibility review moves the difficult questions to the stage where they're cheapest to answer.

Scope stays honest

Fixed pricing per service means you know what you're paying before work starts.

The game keeps its character

We start from the original — not from a mobile template — so the port still feels like the game.

Thinking through your own port?

Drop us a note with a bit of context about your game. We're happy to share a first read without any commitment on either side.

Get in touch

Not all porting work looks the same once it's done.