Independent software & product studio

Software and product, built as one system.

An independent practice for shaping ideas into clear, working digital products. Product thinking, interaction design, engineering and visual direction stay in the same pair of hands.

Since 2016 · Canary Islands · Available for work

01 · Selected work

Products owned end to end.

Wisp.landArchive

02 · Approach

Three movements, run in order.

Define
Find the useful core. Most of what a brief asks for is not the part that decides whether the product works.
Build
Make it real early. A working version answers questions a document keeps open.
Refine
Remove what gets in the way. The last pass is the one people actually feel.

03 · Practice

A practice, not a pipeline.

aday.studio is the practice of Aday González. Product thinking, interaction design, engineering and visual direction are one way of working, at a scale where those four never have to be translated between people.

Read the practice

04 · Contact

One signal out.

There is no form here. Email is direct, it keeps a record, and it does not lose what you wrote. Tell me what you are building and where it is stuck.

info@aday.studio

LinkedIn
Canary Islands, WET/WEST

Android runner-shooter

Paperbot

An Android runner-shooter built end to end, from pencil drawings to a full progression system and connected Play services.

Drawn before it was digital

Paperbot started on paper. Characters, environments and interface ideas were drawn by hand, then edited, textured and animated for the game. The irregular quality of the original drawings stayed visible on screen rather than being cleaned away.

The project was developed in 2016 and later expanded into 3D character studies and a wider robotic-city concept. Neither of those replaced the original silhouette.

A complete runner-shooter loop

The playable game combined continuous movement, shooting, enemies, hazards and stage-specific navigation. La Nave, Cubierta and Descenso each used space differently, and objectives, difficulty levels and records gave every run a reason to exist beyond survival.

Mechanics, content and interface were built as one system. Character statistics, inventory, equipment, workshop upgrades, rewards and mystery boxes tied a single run to longer-term progression.

A connected mobile game

Paperbot also carried the services expected around an Android title: Google Play achievements, rankings and cloud saving. Events and additional content extended it past the initial release.

The game is available on Google Play.

Pencil studies of Paperbot's mechanical head and arm from several angles. — Pencil studies fixed the mechanical silhouette before any digital production began.

The 3D study translated that silhouette into volume and movement without redrawing it.

Paperbot exploring a dense robotic city in a purple night scene. — A robotic-city concept tested how far the world could expand past the first three stages.

Paperbot character screen showing health, ammunition, fuel and equipment statistics. — Character statistics exposed the systems behind every equipment choice.

Paperbot inventory with equipment slots and a selected pair of boots. — Inventory connected collected items directly to the playable build.

Paperbot workshop displaying purchasable upgrades and resources. — The workshop carried upgrades, purchases and character customisation.

Paperbot mystery-box reward screen with possible prizes. — Mystery boxes turned earned resources into a visible reward loop.

Paperbot stage screen for La Nave showing difficulty, objectives and record. — Stages, difficulty, objectives and records gave each run a purpose beyond survival.

A direct capture of La Nave with the updated character and animation set.

Power-ups changed both the rhythm and the destructive reach of combat.

Google Play leaderboard showing Paperbot player rankings. — Google Play rankings placed a personal run next to everyone else's.

Google Play saved-game screen containing Paperbot cloud saves. — Cloud saving preserved progress beyond a single local installation.

Keep scrolling to close

Geolocated mobile social network

Wysh

A mobile social network that anchored conversations to real places, built as one system across client and server.

Wysh began with one product question: what changes when a conversation belongs to a place? The mobile client let people read and publish messages at street level, with the map working as part of the interaction rather than as a separate utility.

I built the complete prototype in 2017, from the Unity/C# client and its visual behaviour to the PHP API underneath it.

The idea grew into the systems a social network actually needs: an activity feed, public profiles, friendship requests, direct chat, comments and shared content. Each was shaped to reinforce the location layer instead of competing with it.

Owning both client and server meant the interaction model and the architecture were designed against each other, not in sequence.

Dandelions across the world

Dandelions were messages designed to travel. Someone could release one, see where it had come from, and let the distance become part of what it said.

During public distribution the prototype was used across several continents, with dandelions arriving from places including India, Canada and New Zealand. The product is now retired and no longer available in an app store.

Editorial reconstruction of the feed with fictional names and messages. The interface and its functions are from the 2017 prototype.

Wysh global chat with fictional names and messages. — Editorial reconstruction of the global chat. The list length preserves the density of the real interaction.

Wysh map displaying a message anchored to a real-world location. — Every post could keep the location context it was written in.

Dandelions turned a message into an object that could travel.

The map joined place and content in one direct interaction.

Keep scrolling to close

Studio

Independent since 2016.

aday.studio is the practice of Aday González. It joins product thinking, interaction design, software engineering and visual direction into a single way of working, at a scale where those four never have to be translated between people.

01 · What it is

A studio sized to keep the whole product in view.

The work started in 2016 with complete products rather than pieces of them. A game that needed art, gameplay code, an economy and connected services. A social prototype that needed a mobile client, a backend and a reason for people to open it twice. In both cases the interesting problems sat between the disciplines, not inside any one of them.

That has not changed. The studio takes on work where product, interface, engineering and craft have to be decided together, and where a handover between four specialists would lose more than it gains.

02 · How the work runs

Four rules that survive contact.

01
One pair of hands, start to finish
The person who designs a decision writes the code for it and maintains it afterwards. Nothing gets thrown over a wall, so nothing gets specified in a way that only survives a slide.
02
Build in the real medium, early
Interfaces behave. A static comp cannot tell you whether a transition reads, whether a list stays legible at real density, or whether an interaction survives a slow connection. The working version answers first.
03
Systems over screens
A product is a set of rules that keeps holding once the happy path is gone. Progression, state, permissions and failure are designed with the same care as the first screen.
04
Ship what can be maintained
Complexity is a cost paid every month after launch. The version that survives is usually the smaller one that someone can still reason about a year later.

03 · What that covers

Four disciplines, one decision.

Product
Framing, scope, feature architecture, progression and economy systems.
Interaction design
Interface systems, motion and state, responsive and accessible behaviour.
Engineering
Application and game clients, APIs and services, real-time and 3D interfaces.
Visual direction
Identity systems, illustration, technical art and the craft layer on top of the build.

04 · Plainly

What this is not.

Not an agency, and not a team you can scale on demand. Work runs one engagement at a time, which is the reason it can be owned end to end and the reason availability is limited.

The published work is honest about its state. Paperbot is available on Google Play and Wysh is retired; both are shown as they are. They are here because the decisions inside them are still the clearest evidence of how this practice works.

Start a conversation

Keep scrolling to close

Software and product, built as one system.

Products owned end to end.

Three movements, run in order.

A practice, not a pipeline.

One signal out.

Drawn before it was digital

A complete runner-shooter loop

A connected mobile game

A social layer for physical places

A complete social product

Dandelions across the world

A studio sized to keep the whole product in view.

Four rules that survive contact.

One pair of hands, start to finish

Build in the real medium, early

Systems over screens

Ship what can be maintained

Four disciplines, one decision.

Product

Interaction design

Engineering

Visual direction

What this is not.