Dev Tools & Studio Platforms.
Operator consoles, internal tooling, and multi-tenant platforms for game studios that have outgrown spreadsheets.
Problems we solve
- —Studio pipelines duct-taped together in Notion and Airtable
- —Permission systems written three different ways across three services
- —Admin surfaces that take a week of engineering time to add one field
Approach
How we run a dev project.
- 01
Policy layer first
Permissions, roles, and tenancy modelled before the first screen is built.
- 02
Design system as contract
One token set shared across every internal tool. No visual drift over time.
- 03
Audit and observability built in
Tracing, event logs, and feature flags wired in from week one.
Stack we reach for
The only page on the site where stack appears. Tools are means; the system is the goal.
- TypeScript
- Postgres
- Cloudflare
- tRPC
- Tailwind
- Inngest
Relevant work
AP2T — Soccer facility sign-in, automated
Platform · 2025
Growing Pro — Coach-to-player performance platform
Platform · 2025
Common questions
What people ask before they book a call.
- What kind of studios need internal tooling?
- Studios that have outgrown spreadsheets and Notion but are not yet large enough to justify an internal engineering team for tooling. The inflection point is usually when a producer is spending more than a day a week manually moving data between systems, or when a permission error in production has already cost the studio money.
- What is a policy layer and why does it come first?
- A policy layer is the part of the system that defines who can do what. Building UI before permissions are modelled is the most common mistake in internal tool development — you end up hardcoding access rules into every button and rebuilding half the interface when the org chart changes. We model roles, tenancy, and permissions before the first screen exists.
- Do you build on existing platforms or from scratch?
- Depends on the requirement. For operator consoles and admin surfaces we typically build on top of your existing stack — same backend, same database. For multi-tenant studio platforms we often build from scratch because existing platforms carry assumptions that create problems at scale.
- How long does a typical internal tool project take?
- The AP2T facility platform took three months from kickoff to daily use by staff. Most operator console projects run 6 to 12 weeks. We scope to a first-usable milestone, not a feature-complete spec.
- Who owns the code after the project ends?
- You do. We deliver a documented codebase written so a new engineer can run it without calling us. We do not charge retainers for work we have already built.