How we think

Some things matter more than scale.

We've built these values through years of arcade work — not from a mission statement document, but from the practical experience of getting things right and wrong.

← Back to home

Our foundation

What drives the work.

Coinslot started from a specific frustration: arcade games are a distinct form with their own logic, and most development resources treat them like any other game. The timing, the input feel, the way a loop draws a player back — these are things that require attention and knowledge, not just engineering capacity.

We wanted to build a practice that takes arcade work seriously on its own terms. That means staying small enough to give each project real attention, and honest enough to tell clients when something isn't working — even when that's harder to say.

Vision

What we think is possible.

We believe indie arcade development is in a genuinely interesting place right now. The cost of building has come down, the audience for original arcade games is real, and the tools available to small teams are more capable than ever.

What often holds projects back isn't technical limitation — it's the gap between a strong idea and a clear, well-shaped execution. That's the gap we work in. Our aim is to help more good arcade games reach a playable state, and to do that in a way that leaves the creator more capable than when we started.

We're not chasing scale. We'd rather work on fewer things with more care than run projects through a pipeline.

Core beliefs

What we hold to be true about this work.

Arcade feel is a specific craft.

There's a tactile quality to good arcade design — the way inputs register, the pace of the feedback loop, the moment-to-moment rhythm of play. That quality doesn't happen by accident. It's the result of deliberate decisions at every level, and it's what separates a game that's merely functional from one that earns a second quarter.

Early clarity saves late confusion.

Most development problems that emerge at the build stage were present at the concept stage — they just weren't visible yet. A well-defined brief and a tested paper prototype are worth more than they cost. We believe in doing that groundwork properly, not treating it as a formality before the "real" work begins.

The client should leave stronger.

Every engagement should transfer capability, not create dependency. When we document a build or write a design brief, we write it for the people who will use it — not as a record of what we did, but as a tool for what they'll do next. If someone couldn't continue without us, we haven't done our job properly.

Honesty is more useful than reassurance.

We'd rather tell a client that a mechanic isn't working than let them spend months building on a shaky foundation. That's not always comfortable to say or hear, but it's the kind of feedback that actually helps. We try to be direct without being harsh — the goal is to help the project, not to demonstrate our own cleverness.

Scope is a form of respect.

Agreeing on clear scope before work starts respects everyone's time and money. When the scope is vague, projects drift — and usually the client ends up paying for the drift. Being specific about what's included and what isn't isn't restrictive; it's what makes a collaboration trustworthy.

Small teams make good decisions differently.

Large teams need process to coordinate. Small teams need trust and judgment. We operate as the latter, and we work best with clients who are comfortable in that mode too — people who prefer a direct conversation to a status report, and who'd rather resolve a problem in twenty minutes than escalate it through a chain.

In practice

How these beliefs show up in the work.

Philosophy without application is just words. Here's where you'd actually notice these values in a real engagement.

Concept

We spend real time on the core loop question before anything else. Not just "what does the player do" but "why do they keep doing it" — that's the question that shapes everything downstream. If we can't answer it clearly at the brief stage, we say so rather than moving on.

Build

During the build, we keep the client informed without flooding them with updates. You'll know what's been done and what's coming. If we hit something unexpected — a mechanic that doesn't translate, an input issue — we raise it directly and talk through options rather than making quiet decisions alone.

Polish

In the polish phase, restraint matters. We're there to serve the game you've built — not to rebuild it in our own image. Changes are proposed, not imposed. If we notice something structural, we flag it and let you decide whether to address it, rather than treating every observation as a mandate.

Handoff

The handoff document we produce at the end of an engagement is written for the next person who picks up the project — not for us. It covers the decisions we made and why, the things we noticed but didn't change, and a clear picture of where the project stands. It's a tool, not a receipt.

The human side

Every project is someone's idea.

We've worked with first-time creators who were nervous to share a rough concept, and with experienced developers who wanted a specific kind of outside input. In both cases, the work is personal — it represents time, money, and something the person genuinely cares about.

We try to hold that with care. Feedback is given in service of the project, not to assert authority. Questions are asked because we're genuinely curious, not to test whether you've thought things through. We work at your pace where possible, and we ask before making assumptions.

No jargon walls

We explain decisions in plain language. If a term needs context, we provide it — there's no advantage to keeping you at a distance from your own project.

Your instincts matter

You know your game's intent better than we do. When there's a disagreement, we share our reasoning and listen to yours. We're not always right.

Reasonable pace

Most of our clients are working on projects alongside other commitments. We're comfortable with that reality and build it into how we plan and communicate.

Thoughtful change

We improve carefully.

We're not chasing novelty for its own sake. Arcade design has a deep history and a lot of hard-won knowledge embedded in it. When we try something different, it's because we have a specific reason to think it will serve the game better — not because it's new.

That said, we don't treat tradition as a constraint. If a client's concept calls for an unconventional approach, we engage with it seriously. The question we ask is always "does this serve the player experience" rather than "does this fit the template."

Integrity

What we commit to.

We say when we can't help.

If a project is outside our scope or we're not the right fit, we say so early. Taking on work we can't do well helps no one.

Pricing is stated upfront.

Every service has a clear, published price. There are no discovery calls designed to upsell you into something larger than you asked for.

We own mistakes.

If we get something wrong, we acknowledge it, explain what happened, and fix it. No deflection, no explanation that reassigns blame.

Collaboration

We work with you, not for you.

There's a meaningful difference between delivering a service and collaborating on a project. We aim for the latter. That means sharing what we're thinking, asking what you're noticing, and treating the engagement as a joint effort rather than a transaction.

We're also genuinely interested in the broader indie arcade space — the people building things, the places showing them, the conversations happening around what the medium can do. That interest isn't a marketing position; it's why we're here.

Duration

We think past the delivery date.

A finished engagement is the start of something for the client, not the end of our involvement in the project's health. The brief, the build, the handoff — these are tools the client carries forward. We design them with that in mind.

We also think carefully about what we take on. A project we can do well is worth more to everyone than a project we take on to fill capacity. Staying selective is how we protect the quality of the work.

→

Documents written for reuse, not just for record

→

Builds structured to be extended, not rebuilt from scratch

→

Decisions explained so future teams understand the reasoning

→

Scope kept realistic so the project finishes with energy, not exhaustion

For you specifically

What to expect if we work together.

You'll communicate directly with the people doing the work. You'll receive honest feedback when something needs it. The deliverables will be structured for your use, not ours. And when the engagement ends, you'll own what we built without conditions.

We're not trying to be the only studio you ever work with. We're trying to be the right collaborator for a specific part of your project — and to do that well enough that you remember the experience positively, whether or not you come back.

Our commitment to you

✓
Clear scope agreed before work begins
✓
Direct communication throughout
✓
Honest feedback, even when it's uncomfortable
✓
Deliverables structured for your team's use
✓
Full ownership of everything produced
✓
No dependency created — you can continue without us

Ready to talk

If this approach resonates, we'd be glad to hear about your project.

No formal pitch needed. Just a few lines about where your arcade idea is and what you're trying to figure out.

Get in touch