Terrafix
Third-person building game on a dead planet. Every machine is a plant, and the whole factory exists to bring the planet back.
Wega Studios product · grown out of the 2025 game jam prototype
Early access planned for Q4 2027

Backend systems, mobile apps and Unreal Engine games. Built by one engineer who owns the architecture.
In developmentKey art created with AIBuild a factory. Get a planet back.
See the gameThird-person building game on a dead planet. Every machine is a plant, and the whole factory exists to bring the planet back.
Wega Studios product · grown out of the 2025 game jam prototype
Early access planned for Q4 2027

A puzzle game for Android and iOS, co-developed by Wega Studios and MayStudios.
Co-development · Wega Studios × MayStudios

A logic game for Android and iOS, built jointly by Wega Studios and MayStudios.
Co-development · Wega Studios × MayStudios

AI does not write code that ships unchecked. It speeds up research and variants — what survives is decided by a review.
Acceptance criteria, data and critical risks are settled before implementation.
Separate components so changes stay traceable and testable.
AI gets only the context it needs and bounded tasks. Generated material stays visible.
Tests, builds and project-specific gates decide what ships.
Domain logic, APIs and data flows that are still changeable years later.

Applications that carry one hand from the data model to the interface — and hand over cleanly.

Android and iOS from one codebase, with resilient state and a release path that holds no surprises.

Gameplay systems in Unreal Engine 5 — from the mechanic on paper to a build someone can play.

Agent harnesses, skills and plugins that make AI systems predictable. With evaluations, gates and measurable behaviour instead of gut feeling.

You talk to the person who writes the code and owns the architecture.
Currently continuing his studies
Reporting directly to the development lead, responsible for the architecture and APIs of the mobile and web clients — from cutting the endpoints to implementing them.
Team work remains team work; project context and individual contribution are not blurred.
Architecture and risk are documented so decisions remain reviewable.
Tests and gates are shaped by the real cost of possible failure.
Substance comes from clear scope, visible risk and reviewable increments — not blanket guarantees.
Define the problem, users, constraints and success criteria together.
Target state · Risks · Acceptance criteriaReduce architecture, interfaces and delivery slices to a reviewable plan.
Scope · Architecture · BacklogImplement visible increments, review them and test them against the criteria.
Demos · Tests · DecisionsSecure failure paths, accessibility, operations and handoff for the usage context.
Release gates · Documentation · HandoffStraight answers on scope, collaboration and the use of AI.
Yes, when the target, risks and delivery increments are shaped clearly. Larger scopes begin with a bounded discovery and architecture stage; any additional roles required are named transparently.
Selectively for bounded tasks such as research, variants, boilerplate or test ideas. Architecture, security and product decisions, diff review and approval stay with the engineer; outputs must pass the same tests and gates as other code.
Yes. Interfaces, responsibilities, review paths and the definition of done are aligned at the start so the work can integrate without creating knowledge silos.
Yes, when they are part of a product or a clear digital objective. The focus is software engineering; visual design is a supporting capability.
Once the scope is clear enough. Uncertainty is shown explicitly; where technical risk is open, a small prototype is often a more honest basis than early false precision.
Briefly describe what should be built or improved, which systems are involved and where the largest risk sits today.
You do not need a finished specification. An honest outline of the goal, context and open questions is enough to begin.
Write an email